You’ve heard of Continuous Integration, Continuous Deployment, and Continuous Delivery, but have you heard of Continuous Merge?
What's the difference between CI/CD and Continuous Merge?
Continuous Merge is a step that enhances the CI/CD (Continuous Integration/Continuous Delivery) process, and is likely already a part of many existing CI/CD pipelines. But don't worry, we're not going to be calling it CI/CM/CD now.
Continuous Merge is a process where code changes are automatically merged into the main branch, also known as the trunk, when they pass an automated series of tests and other workflows such as static analysis. This eliminates the need for pull request reviews on low risk PRs, which leads to a reduced Cycle Time, more frequent deployments, and more time on your developers' hands to actually write code.
So, Continuous Merge is a process of automatically merging code changes into a mainline branch, while CI/CD is a process of automating the testing, building, and deployment of software.
What's wrong with CI/CD?
CI/CD undoubtedly improves development workflows, reduces the manual labor involved in testing and deploying code, and leads to an increased deployment frequency. But it's not a perfect process.
Even the most well-oiled and automated CI/CD pipelines can get blocked by the manual step of code review. Pull requests and code reviews on simple changes that take days, even weeks, can lead to delayed releases and merge conflicts. Oftentimes, lengthy reviews come down to the fact that developers are too overwhelmed to tackle PR's when they have their own code to write and features to complete.
Continuous Merge addresses this bottleneck in CI/CD pipelines by eliminating the need for manual PRs and code reviews on low risk PRs. With CM, code only needs to pass tests and builds in the CI pipeline before it is automatically merged to the main branch. Thus, no PR approvals or code reviews are necessary.
You might be thinking: "Is eliminating PR's *really *a good thing? It sounds a bit risky."
It's a valid point. But the good thing about Continuous Merge is that you can assign rules for which types of code changes get automatically merged after passing tests in the CI pipeline, and which should undergo a manual review.
For example, PRs might feel like an unnecessary waste of time for minor, low-risk code changes - such as docs, formatting, or tests. In these cases, Continuous Merge is a massive help. Instead of pulling one of your devs away from more important work, or waiting a day for a review of a low-risk code change, these changes can be merged after passing the automated tests in your CI pipeline. This drastically reduces your cycle time and allows your team to deploy these incremental, low-risk changes more frequently.
Other times, manual PRs feel a lot more necessary and important. For example, if you're worried about security issues for a big release, you might ask for 2-3 reviewers and you want to be sure that code is reviewed by the right people. For these, you might want to opt out of Continuous Merge and undergo a manual review. Even if you opt out of Continuous Merge for these larger, riskier releases, you'd still be improving your cycle time with CM since the smaller, less risky releases are being tested and merged manually. You're also giving your developers a lot of time back by only asking them for manual assistance on PRs that are absolutely necessary.
Ultimately, getting the most out of Continuous Merge is all about knowing which code changes your team is comfortable with automatically testing and merging, and which need to be manually reviewed for maximum safety.
Feature flags and Continuous Merge
Continuous Merge is a powerful process in and of itself, but when paired when feature flags, is a true force to be reckoned with. Feature flags are an added sense of security when used alongside Continuous Integration, Merge, and Delivery. For example, if a PR only included changes within a feature flag and that flag happened to be disabled, there could be a set of rules that indicate that it could be merged automatically. It could even be marked for review after it had been merged. This allows code changes to be deployed without affecting the user experience, while also allowing developers to test the changes in a real-world environment.
At DevCycle, we like to say that feature flags are like a safety net for developers. This is especially true when leaning on Continuous Merge to eliminate code reviews and ship code faster. As mentioned above, assigning rules to ensure that only smaller, less risky code changes are manually tested and merged is one measure you can take to reduce the risk of bugs and other performance issues. Should an issue arise with code that was tested and merged automatically, though, feature flags allow developers to simply kill the feature or rollback any changes instantly.
How DevCycle uses Continuous Merge
At DevCycle we've adopted a tool called gitStream to enable Continuous Merge. We're still new to the concept ourselves, so we're taking it slow with our CM criteria, but we've already seen improvements to our cycle time by enabling it in our most active repos. We plan on building up a larger and more comprehensive set of CM rules over time to really improve our flow. We've implemented CM for merges that gitStream says are formatting, documentation updates, changes to tests and are from dependabot.
To set up gitStream in GitHub, visit: https://docs.gitstream.cm/github-installation/
Wrapping up
The truth is, the more processes you can automate in your workflow, the less frequently you'll be pulling your developers away from actually writing code and building your core product. DevCycle's feature flags enable teams to automate their tests, merges and deployments for a faster cycle time and increased deployment speed. Chat with one of our product specialists for more information on feature flags and Continuous Merge, or get started with DevCycle on your own today.
Top comments (0)