They Use Mergify: Mozilla

Every day, major projects use Mergify to automate their GitHub workflow. Whether they have a core team of 3 or 50 people, the one thing they all have in common is that the project leads are willing to let their developers focus on what’s important—code. We decided to meet with some of them to learn more about their challenges and discover how Mergify helps their teams be more efficient when it comes to pull requests. This week, we chatted with Johan Lorenzo, who is an active contributor on the Mozilla mobile repository.

Who are you? Your role? How many engineers are on the project?

My name is Johan Lorenzo. I am a Staff Release Engineer at Mozilla. Mozilla as a whole has hundreds of engineers, the majority working on our flagship product: the web browser Firefox.

Please, could you explain what the project is?

We use Mergify for some of our small to medium-sized projects. The source code of Firefox has historically been hosted outside of Github. We have plenty of projects on GitHub, though. Four years ago, we decided to move the code of Firefox for Android (and its privacy variant, Firefox Focus) to GitHub. That’s our largest team using Mergify.

How many people are currently working on the project?

We have about 20 recurrent collaborators on Firefox for Android, plus the external contributors.

What are the main challenges with your workflow?

Last-minute rebase, stabilization branches, and regular bumps were things we used to struggle with. Contributors did spend a lot of time ensuring their changes reached the right places. Mergify helped us out!

Can you describe your workflow?

When we moved Firefox for Android to GitHub, it was a huge rewrite of the original app. Users may remember when they got the revamped interface in August 2020. In the beginning, we started with a startup mindset where we had little processes. As the project gained momentum, we began to bring processes close to the ones we have on Firefox desktop.

When a contributor makes a change, they open a GitHub pull request (PR). Our Continuous Integration (CI) system runs to ensure the changes contain no known regression. One or many peers review the PR. When it’s all good, someone adds a GitHub label to tell Mergify to get ready. At this point, Mergify rebases the PR on top of our main branch, reruns CI, and eventually merges it into the main branch. The fact that Mergify rebases the PR is important to us because we have been burned by last-minute conflicts many times.

The code on the main branch gets released every night to a specific user base. As a user, you can actually install a preview version of Firefox. We have 2: Firefox Nightly and Firefox Beta. The former gets the code of the main branch each night. The latter gets the code from a stabilization branch. Every 4 weeks, the main branch gets promoted to the beta stabilization branch.

This brings us to the next Mergify feature we use: backports. Let’s say Mozilla needs to fix something on Firefox Beta. We first open the PR on the main branch and then ask Mergify to handle the rest. It’s pretty useful to us.

Another Mergify feature we love using is automatic approvals. Our repositories need to be kept in sync, so we have robots opening PRs that bump dependency versions in a particular set of files. It happens at least daily. We configured Mergify to automatically approve and merge the PR if CI remains green.

How many PRs do you manage on the project?

Since Firefox for Android moved to GitHub, we have closed about 25,000 PRs.

What is your favorite Mergify feature?

Automatic approvals. It saves a lot of time for Mozilla’s employees!

What has been the most significant impact of using Mergify on your team’s performance so far?

The merge queue is a time-saver! Contributors no longer have to carry the mental load of monitoring their PRs!

What would be your #1 tip for someone new to Mergify?

Don’t know why Mergify didn’t behave the way you expected? Have a look at the extensive up-to-date report attached to your PR!

How would you improve Mergify if you could?

I would love to have the ability to quickly test changes made to the .mergify.yml file. On our end, we solved this use case by setting up a staging git repository where we create all types of events there.