# Release Management

This guide covers creating and managing release branches, and understanding the release branch locking process. Release branches are under the release folder in ADO and contain the naming convention of release/YearMonth eg: (release/2512) for December 2025 releases.

At the start of each sprint or release cycle, the team lead creates the next release branch.

Source branch selection:

• If the previous release is locked (promoted to pent), create from the latest locked release branch.
• If the previous release is not locked, create from prod1.

This ensures final changes and hotfixes from the last cycle carry forward.

Create from prod1 (Previous Release Not Locked)

git checkout prod1
git pull
git checkout -b release/2505  # Next release branch
git push -u origin release/2505

Once a release branch has been promoted to the pent environment, that release branch is considered locked.

After lock:

• No new features or general changes may be merged.
• Only fixes required for upper environments are allowed, following hotfix procedures or controlled PR procedures.

Locking a branch prevents other users from changing the existing commit history. This is a way for us to say this is the checkpoint that the infra team will use to deploy.

Future Direction: We're moving towards using tags with versions to deploy instead of blocking and unblocking branches. This will provide more granular control and clearer deployment history.

For critical bug fixes after lock, follow the Hotfix Process:

1. Cut a hotfix from the latest release branch (e.g., release/2504.1).
2. Deploy to the required environment(s).
3. Merge the hotfix back into the locked release branch and forward into the next active release branch.

Sprints and releases share numbering for coordination (e.g., release 2504). The name of the sprint is using a number (eg. 122) but each user story, bug, etc will be tagged with the release number (2504)

Typical flow:

• Feature branches merged into release/*.
• Release is validated then promoted through lower and upper environments via PRs and approvals.