Hotfix Branches

Hotfix branches allow developers to quickly fix critical issues in a production environment by working with the exact code deployed in production. Once the code is fixed, it can be quickly tested and deployed, and later merged into the main code. Like feature branches, hotfix branches prevent interfering with ongoing development.

There are a few options for integrating hotfix branches into your CI/CD pipeline. In this article, we'll discuss:

• Creating hotfix branches in Git that work best with automation
• Using hotfix branch pipelines in BuildMaster to accommodate these branches
• Monitoring existing and new feature branches to create builds

Using Hotfix Branches in Git

A hotfix branch should be created from the commit that's currently deployed to production. Generally, this commit will be tagged with a version number to make it easier to find.

For example, if you needed to fix SAML-based logins, you might do the following:

1. Identify the production tag or commit (e.g. 4.2.1 or f839162)
2. Create a new branch from that point (hotfix/4.2.1-saml-login-fix)
3. Write code and commit the changes to this branch
4. Push the branch to your Git server
5. Collaborate with other developers and testers to verify the fix
6. Deploy the hotfix code to production
7. Tag the commit with the new version number (e.g. 4.2.2)
8. Optionally, merge into a main branch
9. Delete the hotfix branch

In some cases, merging the code back into a main branch will be unnecessary. The issue may have already been addressed in the in-development release, or a new feature would have made the fix impractical to merge.

Using Hotfix Branches in a CI/CD Pipeline

To test hotfix changes, production-ready builds should be created in hotfix branches. These hotfix branch builds should be deployed to production. Unlike builds created from the main or development branch, they are guaranteed to have minimal changes from production code.

Creating a Hotfix Branch Pipeline in BuildMaster

BuildMaster includes a Hotfix Branch Pipeline template to help you get started. You can customize any aspect of the pipeline you need, or even create the same pipeline from scratch.

The Hotfix Branch Pipeline template includes the four default stages:

The stages work mostly like they would in other pipelines: the Build stage will run a Build script, and the Integration, Testing, and Production stages run a Deploy script.

Unlike most pipelines, in this template the Deployment Eligibility option is set to not enforce pipeline the stage order for deployments. This setting means that you can deploy to any stage without having successfully deployed to a previous stage, which is often desirable for hotfixes. For example, a build that uses this pipeline could skip Integration, and go from Build to Testing to Production.

To help mitigate an accidental deployment, deploying into Production requires an approval.

After a build is deployed to Production, you must manually set it as deployed.

Monitoring Git for New Hotfix Branches and Commits

You can configure a Git Repository Monitor to automatically create new builds when a new hotfix branch is created or a commit is detected on a hotfix branch.

To do this, navigate to Settings > Resource Monitors in your application and click Add Monitor. After selecting Git Repository Monitor from the list, you can specify a branch filter that uses a wildcard expression such as hotfix/*`:

The expression hotfix/* will create a build when a new branch that starts with hotfix/` is detected, or if there are any new commits to such a branch.

If you need to monitor multiple branch patterns, just create additional repository monitors.