Colaboração

How to manage software development in Slack

Tips and tricks from engineering teams of all sizes

Criado pela equipe do Slack27 de abril de 2017Ilustração de Sarah Lazarovic

Lots of engineering teams (including ours) use Slack to manage their software development process. We were curious: exactly how do these teams use Slack to keep their work focused and ship stuff faster? So we did as we do, and talked to a bunch of technical teams to find out what works best for them.

TL;DR: Every channel should have a clear reason for being. From there, take advantage of the Slack platform — by using off-the-shelf apps from the Slack App Directory, or building home-grown integrations to pipe in data from internal data sources — to commit and review code, fix bugs, and manage deployment and keep everything running just as it should.

One thing we heard loud and clear: well-organized public channels — where anyone on your team or at your company can stay informed, seek help, and complete tasks — are of utmost importance.

While it may seem like having fewer channels would keep things simpler, we actually recommend an organizational scheme of more channels, each with a specific purpose — this can help to focus work among smaller groups of people who want and need to know the nitty-gritty.

Here’s a channel organization scheme we heard works for a lot of engineers:

General software team channel: Teams usually have a top-level, large membership channel (e.g. #engineering) for all managers and individual contributors from different disciplines (front-end, back-end, deployment, etc.) to talk and solve problems together.

Project channels: Use a naming convention to organize channels for each new feature. If each channel starts with something clear and recognizable like #project- , it’ll be easier to find.

“Your interface is discoverability,” says Nic Benders, chief architect at New Relic. “If I need to talk to somebody on the insights team, I should be able to pop into Slack and post in #insights-team to find help.”

Interest-area channels: Create a channel for each technology or sub-group in engineering, for example #security, #ios, or #java, where specialists can gather. At New Relic, Benders calls them “communities of practice.

Automated output channels: Some teams organize their notifications from software services (some examples below) into a dedicated channel collecting the output, while others instead report specific notifications into project- or team-specific areas.

Well-worn paths

Software development commonly falls into four general areas: writing code, fixing code you’ve already written, publishing it, and keeping everything running and stable. Let’s break down how each part works in Slack.

Build stuff

A software engineer writes code to build and improve product features, and code repositories are key to coordinating it all. A code repository allows a team to work on different aspects of a codebase concurrently, while also managing contributions and code review.

Typically, a developer branches out from the master codebase, deploys to their own local environment, and makes changes. When they commit their code to the cloud, notifications from apps like GitHub and Bitbucket appear in specified Slack channels.

Piping commit messages into Slack raises the visibility of a developer’s work and helps managers track progress. In the event of a problem, it also provides a breadcrumb trail of recent changes that might need to be rolled back.

A GitHub commit message showing recent changes piped into a Slack channel

Pushing changes to the main codebase requires a pull request, and that’s another activity where visibility in Slack can facilitate code reviews and reduce context switching.

Some teams create bots to check outstanding pull requests every morning to make sure a review hasn’t fallen through the cracks:

Slack’s custom bot reminds a channel when a pull request is still open and requires review, and the team marks them with emoji to show when it’s done

Most companies use off-the-shelf apps available in Slack’s app directory, while others, like Vox and its CTO Pablo Mercado, go the custom route. “We take GitHub webhooks and we pass it through our own API layer that then posts to Slack, because we want to customize the amount of output that comes through,” he says.

Fix stuff

For bug tracking, most teams use dedicated tools like JIRA (including JIRA cloud and server, and also Jirio), or they build a custom option to sync with internal systems they’re already using.

Piping bug tracking alerts into Slack is another way your team can be notified in the same place they’re already discussing bugs and code reviews — saving you from constantly switching between apps and browser tabs.

When bugs are reported, channel messages can be used to assign work and monitor progress:

A custom bot sends you a DM in Slack when a bug you reported is closed

Get it out there

Once you’re ready to deploy, sending notifications from Jenkins, CircleCI, or Travis CI in Slack is a good way to keep everyone in the loop when new versions of your apps and sites are live.

You can also catch any failures in the build process and get people talking right away about how to fix them.

Slack built a custom bot to track recent pull requests as they move from staging to deployment. If bug reports began at, say, 5:09 p.m., it’s easy to backtrack to what may have caused any issues or failures.

Other teams launch build-and-deploy events using slash commands (e.g. /deply project-rocket) inside Slack. Still others create custom bots to convert release checklists into multi-step bot interactions that ensure every step for rolling out a new site or app is followed.

“Developer attention is the scarcest resource on the engineering team, so it’s crucial to have a deploy process that makes really good use of it,” says Aaron Suggs, operations engineering manager at Kickstarter.

“It requires very little developer attention because it’s so automated, and if things are broken, it just stops deploying. That’s a really valuable tool to invest in.”

Keep it running

The enormous responsibility of keeping a product online and stable is often the domain of a software operations team (commonly known as “ops” or “devops”). An ops team usually deals with uptime and maintaining infrastructure, and also helps manage minor service interruptions or major security breaches.

Incident response is a blanket term for when things go wrong, and engineering teams were nearly unanimous in their use of Slack as the mechanism for real-time information gathering, analysis, and triage — exactly what you need when things go haywire.

Ops teams most commonly use apps like PagerDuty, Pingdom, and New Relic for monitoring, error-reporting, and uptime packages. Alerts from these services automatically appear in Slack, and thanks to notification settings, ops team members can make sure they’re the first to know when something goes awry.

Pagerduty notification in the #alerts channel showing an ops team member resolved it

When you integrate the apps your engineering team needs into Slack, your team will stay up to date and organized right where they’re already working.

You’ll also get the added benefit of a searchable communication history that makes adding new developers to projects really straightforward. As Jeremy Mack, Director of Engineering at Postlight puts it, “The whole point is (for Slack) to be simple and easy to understand and get into for new people or people on a project — they’ve got the whole history right there.”

Esta postagem foi útil?

0/600

Ótimo!

Agradecemos seu feedback!

Entendi!

Agradecemos seu feedback.

Estamos com problemas. Tente novamente mais tarde.

Continue lendo

Colaboração

3 formas de fortalecer as relações com os clientes com o Slack Connect

Saiba como a Crema, a IQ Accountants e a Spark 64 estão criando mais oportunidades de colaboração com os clientes