The State of CI/CD
The 1990’s marked a distinct and challenging era in software development, characterized by late night pipeline stabilization sessions, weeks-long code freezes, projects spanning six months, and even lengthier customer feedback loops.
Then, in 2001 the Agile Manifesto was published, and slowly began revolutionizing software development as we knew it. As agile methodologies gained traction in the industry, customer expectations continued to rise, and engineering teams that adopted scrum over the traditional waterfall approach were suddenly developing features at a faster pace than their operations counterparts could match.
As with any great paradigm shift, this discrepancy in speed highlighted a new challenge: the need to build a faster delivery pipeline.
In response to this demand for accelerated delivery, CI/CD automation and the DevOps movement emerged in the early 2010s.
CI/CD automation opened up possibilities for new architectural approaches like microservices, integrated security, and GitOps – all with the ultimate goal of transforming the way software is built and delivered.
These advances all promised the same things:
- More time to code for developers
- Reduced uncertainty and bugs detected earlier
- A faster, more reliable delivery pipeline & customer feedback loop
Unfortunately, the “more time to code” part didn’t fully pan out, as evidenced by a recent Clockwise study that concluded developers only have 20 hours of focus time per week. And as such, today we find ourselves on the brink of yet another evolution in software development.
Want this guide sent directly to your inbox? Click here and enter your email!
Where CI/CD Can Be Improved
While the benefits of CI/CD – including faster time to market, higher code quality, better collaboration, and reduced risk – can’t be denied, the widespread adoption of CI/CD practices has given rise to a new set of issues: the most glaring of all being the Merge Frequency Problem.
At LinearB, our data analysis team has spent the past 3 years researching cycle time, or the time between when coding begins to when a pull request (PR) is deployed. After analyzing millions of PRs from thousands of dev teams across organizations of all sizes, we found that the average cycle time is 7 days.
But what's really interesting is that most PRs lay stagnant in the review process for 5 of those 7 days. Even worse, we found that the majority of those 5 days resulted in an “LGTM” type review. Painful, we know.
Ultimately, our research revealed two truths:
- The PR review cycle is the main bottleneck engineering teams have to overcome.
- If the code someone wrote, assuming it was properly tested, is released soon after it’s written, there is a better chance of catching a bug while the code & context is still fresh in the developer’s head.
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.
And so yesterday’s solutions have exposed the next big challenge for today’s developers: actually getting code merged.
What is Continuous Merge?
Continuous Merge is a guiding practice behind how engineering organizations program their delivery pipeline. Simply put, it’s a way of applying workflows that optimize the PR merge path for both velocity and quality.
To get started with automated workflows, technical leads can create a simple .cm file that programmatically defines the rules and automation for how their team’s PR process is managed. These rules can help engineering teams:
- Check for the use of deprecated APIs and services
- Automatically identify and assign an expert reviewer
- Unblock low-risk improvements
- Indicate estimated review times, and much more
Repo-based review automations will allow you to eliminate standard, or one-size-fits-all PR review processes, in lieu of routing PRs based on custom criteria.
Why Should I Care About Continuous Merge?
Continuous Merge isn’t just a category, it’s a mindset. And teams that adopt its philosophy and introduce pre-merge workflow automation into their processes will benefit from the following downstream effects:
- Increased Efficiency: Continuous Merge streamlines the release process, allowing businesses to automatically approve safe changes, assign the best reviewer, and request changes when PRs don’t meet your expected best practices. What’s more, implementing automation into the SDLC enables developers to focus on what they really love – coding – instead of spending their time on manual review and merge tasks.
- Enhanced Quality: Continuous Merge facilitates more thorough reviews, leading to higher quality code, adherence to compliance best practices, and fewer bugs. Additionally, automation that alerts developers to high-risk changes, PRs where an expert reviewer is needed and missing data objects can help them identify and address problems early, ensuring higher stability over time.
- Continuous Improvement: Continuous Merge promotes a culture of continuous improvement and learning. Standardizing merge processes can drive best practices across your organization. And workflow automation can help you expand codebase knowledge between teams and fasttrack ramp time for new hires.
- Business Agility: The ability to merge code faster and at a higher quality enables your organization to gain a competitive advantage. Continuous Merge allows business to respond quickly to market demands, competitive pressures, and ever changing customer needs. It fosters agility and flexibility in software development, enabling your team to adapt, innovate, and deliver value faster.
Want this guide sent directly to your inbox? Click here and enter your email!
The First Step Towards Continuous Merge
Most engineering organizations do not have the visibility or mechanisms in place to enforce or audit merge policy across multiple dev teams. And this inconsistency can give rise to poor collaboration, onboarding, context switching, and a lack of code quality.
To take the first step towards Continuous Merge, engineering leaders should start by implementing a set of merge standards on their team that will then be adopted as policy at the organizational level.
Adhering to merge standards establishes best practices for shipping code to maintain quality, facilitate collaboration, and boost efficiency.
Merge standards dictate the decision for “if” “then” scenarios. When practicing Continuous Merge, your merge standards should balance velocity with quality.
Before we dive in, it’s important to note that merge standards can vary widely org to org (and even team to team), depending on factors like company size and maturity. We suggest using the following merge standards as a jumping off point then customizing them to your team's processes as you see fit. From there, you can align at a higher level and reap the benefits of Continuous Merge.
At LinearB, we think of merge standards in two separate categories:
- Merge standards that enforce quality
- Merge standards that boost efficiency
First and foremost, code quality plays a vital role in reliability and collaboration. When code is well-structured and properly documented, it becomes easier for developers to review and merge – either individually or as a team. What’s more, high-quality code is easier to scale as software evolves, allowing for easier integration of new features moving forward.
With that said, code quality is only one side of the equation. Top-performing engineering organizations must also optimize for speed.
Applying Merge Standards with Policy-as-Code
Engineering teams have two options when it comes to implementing merge standards: they can do so manually or they can leverage workflow automation.
The first option, albeit time consuming and task oriented, is certainly do-able.
To start, we recommend working with your team to evaluate your existing code merge practices. It can be helpful to ask questions like:
- Which practices help us ensure high code quality?
- When we collaborate well, what tend to be the reasons?
- What processes enable devs to get code out the door quicker?
Now that you’ve aligned with your team on what’s most important to standardize, it’s time to create a comprehensive document outlining your team’s new merge standards. Feel free to pull from our team’s guide (above) or create your own from scratch.
From there, publish your merge standards somewhere easily accessible, like on your team’s wiki, then conduct a training session to talk through best practices and address any questions or concerns. It can also be helpful to record this session for future hires to review during the onboarding process.
Moving forward, because these standards are subject – and even likely – to change, we recommend evaluating and updating your merge standards at least once a year.
Alternatively, engineering teams have the option to adopt workflow automation. To take the first steps towards Continuous Merge, we recommend installing gitStream, a free workflow automation tool that applies policy rules to your repos that classify and route your PRs.
With gitStream, engineering teams can customize their code review workflows for each pull request, based on the content of the code.
Continuous Merge using gitStream starts with a simple .cm file that programmatically defines how your PR process is managed.
From there, users can implement a set of rules that will help instill a culture of quality and efficiency on their teams like:
Want this guide sent directly to your inbox? Click here and enter your email!
The Future of Continuous Merge
Teams that build a culture of Continuous Merge save developer time, reduce headaches, and become more productive.
The key is removing friction (toil and idle time) from the dev process by creating programmable workflows that classify and route PRs based on their contents.
gitStream marks a shift in the way developers will automate their workflows for years to come. It’s time to wave goodbye to a one-size-fits-all approach to code reviews, and welcome a new era of scalable policy-as-code.
With standardization and repeatability built into your development workflows, growing teams can move faster and scale efficiently.
Setting up gitStream takes less than 3 minutes. Set up your first rule today.
To learn more about Continuous Merge and how it can be leveraged to optimize every leg of your SDLC, check out our other CM Guide:
