| name | rollback-plan |
| description | Design a release rollback or forward-recovery plan from failure modes, state changes, data compatibility, trigger conditions, authority, execution steps, and validation evidence. |
Rollback Plan
Use before a release where failed deployment or behavior could require fast, controlled recovery.
Procedure
- Identify the release changes that can fail: binaries, configuration, schema/data, dependencies, feature flags, infrastructure, caches, or external integrations.
- Determine which changes are safely reversible and which require forward recovery because rollback could lose or corrupt state.
- Define trigger conditions for rollback/recovery using observable health, error, integrity, latency, or business-impact signals.
- Record the exact prior artifact/configuration/state required for rollback and confirm it is actually available.
- Sequence rollback steps including traffic, compatibility, migrations, workers, caches, and dependent services where relevant.
- Assign authority to initiate recovery and owners for technical execution, communication, and validation.
- Define how to verify restored service and data integrity, not merely successful deployment commands.
- Rehearse or dry-run high-risk recovery paths when practical and update the plan from evidence.
Decision rules
- Rollback is not always safer than forward repair.
- Schema/data compatibility determines whether old code can safely return.
- Do not wait for an incident to discover the previous artifact was not retained.
- Recovery criteria should be observable before the release starts.
Quality gate
The plan is credible when reversal versus forward recovery is explicit for each consequential state change, trigger signals and authority are known, required artifacts exist, execution is ordered, and validation proves service and data integrity after recovery.
