Customer-centricity is one of our key core values at Aircall, but we believe that if we want to quickly deliver amazing features, we have to focus on the developer experience as well.
To improve the experience for our developers, we’ve built processes and tools to help our developers review, test, and ship high-quality features, faster.
In 2021, we moved our repositories and CI/CD pipelines from Bitbucket to Gitlab while keeping Jira as our main ticketing system. While we could have simply translated our CI/CD configuration files without improving anything, we decided to take a step back and analyze our workflow.
Aircall’s tech team almost tripled since January last year, with some teams working on more than five repositories at the same time. We couldn’t rely on the same processes and tools as before: We needed faster code reviews, a dedicated testing environment, and more reliable automated ticket transitions.
We couldn’t fix all the problems at once, so we decided to focus on the most critical ones:
1. Lack of visibility of our PRs, spread over multiple projects
2. Lack of visibility of our release candidates and changelog generation process
3. Discrepancies between our ticketing system and our repository management
We talked to a lot of our engineers from different teams to understand the root causes. We discovered that many tried to stay away from Jira as much as possible and were much more comfortable relying on Gitlab instead. They also had trouble listing all the PRs they must review, which sometimes led to forgetting to review PRs in minor repositories.
We decided to build a dedicated tool for that: Airbot.
Its first mission was to automate as many things as possible between Gitlab and Jira and help developers see which PRs need to be reviewed without browsing a lot of repositories.
Airbot’s mission is to make our work easier by providing a set of useful commands and automating as many tedious manual tasks as possible.
With that in mind, we identified a set of repetitive tasks developers perform every day and automated them. One of the main aspects of Airbot is commands.
Commands are a set of directives anyone can run to perform specific redundant actions and be more efficient. Commands are the answer to a lot of use cases we’ve identified during our internal interviews:
Airbot commands can be run from different places, depending on the use case:
@airbotBy typing @airbot pr-summary in a dedicated Slack channel, software engineers can easily list all PRs that need to be fixed, reviewed, or merged. QA runs this same query to list the PRs waiting for validation.
Team leads run the @airbot release-candidates command to list all the PRs that will be embedded in our next release.
Product managers use @airbot changelog to generate a formatted changelog, with links to Jira tickets.
Airbot can also be used in a CI/CD context, as you can see in these “pre-release creation” and “release” jobs of our pipeline. Those jobs use Airbot to create a Jira release and move the correct tickets into it. By doing so, we completely automated this time-consuming task that adds no real value to our customers.
In this article, we presented how Airbot helps Aircallees focus on high-value tasks instead of losing time on tedious ones. In our next article, we’ll explain how we synchronized Gitlab and Jira thanks to PR labels and Airbot.
