Release Management
Release management is the control of what changes go into production, when, and under what approval. It covers the release calendar, environment promotion, build and version control, approval gates, freeze periods, deployment and rollback. On a project it is the discipline that stops one team's change breaking another team's testing.
What it contains
Release management has four components. A calendar of planned releases with content and dates. An environment path — typically development, test, integration, pre-production and production — with rules for what may be promoted and by whom. A record of what is in each release: the changes, the versions, the configuration and the database scripts. And an approval process, defining who authorises a promotion into each environment.
Two further elements matter around a major go-live. Freeze periods, during which unrelated changes are blocked so that the environment the programme tested against is the environment it deploys to. And a rollback position for each release, which is not the same as a backup — it is a documented reverse sequence with timings, as described in the guide to writing a rollback plan.
How it is used
During delivery, release management is mostly environment arbitration. Multiple workstreams need builds deployed to shared environments at different times, and testing needs a stable target for long enough to produce meaningful results. The release calendar is where those competing needs are resolved, and it is a standing dependency for every stream.
Approaching go-live, the release process tightens. The change freeze is announced with a date and a scope, exceptions require named approval, and the content of the production release is fixed and documented. That documented content is what the cutover runbook executes — the runbook is, in effect, one release performed under a stopwatch.
The approval to deploy is recorded at the go/no-go meeting rather than assumed. Readiness of the release itself — built, tested, deployable, reversible — is one line on the readiness checklist among several.
After go-live, release management resumes on a normal cadence, but with the first few releases usually reserved for defect fixes coming out of hypercare.
Where it goes wrong
The common failure is undocumented environment drift. Configuration is changed directly in test to unblock someone, the change is never captured, and production is deployed from a build that has never run in the configuration it will meet. The symptom is a deployment that works everywhere except production.
The second is a freeze declared but not enforced. Business-as-usual changes continue under exception, each individually reasonable, and the programme loses the stable baseline it was testing against.
The third is release content that nobody can state precisely. Asked what is in tonight's release, three people give three answers. Version control answers this question mechanically; informal deployment does not.
The fourth is rollback assumed rather than tested. A rollback that has never been rehearsed is a plan, not a capability, and the difference becomes apparent at the worst possible time. The rollback template exists to force the two things most plans omit: the triggers that start it and the point after which it is no longer available.
Related terms
Deployment window is the agreed period in which a release may be installed. Change freeze blocks unrelated changes around a major release. Environment promotion is moving a build up the environment path. Rollback is the reverse sequence returning to the prior state. Cutover is the specific, heavily sequenced release that takes a new system live.
Questions
What is the difference between release management and deployment?
Deployment is the technical act of installing a release. Release management is the wider control of what is in the release, when it goes, who approves it and how it can be reversed.
Why is a change freeze needed before go-live?
So that the environment tested is the environment deployed. Unrelated changes during the final weeks invalidate testing that has already been completed.
How long should a freeze last?
Long enough to protect the final test cycles and the cutover itself. The scope of what is frozen matters more than the duration — security patching is usually excepted.
Should rollback be tested?
An untested rollback is an assumption. Rehearsing it, at least once, is what turns the documented sequence into a capability.