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, why it's needed, and how to implement it with automation tools like
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.
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.
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 continuous merge 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.
How to Easily Implement Continuous Merge on Your Team
New tools are emerging to support continuous merge and combat CI/CD bottlenecks.
The .cm (.cm/gitstream.cm) file enables custom automation constructs, including defining context variables, filter functions that can be called on the context variables, and automation actions triggered when all conditions (rules) are satisfied.
The gitStream engine runs the custom automation defined in the .cm file. The engine supports some common actions, including add-comment, add-label, add-reviewers, approve, merge, set-required-approvals, and require-reviewers.
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 continuous merge, 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 and and gitStream:
Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!
gitStream is the free dev tool from LinearB that eliminates the No. 1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.
The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!
SOCIAL SHARE CARD GENERATOR