How to Create a Stronger Developer Experience by Optimizing Repository Management

Ready to build better conversations?

Simple to set up. Easy to use. Powerful integrations.

Get free access

Now that you’ve learned how we use Airbot to help Aircallees focus on high-value tasks instead of losing time on tedious ones, we also wanted to share how we enable PMs and QAs to implement commands to automate some of their tasks. Among them: pull request review summaries, a changelog generator, and release candidate criticality.

Even though those commands were already saving a lot of time, we decided to go even further and fix the discrepancies between our ticketing system and our repository management. We noticed that people tend to forget to update a Jira ticket status once its related pull request has been reviewed, merged, validated by a QA, or released.

At Aircall, we want our teammates to focus on adding value to our product—not on making our ticketing system and our repository management consistent. So we started thinking about automating this part as well.

Our process before automation

We use Jira as a ticketing system and Gitlab for repository management. Of course, we set up both tools so that they’re aware of each other (to take advantage of some built-in automations). For instance, when a commit was made on a branch, the corresponding ticket automatically moved it to “in progress”. Then when a pull request was created, the ticket moved to “in code review”.

Those built-in automations were a good starting point, but the workflow still wasn’t as efficient as we’d like. For instance, when a QA found an issue on a pull request, they had to manually move the ticket back to “in progress” or “to do” and reassign the ticket to the developer.

Also, developers were used to communicating with reviewers on Gitlab, while QAs were more used to communicating through Jira. As a result of each only using one of the tools, we were losing valuable information and couldn’t ask them to keep an eye on two different places.

With that in mind, we made two important decisions and based our whole workflow on them.

1. First, we made Gitlab our source of truth for both developers and QAs. Jira tickets are still used to describe the task and its acceptance criteria.

2. Second, we introduced Gitlab labels to provide more context on pull requests.

Gitlab labels

To provide as much information as possible, we introduced these labels:

• Merge request status for developers to use when working on or reviewing a pull request

  • In progress

  • Review needed

  • Review OK

  • Review KO

• Validation status

  • QA in progress

  • QA OK

  • QA KO

• Labels to define who should validate the merge request

  • Design

  • Product

  • Tech

  • QA

  • No QA (to be used only on rare occasions when we want to skip the validation step)

• Risk to automatically fill a blast radius field we use in Jira

  • High

  • Medium

  • Low

Our full list of GitLab labels

Automation rules

After setting up those pull request labels, we worked on improving the automation rules. We wanted to focus on the most repetitive tasks we had identified: updating the status of Jira tickets.

We based those automation rules on the Gitlab labels. You can see in the schema below, but basically, every time we update a label on Gitlab, the corresponding ticket moves to the correct state and is assigned to the correct person.

For instance, if a pull request is approved and the “MR: review OK” label is set, the corresponding ticket will automatically move into the “Assigned to QA” status and be assigned to a QA.

If that QA finds a bug on the pull request, they will set the label “QA: KO” on the PR, which will move the ticket back into “in progress” and back to the dev it was assigned to.

Our Gitlab <> Jira automation rules

Wrapping up

Now, thanks to pull request labels and custom automation rules, we consider Gitlab as our source of truth and we eradicate discrepancies between our repository management and our ticketing system.

Information from Jira and Gitlab can now be fully trusted, as we’re sure those two systems are up to date.

Finally, software and QA engineers’ experience have increased a lot since they don’t have to keep two systems updated.

Want to learn more about the developer experience at Aircall? Look at our open positions or reach out to one of our team members to learn more.

Published on July 11, 2022.