How to Improve Developer Experience by Managing Your Pull Requests with a Merge Queue
Many companies have invested in their software departments and, therefore, their teams of developers. At the same time, development practices have changed, and the SDLC has also evolved with the adoption of CI/CD.
The growth of development teams and their productivity brings some issues. Indeed, in the context of a collaborative project on GitHub, the number of pull requests created and to be processed can explode.
This accumulation of pull requests can quickly create new bottlenecks and become a real source of frustration for developers.
I. Common Issues Related to Collaborative Teams
The arrival of new developers or the implementation of a CI/CD pipeline represents a real added value for your team. That's the theory. In fact, you have already understood that a growing or productive team will also produce more and more pull requests. So far, so good.
However, manual pull request management creates new bottlenecks and risks frustrating your engineers if you do not automate it.
Here is a quick overview of the problems caused by manual pull request Management, that could result in an accumulation of pull requests.
Constant Manual Rebases and Updates, THE Boring Task
Depending on the rules you have defined on GitHub, especially regarding branch protections, managing your PR manually is not the best idea.
Indeed, each time a new pull request is merged, all the other pull requests must be updated, or rebased.
This is a very frustrating and tedious action.
Constant manual rebases and updates will drive you and other engineers crazy, because once something is done, it is supposed to be done. The feeling of doing the same task over and over again quickly becomes unbearable. In addition to asking developers to spend time on a task that doesn't add value, they are asked to monitor their PR more assiduously while regularly taking them away from what they like to do most: coding.
In addition to the inherent frustration of returning to a task you thought was finished, a regular manual rebase limits the impact of the developers' work.They have to wait longer to see their code integrated and shipped thus seeing the fruits of their labor.
Broken Production, a Developers' Nightmare
If the task of updating your PRs seems like a hassle, it's still a lesser evil.
What would happen if you delete these rules? Quite simply, an increased chance of breaking your main branch and therefore your production.
Without any safeguards, the more PRs you merge, the more chances you have to break your production.
This can be explained by the law of large numbers and human limits. Indeed, the more PRs there are, the greater the mental load of the maintainers and reviewers, and therefore the chances of letting an error slip through also increase.
The problem is that a broken production can quickly become a matter for the entire software department, if not for the entire company.
As long as the main branch is broken, no more pull requests can be merged. This is a very frustrating time for developers.In addition to not having their work integrated and, therefore their impact on the project (and this for an indefinite period), they have to concentrate on solving the problem.
To be more concrete and illustrate our remarks, we invite you to consult the Case Study carried out with John Basila of Orca Security.
Lack of Impact, Meaning, Happiness, Productivity, and Feeling of Unfairness
More generally, and as a direct consequence of the problems we have just described, poor management of pull requests has a damaging effect on the well-being of your developers.
Indeed, the manual rebase or dealing with an unstable and regularly broken main branch creates real frustration for developers.
At the root of this, there is a feeling of injustice, a lack of productivity, and a lack of impact in their work. These are essential criteria to take into account when talking about well-being at work for a developer.
Let's imagine Bob, a developer from the Bad DX company. Bob commits and creates a Pull Request to have his work reviewed and integrated. Unfortunately, his PR is quickly drowned in a large volume of other PRs. Forgotten, his pull request will have to be updated or even reworked following the integration of other Pull Requests.
A big frustration and many questions can quickly arise: why has my PR not been reviewed then merged when I created it? Why the others before mine?
For Bob, the result is a loss of meaning in his work and a loss of confidence in his team, gradually turning his teammates into rival competitors.
II. Not Such Good Ideas
1. No More Pull Requests, Lower Quality Standards
Not such a good idea #1: skipping pull requests and merging straight.
This way, you'll merge and "deliver" faster than ever. All the developers would see their Pull Requests merged quickly.
But that's the only benefit you'd get.
Such practices will result in broken production and constant reverts, which could harm the product's reputation, cause significant losses, and for sure, drive the whole software team crazy.
It is essential to prioritize testing and reviews, even if it takes longer, to ensure the production environment is stable and the end-users receive a high-quality product. Implementing a robust monitoring and ticketing system can also help detect issues early and prevent significant problems.
2. Create Only Big Pull Requests
Not such a good idea #2: Squash many commits into one PR = Only one PR to review and test = Better merge frequency. That makes sense, right?
Not that much. In software development, big pull requests can be detrimental to the team's workflow and lead to significant issues in the codebase.
The idea of less review and less rebase to speed up the pull request process is not advisable, as it can create more work for maintainers, who have to review a large amount of code in one go rather than in smaller, more manageable chunks, making them losing focus on their reading and critical thinking.
Additionally, big pull requests increase the chance of creating errors and code conflicts, as many changes are introduced simultaneously, making it more challenging to isolate and fix problems.
This can result in hard-to-find errors and significant reverts, which can be time-consuming and frustrating.
It is best to break down pull requests into smaller, logical work units, commit by commit, and ensure that adequate reviews and rebases are performed throughout the development process. This helps prevent conflicts, makes code easier to review and test, and results in a more stable and maintainable codebase.
Big Pull Requests = Hard to review and find potential errors = Big Reverts.
3. Rush Merge, an Infinite and Unproductive Struggle
Not such a good idea #3: Be the first to create your Pull Request and merge to avoid rebasing it.
When merging pull requests, it is essential to prioritize quality, dependencies, and collaboration over pure speed.
Rushing the merge process to be the first one to reach the merge, even if the code is not fully tested or reviewed, is not a good solution. This selfish mindset can create tension within the team and result in poor-quality code being deployed to production, leading to significant issues and delays down the line.
By acting so, you would not gain much except a bad reputation within your team and, more broadly, within your company and colleagues having a grudge against you.
4. Bribe the Maintainers and Reviewers
Not such a good idea #4: corrupt the maintainers and reviewers to see your Pull Request being reviewed and merged first.
Not a long-term solution since you'll spend all you earn before the end of the month. Yep, developers are expensive.
III. A Merge Queue: A Developer Experience Booster
Now that we have identified common issues and listed all the solutions that seem interesting but still are far from being smart, let's focus on the answer you need to improve your developer experience: a Merge Queue!
If you are not familiar with the concept of the Merge Queue, do not hesitate to check our article What is a Merge Queue?
In this section, you will discover 4 good reasons to use such a tool. Let's get started!
1. Make Developers Happy Again
The first benefit of a Merge Queue is a lighter mental load and more time allocated to coding.
Yes, it sounds like your dream, we know.
By integrating a Merge Queue into your workflow, you will save a maximum of time that can be put to good use. But where does this extra time come from? Thanks to the Merge Queue, monitoring and tracking of the Pull Request by the developer is no longer necessary.
You only commit and create your Pull Request; it will be reviewed and tested, then it is directly embarked in the queue.
You come back to coding as soon as the PR is created. You will then receive a notification once your PR has been processed, telling you if it has been merged or not.
The perception of the impact and use of time is greatly improved because a Merge Queue helps you to allocate more time to tasks that are considered interesting and have an impact. Moreover, you know that if you work well and smartly, your changes will be integrated quickly, you won't have to wait for it.
2. Automated Rebase
Second benefit: say goodbye to manual rebasing and hello to automatic rebasing.
As we have seen before, constantly rebasing Pull Requests is a very tedious task. What could be more tedious?
With a Merge Queue, this is history. Each of your Pull Requests embedded in the Queue is automatically updated before being tested.
To do this, Mergify merges the latest version of the main branch directly into your Pull Request. The tests and your CI are then launched and your Pull Request will be merged if all the checks are green.
Isn't life great?
3. A Deep Sense of Justice: Make Developers Teammates not Competitors
Third benefit: JUSTICE!
Using a Merge Queue ensures that Pull Requests are merged in the order they were received, and allows for proper testing and review of each change.
The first arrived, first merged approach ensures a fairer perception of the merging then delivering process.
"If you have a team that is not of a trivial size and has a repository that many people are merging to, then I would recommend using Mergify. Especially if developers are racing each other to merge first." Trym on G2
Moreover, even if you are not the first in the queue, the Merge Queue still ensures that your Pull Request will be updated, tested and merged in a timely manner.
You probably already understood, but, using a Merge Queue promotes a more collaborative and team-oriented approach to development, where everyone's contributions are valued, and no one is left behind.
Ultimately, using a merge queue can lead to a more stable and successful development process, where changes are deployed in a controlled and organized manner, and everyone's contributions are valued and integrated into the codebase.
4. Less Merging Lag and Extended Velocity Through Awesome Features
Finally, by using a Merge Queue, you will significantly reduce merge latency.
Indeed, all your Pull Requests will be processed, it is impossible to forget one. As soon as they are validated, they are loaded into the queue.
In addition to the merge lag, Mergify's Merge Queue offers many features that allow you to increase the velocity of your project. Indeed, if a classic Merge Queue creates a bottleneck to ensure the security of your code, the features offered by Mergify counterbalance this undesirable effect.
Multiple Queues and Priority Management
By using multiple queues and their priority management, you can organize your Pull Requests and prioritize the most urgent ones. This double feature is very useful to treat fixed bugs first.
Batches and Speculative Checks
Finally, the Batches and Speculative Checks features considerably reduce merge lag and increase your productivity. By testing multiple PRs together or in parallel, you merge and deliver faster than ever. And a fast integration means a better perception of the impact of your work.
Interesting Case Studies, Understand How Mergify Changed Engineers' Lives
Working with dev teams all around the world, we create ressources to illustrate how Mergify can concretely help developers to be happier and more productive in their everyday life.
After this slightly promotional note – apologies for that, but you can still visit our Merge Queue's page – you have reached the end of this article.
If you have encountered one or more of the issues presented at the beginning of this post, we sincerely hope that you have not opted for any of the Not Such Good Ideas that we have highlighted (albeit reluctantly). If you have, don't worry, it's never too late to change course and integrate a Merge Queue into your workflow. Your Pull Requests will never be better managed, and your developers will never be happier.
