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.
The Problems We Wanted to Solve
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.
Our First Version of Airbot
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.
What are 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:
- software engineers need them to easily list PRs they must review
- team leads use them to have visibility on the features the next version embeds
- product managers fetch changelogs, thanks to a command
- QA engineers list tickets waiting to be reviewed with a command
- even our CI/CD pipeline uses commands
How to run commands?
Airbot commands can be run from different places, depending on the use case:
- via Slack, by simply mentioning
- via a terminal, using Airbot’s CLI
- in the context of a CI/CD pipeline, by also using the CLI
Example of commands
@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.