Skip to content

10. Hotfix
What The fast, controlled path for urgent fixes to issues already live in production.
Owner Engineering (fix), DevOps (deploy), with Support and Management coordination.
Triggers A production issue that cannot wait for the normal release cycle.

Summary

A hotfix is for production issues that must ship as soon as possible, outside the normal sprint and release flow. It branches from the last production tag (not from develop, which may contain unfinished work), increments the patch version, and otherwise follows the same disciplines as a normal release: work happens on branches through pull requests, QA verifies, the result is tagged, and it merges back into master and develop. The hotfix path is faster, not looser.

Full detail

When to use a hotfix

Use a hotfix only when an issue is already in production and the fix cannot wait for the next normal release. Severity is assessed with the Production Support process: critical issues affecting all users or causing downtime are the typical triggers. Anything that can wait goes into the normal release cycle instead.

The hotfix branch flow

  1. Create the hotfix branch from the last production tag, not from develop: tag/<production-version> becomes hotfix/<version> (for example tag v1.3.0 becomes hotfix/v1.3.1).
  2. The hotfix version increments the patch number and MUST match its JIRA Hotfix Release version.
  3. Do the actual work on bug/<ticket> (or feature/<ticket>) branches cut from the hotfix branch, merged back through reviewed pull requests. Never commit directly to the hotfix branch.
  4. QA verifies the fix (scope is narrower than a full release but the same gate applies: impact analysis, targeted regression around the change).
  5. Tag the hotfix with the production version, deploy after Support and Management coordination, then merge into master and develop.
gitGraph
    commit id: "v1.3.0" tag: "v1.3.0"
    branch hotfix/v1.3.1
    checkout hotfix/v1.3.1
    commit id: "cut hotfix"
    branch bug/ABC-1400
    checkout bug/ABC-1400
    commit id: "urgent fix"
    checkout hotfix/v1.3.1
    merge bug/ABC-1400 tag: "PR + QA"
    checkout main
    merge hotfix/v1.3.1 tag: "v1.3.1"

Versioning

Hotfix versions increment the patch number: v1.3.0 becomes v1.3.1, then v1.3.2, and so on. Each hotfix has its own JIRA Hotfix Release with the matching version, and the same close-out rules apply (close the release the same day, no reuse of version numbers).

Same close-out discipline

After deploy, a hotfix follows the same Release Close-out: merge into master and develop, merge into or inform other active release branches, close the JIRA Hotfix Release the same day, and tell other developers to pull the new tag. Skipping this is especially dangerous for hotfixes, because the urgent fix can silently disappear from the next normal release if it is not merged back.

Example

Production v1.3.0 has a payment-confirmation bug affecting all clients. A hotfix is approved. The team cuts hotfix/v1.3.1 from tag v1.3.0, then bug/ABC-1400 from the hotfix branch. The fix is reviewed, QA verifies it and runs targeted regression on payments, and it is tagged v1.3.1. After Support and Management coordination, DevOps deploys it. The team merges hotfix/v1.3.1 into master and develop, closes the JIRA Hotfix Release, and tells everyone to pull v1.3.1.