How we saved 2.5 hours per day on Slack
I’m a big Slack fan. My engineering team relies on Slack for just about everything, but before we had our present Slack integrations, we often missed notifications across different platforms and had to re-notify each other or check email constantly.
Having brought the notifications all under one roof, we’ve streamlined our processes, and saved enough time for an extra sandwich a day (or two). 😀 If it takes on average 15 minutes per person to eat 1–2 sandwiches, that’s 2.5 hours per day saved for a team of 10 (hungry) engineers. Below I share the best tools we use and why we decided to use them.
Github Integration
The Slack app lets you easily define custom repo — channel routes. And it supports filtering for events.
With a large team, you likely already have multiple engineering channels, such as #engineering, #front-end, #devops, etc, and it’s a good idea to separate the notifications for repos into these channels.
The PR comments notification is the only one you need to have on. Some more trivial notifications like pushing a commit or force pushing branch are mostly noise, because developers can perform these multiple times before the PR is actually ready for review.
Engineer-notifier bot that Slack-pings people from Github mentions
Working with the Github integration has one serious flaw: when someone mentions your handle on Github, it doesn’t trigger a ping notification in Slack.
Solving for this problem, I’ve written a bot that catches those mentions, and automatically “re-mentions” you in Slack, which triggers proper Slack notifications. You only have to maintain a hash map connecting Github usernames to their Slack username ids, that’s it!
Seal bot that posts a list of PRs from all your repos
This one is handy when your team has multiple active repos. It runs a daily cron job collecting all of your open PRs, before dumping all in Slack in a nicely formatted message.
Similar to typing org:policygenius is:open is:pr in the Github search box, but also has nice features like multi-team support and filtering based on PR title/labels (can exclude “WIP” PRs or ones with specified labels).
Deployment Pipeline
To monitor your Continuous Integration Pipeline, I suggest you need only a notification for failed builds and deploys. Succeeded processes are mostly noise, and not worth a Slack message, especially if your CI pipeline is active throughout the day. All of the popular CI services have Slack integrations and configuring their notifications is very easy. We’ve used Semaphore and Buildkite and it’s very helpful.
Wrapping your deploy script with a bot can also pay off. Here is a great article on why you would want to do that. You can use one of the many open-sourced solutions, or pay Deploy Bot to have it done in style 😎.
The idea for the deploy bot is to not only run your deploy commands, but also provide communication about the timing of deploys, which commits are going out, which git commit is currently on your remote server, etc.
Error Reporting and Monitoring
You likely already receive a ton of notifications about your site performance and usage. We have a special Slack channel — one per environment — dedicated for such messages. We use Sentry to catch and give us data for errors on our website, and NewRelic to monitor site performance.
You may also want to identify the most important type of errors and set these words as triggers in your Slack settings. This will ensure stuff you care about will trigger a Slack ping.
IFTTT Google calendar integration!
I like to focus on a particular task for a while, and can easily miss a meeting if it wasn’t for this. Regardless of your punctuality habits, it’s nice to receive a reminder about your meeting without having to check your calendar. To use this effectively, create a dedicated private Slack channel, such as #john-s-notifications, configure it on IFTTT and set notification preferences to “activity of any kind” for that channel in Slack.
Voila! Your boss is much happier now!
#slack-overflow engineering channel
Your colleagues are experts in different parts of the stack. There is always an engineer that has most experience with X and is sought after by others for advice or a quick question. There are team members who have focused on a particular part of the stack and have the best domain knowledge of that code. Whatever the reason, engineers ask other engineers technical questions.
We ask each other technical questions in a dedicated Slack channel, where questions and answers can be seen by other team members. This falls short of maintaining a full-blown QA wiki, but retains most of the benefits, since Slack history is fully searchable (providing you are a paying Slack customer 💸).
Note: The above is a sample of good tools out there and by no means an exhaustive list. If you use other tools, I would love to learn about how they help your team — please leave a comment 👇
