Updating, Testing, and Merging Several Pull Requests at Once with a Merge Queue
Tags: cicd, github, productivity, git
Published: 2023-08-21 14:52:11

The rapid expansion of a project can lead to an exponential increase in the number of pull requests requiring processing. This surge in pull requests brings an inevitable, heightened demand for Continuous Integration (CI), leading to a consequent surge in both the time needed for CI and, subsequently, the associated costs. So how can this be mitigated?

Implementing a merge queue offers a feasible solution, as it can effectively manage and reduce the number of CI jobs initiated per pull request. This is a natural and direct advantage of a merge queue. But to enhance efficiency even further, you might consider formulating a smart testing strategy and utilizing a distinct feature known as batches.

##Avoid Rerunning Tests
In the context of a large-scale project, a growing number of pull requests can have an exponential effect on your CI times. This is especially true if you refuse to merge out-of-date pull requests — and you should.

Let's take the example of a project with 20 open pull requests.

Without a merge queue, after the first pull request has been merged, the other 19 would have to be rebased as they're out-of-date, and 19 CI jobs would have to be restarted.

After the second merged PR, 18 PRs would have to be rebased, and 18 CI jobs would restart. And so on.

With a merge queue, if you have 20 open pull requests, you'll only have to rebase 20 and schedule 20 CI jobs.


![Merge Queue Scheme](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/62mbm335q4i58f4ynjnn.png)

A merge queue solves this issue by processing your pull requests sequentially and automatically, one by one. After automatically rebasing it, a merge queue triggers a CI job to run on that pull request. The same principle applies to the second pull request and then to all the others.

To sum up, without a merge queue, the number of CI jobs could be equal to:
20+19+18+17+...+1=210 CI jobs! As opposed to just 20 jobs in all with a merge queue.

##Smart Test Strategy: Reduce CI Time, Increase Velocity
By using a merge queue, you can go even further to optimize your CI times and improve the velocity of your project.

Let's say some of your tests are very long and therefore require a lot of CI time.

If you launch them as soon as you create your PR, you need to be sure to merge them right away if they pass.

However, without automation, you are likely to have to rebase this PR and therefore have to run your tests several times. Each iteration represents time and money.

With a merge queue, it is possible to split your tests to optimize your workflow.


![Test your PRs Smartly with a Merge Queue](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/is8lqsbyu3qpmsrqxwpw.png)

When a pull request is created, it only runs the unit tests. If they pass, the pull request will be included in the merge queue. Once it's at the top of the queue, it's time to go: just after being rebased, this is the best time to launch your longest and most expensive tests (functional tests, end-to-end tests...).

If those tests pass, the pull request will be merged, and you only had to run your tests once, at the right time.

##Going Further: Introducing Batches Feature
Now that you know a little more about the merge queue and how it can help you reduce your CI time, it's time to look at a real game changer.

We're talking about Mergify's Merge Queue's exclusive feature: batches.

{% embed https://www.youtube.com/watch?v=zBKl8lr6B2w %}

With batches, you can check the mergeability of multiple pull requests at once. To do so, you have to use the batch_size option.

If you set it to 5, the merge queue will create a rebased draft pull request and merge the commits of the five next queued pull requests.

Then, to test all the commits from the five pull requests, Mergify will only run one single CI job instead of 5!

If the CI passes: Mergify merges the five queued pull requests and closes the draft one.

If the CI reports a failure: Using a binary search, Mergify builds two smaller batches of pull requests to check in order to find the culprit; for example, a batch of 3 and a batch of 2. Once the guilty pull request is spotted, Mergify kicks it out of the queue, and the rest of the pull requests are merged.

Look at the demo below to see what it looks like when used.

{% embed https://www.youtube.com/watch?v=dc2_fZkJaVU %}

##Conclusion
In conclusion, the exponential increase in pull requests and consequent demand for Continuous Integration (CI) in a rapidly expanding project can present significant challenges, most notably increased CI times and associated costs. However, tools and strategies like the implementation of a merge queue, smart testing, and batch processing can effectively mitigate these challenges.

A merge queue helps process pull requests sequentially, reducing the need for rebasing and the restart of CI jobs. This makes your CI process far more efficient and cost-effective. Additionally, a smart test strategy, which includes running unit tests immediately after creating a pull request and running more extensive tests only after a pull request reaches the top of the queue, can significantly reduce CI times and increase project velocity.

The batch feature in Mergify's Merge Queue offers a game-changing advantage by checking the mergeability of multiple pull requests at once, reducing the number of required CI jobs even further. It smartly handles any CI failures by identifying and eliminating the problem pull request while seamlessly merging the others.

With these features and strategies, the challenges of a growing project can be effectively managed, keeping your CI times and costs in check and ensuring the project's smooth and efficient progress.