Slack as Key Resource for Engineering Teams

I don’t think you would be surprised to hear that ShuttleCloud uses Slack. It has become one of the main communication tools in our daily workflow and we are very happy with it. Some people I have met lately have had some negative experiences with it and ask how we managed to use it so extensively.

I must confess that it took us some time to get to the point where we are right now. Also, we have experienced some of the issues that other companies have, such as channels flooded with messages and critical information not being read by everyone. In this post we’d like to give some tips and highlights about how we use Slack right now in case they could be useful to you.

This is not set in stone, so we are open to iterate on the way we use Slack. Maybe in the future a different approach will work better for us. Also, we are still a small team, so some of the channels we have might not be useful once there are more people involved, but we will solve that problem when we get to it.

As you will see, we like the paradigm of having one channel for each purpose, which led us to create some singular channels. We even create channels ad-hoc for specific subjects or discussion so that the context and data is clear and isolated. This is a list of the channels that I consider the most important.

Channels of the development team

I will start this list with the channels that we, the engineering team, use for our daily work — not only for technical stuff but also for internal organization or communication.

#dev

This is the first and main channel of the development team, where we talk about technical stuff or our day-to-day issues that only concern the engineering team. The exceptions here are all critical decisions and important announcements regarding the development team.

We don’t expect someone who was on vacation to catch up with this channel when coming back, as it could take hours (or even days!).

#dev_announces

This is precisely the place for announcements and important things concerning the team. Being up-to-date and aware of this channel is mandatory for everyone on the team. In order to avoid flooding, it is not a channel for discussions and chatting, only for statements and important outtakes from #dev have a place here.

#daily_learning

If you are following @ShuttleCloudEng on twitter, you already know that we share some articles and we discuss them on a daily basis. (If you are not following us, you should! :)) This is the channel where we internally suggest articles, agree which ones will be discussed and set a time for the meeting.

#vacations

If some team member wants to take some days off, he/she will communicate it to the team using this channel. To be able to take vacation, the developer must check that some team members are indeed working those days and a have a designated replacement for himself/herself. In this channel all of this can be coordinated before making the official vacation request.

#alerts

In this channel we have set up an integration with PagerDuty (which we use for the engineer on call). The consequence is that every time an alert is fired, it appears here. We all have the level of notifications of this channel set very high so we avoid chatting here, and only make critical comments, mentions or updates about the alerts triggered. Another use case is if a possible/potential critical malfunctioning of any of the services is detected manually by anyone on the team, that will also be communicated in this channel.

#alert_discussion

When an alert needs some discussion or raises some investigation, this is the channel where everything is shared and talked about. We don’t use #alerts for this purpose because we want to avoid unnecessary noise in case of simultaneous alerts.

#deploys

The main purpose of this channel is to announce that something is going to be deployed with all the necessary information and ask for “green light” to proceed with the deployment. There are two channels where a slackbot does some automation, and this is one. First, I’ll explain how we used to do it because our first approach without automation is interesting.

At first, every deploy request was manually announced with a template that included the following details:

• “What”: service to be deployed
• “Where”: which project(s), environment(s) affected by the deployment
• “When”: time of the deployment
• “Why”: brief explanation of the change to be deployed
• “Task”: Jira issue code referencing the bugfix, change, feature to be deployed
• “Risk”: consequences of a failed deployment (ie. service down and how easy it is to rollback)

To proceed with the deployment, someone from the team must approve it (usually someone with knowledge of the affected component(s) and who could assist if something goes wrong). The approval was done just by manually saying “OK” or “go”.

After the approval, the person deploying is responsible for updating the channel with the progress of the deployment, and a confirmation once it is deployed and tested.

Currently, we have the approval and notification process automated with a slackbot. Each project has some team members assigned as the ones that know most about it or who could help in case something fails.

The slackbot requires the approval of the selected team members for the project, and they approve using thumbsup/thumbsdown emojis instead of replying on the channel. The approval of the team members on vacation or not working is not necessary, which is one of the reasons why there is more than one person in those teams. In the following image there is one example of a deployment:

1. The team members whose approval is required are explicitly mentioned so they get a Slack notification if there is an action required from them.
2. The bot counts the number of votes, and if there are any thumbsdown emoji, the deployment will be rejected. If all team members give a thumbsup the deploy is approved.
3. The bot informs the channel about the result of the approval process and how to proceed and start the deployment if it was approved.
4. Finally, once the deploy is finished, the bot shows a final message on the channel.

Once the feature/bugfix/change is live, the rest of the team should be informed on a different channel called #changelog, which is the first of the public channels that I will explain.

Public channels

#changelog (public)

In this channel everyone can see what has been deployed in every system we have. Do you remember the bot that I mentioned in the #deploys channel? This is the second channel where there is a bot doing some automation.

Before, the owner of the deployment was responsible for announcing here what has been done, using the following template. All fields but one are the same as the ones used in the #deploys channel when the approval was requested (those with a star):

• (What)*
• (Where)*
• (Why)*
• (Task)*
• (Test): (optional) if it is something that can be seen/tested from the outside (ie. a new feature) the steps to actually confirm it has been done.

As you can see, there was a lot of copy/paste involved, so our slackbot has been a great improvement. When a deployment is announced as finished, the bot automatically updates the changelog channel:

#<project-n>

To discuss issues about a certain project with all stakeholders involved, there is a public channel for each big project in the company. This is also the place where actions can be coordinated between different teams and important notifications can be shared.

#madrid_office

Finally, for all office-related or local issues, there is a channel for each office. In my case it is the office in Madrid. In this channel you can see a wide variety of messages, from ordering some lunch together or asking who is in the office at a precise time, to suggesting some drinks after work.

So to sum up, we use the following channels:

• #dev: development team coordination and technical discussions.
• #dev_announces: important changes, team conventions and process decisions.
• #daily_learning: articles share and daily meeting coordination
• #vacations: vacation agreement and team coordination
• #alerts: integration with PagerDuty and notification of critical issues
• #alert_discussion: discussions about events happening in #alerts
• #deploys: deployment approval and coordination process
• #changelog: deployment notification and log
• Project specific channels: discussions and coordination about an individual project with all stakeholders
• #madrid_office: office-related or local issues

There are some other channels that I did not mention, but I think I have covered the most interesting ones from an engineering perspective. In addition, this can be enough to give you an idea about how we love to use dedicated channels. Finally, you may have also noticed that some channels are more critical than others, and this is something that everyone in the team must be aware of.

If you have any comment or questions about how we use Slack, please let us know! We are happy to discuss tips and best-practices with Slack and maybe we can improve the way we use it.

This article has been written by Nacho Carretero, software developer at ShuttleCloud (@carretops)

The post Slack as Key Resource for Engineering Teams appeared first on ShuttleCloud Blog.

Originally published on ShuttleCloud Blog