Customer story: Anodot’s shift from Halp to Actioner for streamlined support
Read now

The curious case of Actioner development lifecycle (Slack-first DevOps)

Find out how Actioner team managed to streamline the development process and improved the daily workflows of developers through automation. Discover the story behind the CI & CD apps built on Actioner.

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!

How do you deliver software?

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.

Phase 1: Planning & Design

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.

Phase 2: Implementation

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.

Phase 3: Delivery 

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 run workflows 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.

How automation could improve our daily life quality

Separate channels, clear boundaries, and context

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.

Automated channel creation for each pull request
Figure 1: Automated channel creation for each pull request

Improved tracking of test statuses

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.

Check run results posted in the thread message
Figure 2: Check run results posted in the thread message

Eliminate redundant messages during communication

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.

Automated PR channel creation
Figure 3: User action notifications in PR channel

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.

Broadcast new commits to main through updates channel
Figure 4: Broadcast new commits to main through updates channel

Release and deploy with one-click

After the pull request has been merged, the most common next stepis 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.

Deploy with one click
Figure 5: Deploy with one click

With such requirements, we have developed multiple Actioner apps and covered these different use cases in purpose-built apps.

Solutions tailored to fit unique needs

GitHub PR management application

We developed a GitHub PR management application to automate some of the processes we found valuable, i.e. 

  • Creating a dedicated Slack channel for each pull request
  • Notifying the PR assignee with results when test runs are complete
  • Inviting assignee & reviewer(s) to the channel 
  • Sending messages to the Slack channel when a comment is added to a pull request or to a specific change
  • Broadcasting new commits to a specific channel

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.

Continuous Integration & Deployment application

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.

Broadcast deployment events to a channel
Figure 6: Broadcast deployment events to a channel

GitHub Actions workflows application

We have many GitHub workflows 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 workflows for your GitHub Actions.

Run GitHub Actions workflow from Slack
Figure 7: Run GitHub Actions workflow from Slack

With the GitHub Actions workflows app, you can easily clone & refer to these workflows 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.

Subscribe to GitHub Actions workflow
Figure 8: Subscribe to GitHub Actions workflow

Have different use cases?

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!

Similar posts

DevOps

Building GitHub AI code review assistant with Actioner

Build your own GitHub Al assistant for pull request code reviews. Interact with the Al copilot, request to make changes to the PR according to its suggestions.

Canturk Sen
DevOps

The One-click deployment within GitHub PRs on Slack

Deploy code with one-click from Slack while collaborating on Pull request channels. Read the blog to learn more 👉

Alper Saglam
DevOps

Top 3 Planning poker Slack apps for 2024

Here we've listed and compared Planning poker Slack bots. Let's find the best Slack app that fulfills your team's needs.

Aysegul Yavuz Gokcuoglu