Release vs Change Management

Change management exists to make risk visible before it lands. Its useful output is a record of what is being modified, what could break, who is accountable, and how it gets undone. Release management assumes that decision has been made and asks a different question: what ships together, in what order, and behind which controls.

Release management exists to make delivery repeatable. Its output is a versioned, tested artefact and a plan for getting it into production in a known order. The valuable parts are build reproducibility, sequencing when components depend on each other, and a rollout strategy that limits exposure.

They overlap because shipping a release is itself a change, and because a single change may require several releases across components. That overlap is where most process friction lives. A team asked to raise a change record per commit is answering a governance question with a delivery artefact, and the record stops meaning anything. A team that ships a hundred commits as one release and calls it one change has technically satisfied the process while destroying the thing it was for, because nobody can say which modification caused the failure.

Batch size became the main risk control. A small change deployed alone is diagnosable. If the error rate moves, the cause is obvious. That property does more for reliability than any approval step, and it is a release management decision, not a governance one.

Pre-authorisation replaced per-change approval. The workable pattern is to define classes of change that are authorised in advance because the pipeline enforces the conditions: tests pass, the change is behind a flag, the rollout is staged, rollback is automated. Novel or high risk change still gets human assessment. This keeps the control meaningful precisely because it is not applied to everything.

The release record became the audit trail. A pipeline that stamps each release with its commits, reviewers, test results and deploy time answers the auditor's question without a parallel ticket, provided the release is the unit being recorded rather than a bundle labelled after the fact.

Progressive rollout made blast radius a first class concern. Staged deploys, canaries, and flags convert a binary question into a gradient, so the interesting number becomes how many users saw the bad version and for how long.

Keep the records distinct and linked. A release should reference the changes it carries, and a change should reference the release that delivers it. This is what lets you answer the only question that matters after an outage: what went out, and which part of it caused this.

Measure change as an incident cause. If your close codes capture change related failures, you get a change failure rate for free, and it is the number that should drive how much control each class needs.

Put the backout plan where the responder will find it. A rollback documented in a change record nobody opens during an outage is not a rollback plan. It belongs where the on-call engineer already looks.

Do not use emergency change as the normal path. When the fast route is to declare an emergency, that is a signal the standard route is too slow, and the fix is to shorten the standard route rather than to keep granting exceptions.

Review the classification, not just the changes. The risk classes themselves should be revisited against what actually caused incidents. Classes that never fail absorb review effort for nothing.