Deployment freeze
A defined stretch when routine production releases stop, usually because support is thin or the cost of disruption is unusually high.
What it is
A deployment freeze is a named period when routine production releases stop. Teams use one around holidays, major sales, financial close, or another stretch when fewer responders are available or the cost of instability is unusually high. Development can continue; the restriction is on changing the live environment. Retail and payments teams commonly freeze from the week before Black Friday until the first week of January.
Reach for it when the temporary operational risk is real and has exact start and end times. Publish the dates early, say which systems are in scope, and keep a narrow exception path for security patches and fixes to active incidents.
Gotcha: a long freeze stores up a large, risky release for the first day afterward. Keep building and testing small changes, deploy to staging, and reopen production gradually. A freeze without an emergency owner and an audited bypass can also delay the one change that reduces risk.
Ask AI for it
Add a deployment-freeze guard to the production job in GitHub Actions. Read UTC start and end timestamps plus affected environments from a versioned `deployment-freeze.yml`, fail the job before credentials are requested when the current time is inside a freeze, and print the active window and exception instructions in the workflow summary. Provide a separate workflow_dispatch emergency path protected by the GitHub Environment named production with required reviewers and prevent self-review enabled, plus a required nonempty incident or CVE reference input. Record the actor, reason, commit SHA, artifact digest, and approvals, and add tests for boundaries, UTC parsing, and an expired window.