Despite the workflow improvements that have been made with CI/CD, there are huge bottlenecks found in the pull request and code review process. These bottlenecks can be removed with continuous merge, a set of processes that make pull requests easier to pick up and code reviews quicker to merge.
Let’s look deeper into what continuous merge is and why it’s needed
The State of CI/CD
Plain and simple: Continuous integration/continuous delivery (CI/CD) has become standard practice for rapidly delivering new software features, bug fixes and enhancements.
Continuous integration (CI) is where developers merge individual code contributions into a central repository, where automated tests and builds are executed.
Continuous delivery (CD) automates code change deployment to testing and production environments. Continuous deployment — a term often confused with continuous delivery — is the final step of the DevOps pipeline, where all changes that successfully pass the production pipeline are released to customers.
CI/CD automates every step of the development process, ensuring products and features are shipped to users almost as fast as they’re developed. But it does have drawbacks.
Where CI/CD Can Be Improved
Many branches often extend from the central repository when multiple software developers work simultaneously on a large codebase.
Branches with long lifetimes (the period between review and merging) impede the performance improvement that agile practices like CI/CD seek to achieve.
Inefficiencies in the pull-request (PR) process create bottlenecks in the delivery pipeline, especially when code reviews take days to complete.
For optimum CI/CD performance, there should be at most three branches with lifetimes no longer than a day before merging with the trunk. But in most software development environments, this is virtually unheard of.
Pull request reviews that take days or weeks have significant cost implications. Besides work backlogs, delayed reviews can trigger complex merge conflicts. Even worse, pull requests come before integrated testing in the CI/CD pipeline, so a successful review doesn’t guarantee a similar outcome later.
The solution to these bottlenecks in the pipeline is continuous merging.
Continuous Merge Definition
Continuous merge is a set of processes that help eliminate the bottlenecks plaguing pull requests and code reviews.
The standard practice for engineering projects is to manage the code base through a version control system (VCS), where developers and contributors can collaborate.
It’s common for VCS repositories to have one or more branches, and in traditional PR reviews, changes to the code require manual checking before merging into the main branch.
Understanding Why Continuous Merge Is Needed
A typical code review involves a contributor or developer opening a pull request and informing other collaborators that code changes have been pushed to a branch and require reviewing (and subsequent approval) before merging into the main branch.
PRs enable collaborators, typically lead or senior developers, to check the changes for quality adherence and then take one of these three actions:
- Comment on the proposed changes.
- Approve the changes.
- Request further changes before merging the branch.
Many, many inefficiencies characterize this process, often resulting in PRs taking longer than is ideal. For example:
- The collaborator may begin reviewing the PR only to pause prematurely to attend to other responsibilities.
- The process freezes because developers don’t get feedback, nor is the merge executed.
- If the repository has many branches with multiple contributors, the entire CI/CD pipeline may be affected, introducing the risk of merge conflicts and reduction of developer productivity.
Other issues that slow down traditional reviews include:
- PRs being too long;
- Overwhelmed teams;
- Diversion of collaborators to other tasks; or
- Sub-optimal assignment of PRs to people, such that the desired outcome is not achieved in the initial request.
Many gaps in this process necessitate re-engineering the PR review process to eliminate such inefficiencies.
How Continuous Merge Creates Frictionless Code Review
A pull request, also known as a merge request, is where developers or contributors indicate that code changes are ready for merging into the project’s main repository. It is an industry-standard practice for other developers, team leads and other parties to review code changes before merging, human input into this process is inevitable.
Historically, this pull request process has caused inefficiencies, particularly review delays, as the process is not automated, so speed depends on the availability of the right code reviewer.
Continuous merge seeks to improve the pull request review process by introducing a layer of automation that enables automatic approval and efficient routing of complex pull requests to relevant reviewers.
Continuous merge considers the unique characteristics of individual pull requests and routes them appropriately on a risk-based model, ensuring process optimization and bottleneck reduction.
Continuous merge categorizes pull requests and code reviews according to their characteristics — type, code complexity, and size.
This creates automatic pull request lanes that boost merge speed and efficiency.
The 3 Crucial Steps To Continuous Merge
Step 1 – Provide Context To Pull Requests That Make Them Easier To Pick Up
The first step is to understand the context of the pull request. Pull requests are treated equally by most version control systems, which provide the same information for each one — not enough for a reviewer to assess their size or complexity.
Continuous merge adds a contextual layer with more information, like the estimated review time, the concerned project component, and the pull request owner.
Step 2 – Treat Pull Requests Differently Depending on Their Size and Characteristics
The second step involves classifying pull requests according to this contextual information. This process acknowledges that pull requests vary in size — some are just a few lines of code, and others are chunky. Despite this, pull requests go through a similar process, and even those that could be completed quickly may extend for days before the review.
The routing step of continuous merge seeks to remedy such inefficiencies by relying on PR classification to send pull requests with a few lines of code for near-instantaneous reviews and approval. The WorkerB Chrome extension for pull requests simplifies creating and delivering context-enriched pull requests to code reviewers.
Step 3 – Streamline Pull Requests With Low Risk
The third and final step of the continuous merging is to apply rule-based automation and tooling to achieve automatic approvals and merges for low-risk pull requests while optimizing the routing of others based on their level of risk.
Why Continuous Merge Beats Traditional Merge
The traditional merge workflow involves strictly defined steps with all pull requests — whether five lines or a critical change of 100 lines — processed the same way.
Similarly, changes to static files, which can be approved and merged automatically, are processed through the same pipeline. When code reviews are delayed for days, there’s a greater risk of merge conflicts, and idle time between pull request reviews can lead to a drop in developer productivity.
Continuous merge, in contrast, addresses these CI/CD pipeline bottlenecks by contextualizing PR requests and classifying them via a model that has been defined by the team. And following standard DevOps practices, pull requests are placed in appropriate lanes for continuous merge through automated tools.
Continuous Merge Completes the Promise of CI/CD
Traditional PR reviews and merge workflows tend to create bottlenecks in the CI/CD process.
Code reviews and approvals can cause delays for days, even when some are low-risk and could be resolved quickly. Because all pull requests are processed the same way, improvements to the efficiency of this process have yet to be made.
Continuous merge is a promising solution to these challenges. With the continuous merging, developers can create custom rules to accompany their pull requests, optimizing the review process.
Check out this talk from our Director of Developer Experience, Luke Kilpatrick, to learn more about continuous merge:
Engineering Insights before anyone else…
The Weekly Interruption is a newsletter designed for engineering leaders, by engineering leaders. We get it. You’re busy. So are we. That’s why our newsletter is light, informative and oftentimes irreverent. No BS or fluff. Each week we deliver actionable advice to help make you – whether you’re a CTO, VP of Engineering, team lead or IC – a better leader.
