Streamline Your Development Workflow with a Merge Queue: Say Goodbye to Code Breakages and Shipping Delays
When you are developing new products or features, time is key, and you can't accept being stopped several times because of malfunction. And by malfunction, we mean the main branch being red instead of green, with your developer team waiting and wasting time trying to repair the whole thing.
The problem here is that most of the time, teams are just fixing the problem, and it comes back hours or days after. They are not aware of solutions they can work with, helping them to ship faster than ever.
When you are a team, it means that several people are working on the same project. Most of the time, it's developers assigned to tickets. They start working on them, creating pull requests to run CI tests to be sure the code is clean. After that, pull requests are approved and merged.
Though it's not as simple as it appears.
I. The Main Problem
To better understand the problem, let's imagine a GitHub repository in the following situation: a pull request is created, and it passes the CI.
While the PR is open, you push another commit to the main branch. CI tests pass, PR is marked as valid.
No code conflict? Then the PR is considered mergeable by GitHub: the merge button is green.
You merge your PR and then you realize that the PR broke the main branch! You actually merged a stalled pull request that introduces a regression or breakages into the production system.
Tons of engineers are confronted with this problem every day. It stops them from delivering faster because they must backtrack, rebase the code manually, and run the CI again, wasting time and money.
II. Underlying Issues
1. This Is What We Call: Break the Production
When many people work on a branch, for example, on a monorepo, you are skyrocketing your chances of breaking the whole code.
It can become one of the principal problems to fix daily in your dev team, half of the week shipping, the other half fixing.
Many clients of ours told us that before Mergify, they were facing daily code breaking and always spending hours correcting it. Like Orca:
Don't give up; there are ways to avoid this problem. ⬇️
2. Mergeable Pull Requests Waiting for No Reason
To be efficient, you should merge your pull request when they are ready, not when you are around. A pull request can be reviewed, pass all the checks, and still sit there waiting, even though it can be merged.
The longer we wait, the more this PR will have to be updated, and the cycle will start again at 0 – a huge waste of time.
3. Repeating the Same Tasks Over and Over Again
If you have understood the initial problem, you will easily understand what we are getting at.
How can you expect your project to move forward properly if your developers have to constantly go back and update their work because their changes are not integrated in a timely manner?
There is no way to do it that way.
A PR must be merged when it is ready; otherwise, an update will be almost mandatory in the short term. Forcing your developers to stop new development to come back to a job they thought was finished.
III. What You Think Is the Solution
Of course, these problems are not new and predate the creation of merge queues.
How do you solve them without a merge queue, though?
1. Do a Manual Rebase
This option is a solution; for sure, you will merge changes, and fix the code, but for how much time? It could be minutes, hours, or days.
Moreover, your workflow could be complex with tedious branch protection, and doing it manually could take you a lot of time because each time a pull request is merged, you need to rebase each PRs that were waiting to be merged. A long journey!
In addition, you need to take into account that your devs are doing a lot of monitoring, always spending time on tasks that are not ''coding'' tasks. It can be frustrating for them.
It could lead your developer team to be less productive, with long ship agenda.
What you should think is;
''No, the aim isn't to correct it, but to avoid it.''
Correct means that you could have the same problem again and again. You need to avoid this with long terms solutions and not short terms solutions.
2. Stop Creating PRs…
If you are this kind of person, going straight to the point, you could think about doing it. Indeed, you will merge faster, so ship faster, but the cost could be important for the stability of your code. By doing it, chances to break the code are highly important.
By skipping testing and reviewing steps, nothing guaranty you that your code is "clean." Yes, you are shipping quicker, but not safer.
3. ...Or Create Fat PRs
Well, it's still better than creating nothing, but still not the good way to do it.
Indeed, fat PRs can be difficult to review from a work time and work effort point of view. Reviewers may need to spend hours understanding and reviewing the changes, so say bye-bye to the ''ship faster'' gain. It's also harder to spot issues or bugs between hundreds of code lines, increasing the risk of errors in your project.
Following the explanation above, it looks logical that fat PRs are more likely to encounter merge conflicts, especially when multiple team members are making changes to the same codebase simultaneously.
All of this can result in lower code quality and increase your team's technical debt.
Don't give up; there is a solution that can erase all of these problems. ⬇️
4. Test Less, Merge More
In the end, the solution could be as simple as this: test less and merge more.
You could, for example, reduce the number of required checks, and ditto for reviews. Pull requests would then be ready to be merged more quickly.
On his side, the maintainer would only have to click frantically on the merge button for each validated pull request.
The integration will thus be greatly accelerated... But at what cost?
Of course, never do this. The time saved would be small compared to the time lost reverting and fixing all the errors you merged.
IV. The Merge Queue, the Desirable Solution
Yeah, just like that, you read the name of the solution that will make you save tons of time and CI costs, making you ship faster than ever!
1. First, What Is a Merge Queue?
The definition:
A merge queue prevents merging broken pull requests by serializing their merge and updating PRs with their base branch. Merging broken PRs can happen when outdated pull requests are being merged in their base branch.
Now you understand the whole concept, this is what it looks like:
A merge queue creates a queue based on every PRs that pass the CI to merge them automatically and sequentially, and it updates any outdated PR with its base branch before it is merged. It forces the CI to retest the PR with the new code from its base branch. All in an automated way, catching any potential regression.
Remember the first graphs explaining the problem companies are facing? The following one is the same thing but with a merge queue. It will automatically merge the main branch with the feature branch.
Haim from Epsagon, a Mergify user, wrote an article called ''How Merge Queues Made My Life Easier''.
Haim Raitsev
c
He also created a GitHub repository with built-in PR automation and merge queue configuration.
V. Why Are You Delivering Faster With a Merge Queue?
If you are still reading, it's because you might think that the queue created could make PRs merge in a longer period than doing things manually. And you are right… if you have a small number of PRs to merge, but when you need to merge 25, 50, 100, or more PRs, it starts to be tedious.
Moreover, as we demonstrated above, not using a merge queue could break your prod, low the overall quality of your code, and frustrate your engineers, leading you to waste a lot of time. While using a merge queue could improve the whole package.
1. Your PRs Don't Wait For Nothing
Once your pull request is ready - we mean it has enough approval reviews, passed all the checks, and there is no conflict – it will be merged.
A merge queue is the most reliable merger you could have in your team, and you won't have to worry about stale pull requests no more.
By reducing the merge lag, a merge queue will considerably increase your velocity.
2. Automatic Rebase
As we said, with a merge queue, each of your PR embedded in the queue is automatically updated before being tested.
It means that the merge queue will make sure that each PR in the queue is up-to-date by merging the main branch into the feature branch.
Then the CI rerun to make sure the PR is mergeable, and it's automatically queued and merged. Amazing.
You don't need to do anything; it will be handled automatically, allowing you to spend time on projects that matter.
3. No More Conflicts
Having a merge queue assures you have each PR up to date with its main branch before it gets automatically and sequentially merged; you are sure to catch any potential regressions and minimize the risk of conflicts.
Coupled with good communication and organization within the project, code conflicts are becoming less and less problematic.
4. Automate Your Dependencies Updates
To streamline your development process, you can use tools like Renovate and Dependabot to create PRs for updating dependencies and fixing code vulnerabilities automatically.
Once the pull requests are generated, you can use a merge queue to automatically merge the changes into our codebase.
Michael Bahr wrote an article about this:
Michael Bahr
5. You Are Doing What You Should Do: Code!
First, a merge queue will improve your code quality because it can be integrated with CI tools to run tests on the code changes before they are merged into the main branch.
This helps catch bugs and other issues early in the development process, saving time that would have been spent fixing them later.
Moreover, the developers will mainly focus on coding by avoiding boring and repetitive tasks such as rebasing or babysitting their pull requests.
6. Go Further with Advanced Merge Queue Features, Like Mergify's Ones
There are merge queues solutions, and there is Mergify, working on the most advanced market's merge queue since 2018.
We created features following users' needs to help you ship faster than ever.
You need to know that sometimes, a classic merge queue can create a bottleneck to ensure the security of your code, and we found the solution, making the Mergify Merge Queue, the must-have merge queue for any developer team looking for a merge queue.
Multiple Queues and Priority Management
By using multiple queues and their priority management, you can organize your Pull Requests ranking and prioritize the most urgent ones. This double feature is very useful to treat fixed bugs first.
Batch and Speculative Checks
Finally, the Batch and Speculative Checks features considerably reduce merge lag and make you save tons of time. By testing multiple PRs together or in parallel, you merge and deliver faster than ever. And a fast integration means fast shipping.
Visit our Merge Queue's page to know more.
VII. Interesting Case Studies
Working with dev teams all around the world, we created resources to illustrate how Mergify can concretely help developers save time and be more efficient:
Conclusion
Time is a crucial factor when it comes to developing new products or features. The constant risk of code-breaking and delays caused by fixing issues can significantly slow the development process and hinder productivity.
Manual rebasing, skipping testing and reviewing steps, or creating fat PRs are not ideal solutions, as they can lead to lower code quality and increased technical debt.
By implementing a merge queue in your development workflow, you can prevent merging broken pull requests and ensure that outdated PRs are updated with their base branch before merging. This helps to maintain code integrity and minimizes the risk of code breaking in the main branch.
With Mergify's Merge Queue, you can save time and CI costs, allowing your team to ship faster than ever. It streamlines the merging process, eliminates the need for manual rebasing, and ensures that all PRs are thoroughly tested before merging.
➡️ Interesting in trying the most advanced merge queue for free? Check Mergify Merge Queue and ask for a demo.
