Design a hotfix path plan

A hotfix path is the answer to: production is broken, the fix must ship now, and main contains half-finished work that must not go with it.

Release-first shape

When the deployed version is maintained on a release branch and main contains unreleased work, branch from that release line, PR the fix back, and deploy it. Then create a branch from main, cherry-pick the exact fix, and use a second PR. Do not merge the whole release branch into main, because that can import release-only changes.

This is not the only valid direction. Microsoft also documents a main-first flow: PR a fix branch into main, cherry-pick that change into the current release branch, and deploy from the release branch.

Control points

1. Keep both maintained lines fixed. A release-first fix that never reaches main can disappear from the next release.
2. Port the exact change. Use a targeted cherry-pick and PR rather than merging the release branch wholesale.
3. Make emergency validation risk-based. Keep safe deployment practices and high-risk, low-cost checks; a predefined emergency process may shorten or modify lower-risk, costly steps.
4. Predefine authorization and retain the audit trail. A supported Azure Pipelines check bypass requires Administrator permission on the checked resource, and the checks panel records who performed it. Document high-impact incident actions.

Primary sources

• https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance
• https://learn.microsoft.com/en-us/devops/operate/how-microsoft-operates-devops
• https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals
• https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/maturity-model
• https://learn.microsoft.com/en-us/azure/well-architected/design-guides/incident-management