The Problem with Deploying Release Branches

There are plenty of online articles that talk about the different Git strategies, and some of these strategies include release branches, which are deployed to upper environments. The problem with doing that is the branch is not immutable, allowing late merges to be deployed when testing may have started, thereby throwing the release into chaos. Instead of having the pipeline deploy from a branch, I recommend teams deploy from Git tags instead, using semantic versioning to track bug fixes to the release branch.

In so many places, development teams are under constant pressure to deliver more and more features at a faster pace. Depending on the team structure, that can often mean that a feature doesn't get to testers until right before end of sprint, giving them precious little time to perform thorough testing on the new feature, or regression testing. Then, the team is merging bug fixes they discover late in the game into the release branch (and any other branches, depending on their Git workflow), leading to uncertainty on the state of the upper environments, where testing may have already started. In other words, the team is trying to slide changes under the door.

The intent with this article is not to dive into how to solve the team's work habits, e.g. observation of Definition of Done, but how to enable the business to better track how often this is happening and make it a metric for continuous improvement. If the pipelines are set to use Git tags, which are immutable, instead of Git branches, which are not immutable, then the process can use the PATCH (from semantic versioning) to track how often the release needs to be patched before it goes out the door. The more patches, the greater the evidence is that the process needs to be addressed.

A good visualization of the process can be found on the website for Release Flow.