Many teams working towards an agile development process feel blocked by an internal demand for a specific release cadence. Businesses may want to work according to a specific release frequency for any number of legitimate reasons — the compliance team may ask to look over new development work, your QA team may want time to test work before it’s released, or any releases may have to pass through a Change Advisory Board before they can be deployed to production. And because these reasons are legitimate, they should be seen as harmonious with, not a hindrance to, agile development.
Rather than seeing a fixed release cadence as a bottleneck in your release pipeline, it can become an integral, defined stage by adopting release branches in your Git strategy. Read on to learn how you can balance the agility of a CI/CD pipeline with the risk mitigation of a weekly or bi-weekly release cadence.
Speed vs. security
At its core, CI/CD promotes the practice of regularly merging work back into your main branch and automatically testing the latest changes. However, it’s easy to forget that accelerating releases isn’t the only goal of CI/CD. While it’s true that some teams may use CI/CD to release to production multiple times a day, many teams won’t feel comfortable with this cadence.
Even if your team is more cautious, it’s important not to go too far in this direction. Teams that “sit on” work, allowing a release to swell as they wait for the assigned release date, are unnecessarily preventing their end users from experiencing the value of the delivery.
The best release management process is one that finds the golden mean between speed and security. Where this balance lies varies by team, but larger teams are more likely to answer to an organization-wide compliance framework that places emphasis on security rather than speed. In this situation, adopting release branches allows you to maintain the agility of continuous integration while still meeting compliance and accuracy concerns within your release plan.
Git branching strategies and release branches
While you need to be using version control in order to establish a CI/CD process, all Salesforce teams differ in their preferred Git branching strategy. The good news is that if you want to try using release branches, you can add them to any existing branching model.
Let’s take a simple feature branch model and see how it would look after introducing release branches. As usual, begin by creating a feature branch from main and completing your development work. When this development work is complete, you’d usually merge this feature branch back into your main branch. Instead, you’ll need to create a release branch from the main branch and merge the feature branches into this. You can merge any number of feature branches into this release branch.
As this is part of a CI/CD process, it’s still important to merge work early and often into the release branch, so that merge conflicts are dealt with during the sprint — not just before the release window!
Once the feature branches have been merged into the release branch, it can remain open for as long as needed to fit with your release management process. You may want to merge the release branch into main when:
- Testing requirements have been met;
- A predetermined release date approaches; or
- The agreed upon features for the release have been developed.
Even with a careful release testing process, bugs and errors are never going to be eliminated entirely. You can address these quickly by creating hotfix branches and merging them directly into main, without going via a release branch.
What are the benefits of using release branches?
Having a set release cadence allows more time for checks before each release, mitigating risk in your release process while keeping your development cycle agile. Release branches also bring together projects and work streams into a single branch for testing, before merging anything back into the main branch. Many businesses still prefer to deploy to their live Salesforce environment on an agreed release schedule. Release branches facilitate this predictability for your end users while keeping flexibility for your developers.
The biggest benefit of using release branches is that they can be integrated into a CI/CD workflow, allowing you to introduce automation to your release process.
While release branches effectively hold back development until the end of each sprint, it’s worth pointing out that some long-term projects should be held back for even longer — and these work streams can be managed somewhat separately from the main pipeline.
How do release branches fit with CI/CD?
Including release branches in your pipeline can allow you to fulfill both the “CI” and “CD” aspects of CI/CD — continuously integrating your development work and continuously delivering work to your end users. They can also make continuous deployment less risky.
Release branches and continuous integration
When you merge your feature branch into a release branch, your continuous integration processes will be triggered. It’s particularly useful to have your unit tests triggered, which can help you meet the Salesforce requirement that 75% of your Apex code in a final release should be tested.
Further, continuous integration can be used for automated builds of your release branch. This will help ensure that the work within the release branch is in a deployable state.
Release branches and continuous delivery
Release branches can help teams fulfill the overarching aim of “continuous delivery” — delivering value to end users as soon as possible. Once your development team has combined their changes into a release, they can move on to work on new development work while your automated testing checks that the release itself is viable. This avoids wasting development time on ad-hoc troubleshooting on release day.
While development work does then sit in a release branch for pre-release checks, meaning it’s not immediately delivered to the end user, for larger teams this process is faster than completing testing on isolated feature branches because changes can be combined, checked for conflicts and validated in advance of deployment day. Ultimately this will reduce risks on release day, making the release process far faster.
Release branches and continuous deployment
Finally, release branches can also enable teams to “continuously deploy” their work. While teams working in a traditional feature branching model may be rightfully nervous about automating the final deployment to production, release branches can ease these concerns. By continuously validating your release branch, you can check that your code meets your security and performance requirements ahead of the next automated release.
As continuous integration and testing ensure that all the work in a release branch is at a deployable standard, automating this final deployment to production is far less risky than automating a deployment from a regular feature branch.
Incorporating release branches into your release pipeline can enable automation that teams may otherwise avoid for fear of the risks attached. So, you’ll be able to reap the agility of CI/CD while still mitigating risk in your release management process.
How to integrate release branches within a CI/CD pipeline
You can build a CI/CD process that includes release branches using Gearset’s DevOps automation tooling. Our Pipelines tool supports the use of release branches within both a feature and expanded branch model.
Gearset allows you to create a release branch from the last environment in your pipeline. You can do all of this within Pipelines — just click on an open feature in the Open pull requests tab and click Create release.
You’ll then be prompted to choose a release branch name, before you can click Merge into release to create the release branch.
Gearset will automatically create a new release branch from the main branch and begin to merge the selected open feature branches into the release branch. After this, Gearset will create a new pull request from the release branch to your target environment, which is usually main.
You can handle any merge conflicts between your release branch and main from within the Pipelines UI. You’ll also be able to view all of the changes included in the release and the combination of components ready to deploy. Once the release branch has been merged, it will automatically be deleted.
Ready to get started?
A release branching strategy can help you to mitigate risk in your release process, while still reaping the benefits of agile development work. With Pipelines, Gearset’s Salesforce CI/CD solution, it’s possible to establish release branches as a stage in your CI/CD pipeline! If you’re ready to start using release branches within your CI/CD pipeline, start a free 30-day trial of Gearset today. Or get in touch to book a tailored demo with our team.
