阅读中文版本

Release Freeze Window Workflow

Declare and enforce a freeze window with exceptions and a documented rollback plan so risky changes do not land before a key event.

Overview

Protect a critical period by freezing risky changes with controlled exceptions.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

• Change management tooling
• Branch protection rules
• A list of critical events

Procedure

1. Announce the freeze window

Publish the freeze start and end with the events it protects and the exact rules.

Expected state: Teams know what is frozen and when.

2. Enforce via branch protection

Restrict merges to allow only pre-approved exception labels.

Expected state: Unapproved merges are mechanically blocked.

3. Process exceptions explicitly

Review each exception request for risk and require a rollback plan.

Expected state: Every landing change during the freeze has an owner and rollback plan.

4. Exit the freeze deliberately

Unfreeze only after the protected period, then allow the backlog to resume.

Expected state: Normal changes resume with a clear end to the freeze.

# GitHub branch protection: require the 'freeze-exception' label
gh api -X PUT repos/org/app/branches/main/protection \
  -f required_pull_request_reviews.required_approving_review_count=2

Verification

Confirm that merges without exception labels were blocked and every frozen-period change has a rollback plan.

Decision points

Full freeze or only risky changes?

• Freeze only risky change classes
• Freeze everything

Recommendation: Freeze the risky classes; a total freeze blocks safe fixes too.

Who approves exceptions?

• Release manager
• Any approver

Recommendation: A single accountable release manager keeps exceptions consistent.

Common failures

• Undocumented freeze leads to accidental risky merges.
• No exception process blocks urgent fixes.
• Forgetting to unfreeze leaves teams stuck.