Know how a release reaches production
Record the path from a code change to a running application. Identify checks, configuration, secrets and the account permitted to deploy. Use a separate environment to review changes before customers see them, and keep the release process understandable to more than one person.
Release a booking change with a rollback decision
A small team changes how booking credits are stored. Reverting the application alone may not undo the database change. Use a rehearsal to check compatibility between the current and previous application versions.
| Gate | Evidence to proceed |
|---|---|
| Before deployment | Migration tested on a representative copy; backup restore rehearsed |
| Immediately after release | A test booking, cancellation and credit check all pass |
| Service limits breached | Named operator runs the documented rollback or stops writes for repair |
Choose checks that catch useful failures
Prioritise the customer’s critical journey and the operations that can lose data or money. A build check alone does not prove a checkout or booking still works. Bound automated jobs with time limits and stop superseded runs so release checks do not consume unlimited resources.
Practice recovery before an incident
Agree how to roll back an application and how database changes affect that decision. Test restoration from a backup rather than only checking that backup files exist. Alerts should identify an owner and an action, and support coverage must match the team’s actual availability.
Before you proceed
- Document the release path and account permissions.
- Test a critical journey and an interrupted release.
- Rehearse a restore and assign incident responsibility.
