Release Line
A Pattern for tracking what's deployed and (rarely, if you really need to) deploying a fix.
When developing from the Main Line, you want to know what you released, for historical and support reasons. You might also need to occasionally provide patch or hot fix releases for critical issues. This pattern describes a structure that can help you identify what was released and enable emergency changes to currently released code in the rare instance that you cannot deploy from the Main Line quickly enough to meet business needs.
Identification and Handling the Unexpected
Identification and reproducibility are essential elements of a code line process. Released software is usually identified by a commit on Main Line. A Tag should be sufficient to identify the released code, but many CI mechanisms work off changes to a branch.
While the goal is always to release from the head of the Main Line you may not always be able to deliver from the Main Line quickly enough to address a critical business issue. Some reasons for this could be:
You don’t yet have a full continuous deployment to production; you release at the end of a development iteration, and you are not yet confident in your ability to support or thoroughly test work in progress before the end of the cycle.
Your software follows a regulated process that requires that a process be followed for changes. That process allows for less overhead for minor patch releases than for a release with additional changes.
None of these situations is ideal, and while you can work to avoid the need for patch release, they happen.
You can try to avoid unplanned releases. Not all errors are truly critical emergencies. However, some changes cannot wait for the next release at the end of the planning cycle.
You want an was to identify what was released so that you can debug any issues that arise in the deployed code, and have a simple way to provide an emergency fix if needed.
Branch on Release
When deploying code to any environment, branch (or tag) to create a Release Line. This branch identifies the released version. You can add changes to the branch should you need to deploy a fix before the next regular release cycle. Limit the number of active release lines to 1. Patch releases should be rare.
A Release Line starts from the Mainline. Its purpose is to identify a released version of the software. Usually, a Release Lineshould have no commits added to it, and the branch ends when the next release line is created. The Release Line could be deleted after the next release is deployed, but we often keep it around for review, audit or compliance reasons. Limit the number of deployed release lines, ideally, to 1.
When you are ready to release (or after each merge to the Main Line passes any required checks if you are using a Continuous Deployment approach):
Tag the version with a meaningful name
Optionally create a branch off of that tag.
In the rare event that you need to make a fix to a Release Line :
Create a branch from the release tag if one does not exist.
Checkout a “fix” branch
Make changes and mere to the release line after a review/test cycle
Incorporate the changes to the Main Line either:
Merge the post-deployment version of the Release Line to the Main Line
Apply analogous changes to the Main Line using a new Task Branch. There may be some cases where the changes are no longer relevant to the code on the Main Line.
Or
Use with a Periodic Release Model
Sometimes, business or other constraints limit the rate at which you can deploy code to production. For example, some regulated systems have documentation workflows to follow, and while you can speed them up, you may not be able to eliminate them. For some App Store deployments, there may be an approval process.
For validated and other systems that require deployment gates, a Release Line is a mechanism to balance an agile continuous integration workflow with controlled software release. After each commit to the Main Line, code is deployed to a pre-production environment using the usual deployment workflow. Emergency releases with small changes can often use a shorter validation test suite and have a smaller documentation requirement.
Pre Release Environments
If you use pre-release environments, each environment branch is a release line. If you have more than one (dev, stage, prod) ideally each should start from the same point on the Main Line. If you are using a time-boxed development cycle, aim to deploy to the production environment one or more times per cycle to avoid pre-release stages from diverging from each other.
Cautions
While using the Release Line for identification is valuable, and having a safety net for patch releases useful, you don’t want to make patch releases a habit. Be thoughtful when releasing a hotfix and aim to reduce the interval between deployments as much as your process and business environment allows.
Patch or hotfix releases should be rare, and each instance should motivate you to make them less necessary. Ideally, see if you can identify mitigations or other workarounds that allow you to delay the fix until the Main can be deployed. Even in regulated environments, you can use a process that allows for rapid deployments from the Main Line.
It’s worth repeating that:
Release Lines should rarely accept changes
There should be only one release line, to the extent possible
Next Steps
Document (and automate) the Codeline Policy that applies to the Release Line
Getting Started
The concept of a release tag exists in most all codeline models, as Identification is a core attribute of a Software Configuration Management system. To move towards this pattern you need to deploy code from the Main Line and tag the version there.