In this post, we share how we've improved the quality of developers' lives by building Slack apps and share some best practices. We hope you enjoy reading it and find it helpful!
There is no single answer to this question. Every company has its ways while delivering software to its internal and external customers. Regardless of the tools and environments used, some best practices are followed. Throughout this article, we will share some of our favorite best practices.
As part of the development lifecycle, we select a reviewer to discuss the details of the development phase as soon as we know what we will be working on. Communication is crucial before getting started with the implementation. Because we can make critical decisions regarding the issue, such as what design should be used, which parts of the product and code will be affected, etc. If you do not want to end up with code that performs poorly or cannot perform the tasks expected of it, the communication phase should not be skipped. Needless to say, it can result in deleting the feature branch and starting from scratch (It happened to me, just saying, and it was not cool). Once we clarify what changes need to be made and how, we start the implementation and create pull requests at some point.
Pull requests are essential to the implementation phase, since they are the starting point for triggering tests to see if the recent changes have broken anything or if we need to request a review. Accordingly, even if the work needs to be done is extensive or complex, it would be wise to divide it up into smaller chunks (via PRs or commits). By doing so, you can identify any problems earlier and solve them much more effectively. Additionally, your reviewer would also be thankful while reviewing the changes.
Upon review, changes are merged into the main branch, and deployment begins immediately. Almost each pull request is sent to production on its own to ease tracking and take action quickly if necessary, like reverting the pull request or understanding the cause and sending a quick fix. Therefore, we also keep track of the active deployments within the team while merging and sending changes to production.
We use Slack as the primary communication channel within our company. We previously used private conversations to discuss issue details, mainly between the issue developer and reviewer(s). This causes problems when we want to involve other people in the conversation, as there could be irrelevant stuff or missing context when they get involved. In addition, having a specific place for a particular issue makes it easier to discuss different issues and find them later. For this reason, we thought it would be best to create dedicated Slack channels for each pull request automatically.
Once PR is ready for review, adding the reviewers to the Slack channel automatically speeds up initiating the conversation. Before having PR specific channels, we used to start with: “Hey mate, I have made some changes regarding user authentication. Can you take a look, or can we discuss something related to table design?” Setting up a separate channel clarifies the boundary and keeps the conversation focused.
During the implementation phase, you iteratively push commits to your feature branch and wonder which tests are failing, if there are any. To learn that, you need to manually check once in a while if the test runs are complete. Having suffered from that, we thought it would be excellent to get notified automatically when tests are complete. In our solution, in addition to adding Slack notifications for that, we added a follow-up action to the notification message allowing you to merge your changes after rebasing from the main branch to avoid constantly refreshing pages.
While reviewing a PR, communication also happens by commenting on the specific change itself or by commenting on the pull request. When a reviewer adds a comment to the pull request or a specific change, notifying the PR assignee in the Slack channel would help to make the review process more efficient.
Likewise, when a reviewer approves a PR, s/he does not need to take additional step to write that they’ve done so.
When new changes are merged to the main branch, it would be useful for your teammates to receive updates via a channel. If you are making deployments for each pull request separately, broadcasting both of new commit and deployment events helps your teammates to wait for the completion of that before merging their pull requests. It also allows them to rebase with the latest code to stay up to date and keep track of what is being deployed to production.
After the pull request has been merged, the most common action is to start the deployment. Easy access to this operation from Slack improves the daily lives of our developers as it eliminates going to the tool and finding the corresponding page etc. (GitHub Actions in our case) to perform the same thing.
With such requirements, we have developed multiple Actioner apps and covered these different use cases in purpose-built apps.
We developed a GitHub PR management application to automate some of the processes we found valuable, i.e.
We have made this application available in the Actioner app directory so that other teams could also make use of it as well.
In response to requests for other platforms, we also developed Bitbucket and GitLab versions of this app.
Having used the GitHub PR management app for a while, we decided that it would be great to make the Slack message sent when the PR is merged actionable so that you can begin deployment straight away. Similarly, we wanted to centralize the info of whether there is an ongoing deployment and whether a specific deployment was still in progress.
However, we did not want to add such new functionalities to PR management apps since different teams use different tools for deployment, i.e., GitHub actions, Jenkins, custom Slack bots, etc. Therefore, we decided to create an extended version of the GitHub PR management app called Continuous Integration & Deployment.
We have many GitHub actions that we frequently use during our development process— and we thought, why not add GitHub actions directly to Slack? As a result, we have developed a GitHub Actions workflows app that lets you create corresponding Actioner actions for your GitHub Actions workflows.
With the GitHub Actions workflows app, you can easily clone & refer to these actions in Slack messages. For example, you can use the "Run workflow action" to start a deployment after a pull request is merged.
You can also subscribe to any workflow to receive a Slack message about the workflow progress when it is run.
You can install these ready-to-use apps from Actioner’s app directory, start using them in Slack right away, or customize them according to your use cases. Actioner lets you customize apps as you like and share them with the community. Your imagination is your limit while building applications via Actioner. Try it today!
