What is Continuous Merge?

This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by LinearB

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 gitStream.

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 merge.

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:

1. PRs being too long;
2. Overwhelmed teams;
3. Diversion of collaborators to other tasks; or
4. 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 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.

gitStream helps you implement continuous merge.

gitStream deviates from the standard code-review process by automating merge approvals for small, low-risk pull requests and routing other types of code change to appropriate reviewers.

The tool uses a rule-based automation model that empowers both developers and reviewers.

Continuous merge also tries to ensure that the reviews go to the most appropriate people, so there needs to be thought given to the type of code and who is assigned to review it.

You can create automation rules in a .cm file to provide parameters and constraints that dictate how code is reviewed and subsequently merged. This file improves PR classification, allowing reviewers to gain more context on the PR request, so they can prioritize reviews according to characteristics like complexity and size.

Here’s an overview of how gitStream delivers continuous merging through the rules specified in the .cm file:

• Auto-approval of pull requests containing small code changes that have passed unit testing successfully
• Automatic assignment of pull requests to appropriate individual reviewers according to code complexity, estimated review time, and reviewer expertise
• Automatic assignment of pull requests containing critical changes to the ideal review teams through the codification of custom rules

Getting started with gitStream is straightforward because the tool integrates seamlessly with your remote repositories. To set up gitStream on GitHub, for example, you can follow these three simple steps.

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!

Learn more about how gitStream is making coding better HERE.

This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by LinearB