Release safety and recovery
Rollback as a minimum standard
Why an old binary alone is not a fallback and how to prepare the mechanism, data consequences, and decision separately.
The short answer
A rollback is more than redeploying an old binary. It needs to account for artifacts, reproducible deployment, compatible configuration, data changes, and external interfaces together.
The technical mechanism and the decision to use it are separate. The mechanism needs preparation and regular testing. Ownership, approval, observation, and abort criteria determine when it is used.
Decision context
A rollback fits when the previous version can operate safely with current data and neighboring systems and reduces risk faster than a forward fix.
A forward fix may be safer when returning would lose data, break interfaces, or take longer. Prepare this tradeoff before the release.
Signals in day-to-day operation
- The previous artifact cannot be found unambiguously or deployed again.
- Configuration changes are not versioned or linked to the application version.
- Database migrations have no tested compatibility and recovery plan.
- External interfaces or consumers cannot work with the previous version after a release.
Data and prerequisites
- Immutable, identifiable artifacts and a reproducible deployment path.
- Versioned configuration with secure handling for secrets and environment-specific values.
- A data strategy with backward compatibility, backup, restore, or a deliberate forward fix for every relevant migration.
- Known contracts for external interfaces and clear observation and approval criteria.
A step-by-step approach
- Describe the last compatible state for the application, configuration, database, and interfaces.
- Deployment and return use versioned artifacts and documented, repeatable steps.
- Review database changes for forward and backward compatibility. Running down migrations is not considered safe by default.
- Feature flags can separate feature release from deployment, but they do not replace a data strategy or artifact rollback.
- Test the complete process regularly in an appropriate environment and record timing, outcome, and open risks.
Outcome of the analysis
- A tested technical fallback with known limits for application, configuration, data, and interfaces.
- A separate decision process with ownership, triggers, approval, and observation.
Limits and boundaries
- There is no universal rollback architecture for every platform and data model.
- A database downgrade can lose data. It needs to be reviewed and tested for the specific schema.
- Feature flags protect only the paths designed for them and require maintenance, permissions, and a process for removing old flags.
- A successful technical test does not determine who may make the decision during an incident.
Questions to check
- The previous artifact is identifiable and deployable.
- Configuration and secrets match the target version.
- Data consequences and interface compatibility are reviewed.
- Rollback and forward fix have clear decision criteria.
- The complete fallback is tested regularly.
Sources and context
The sources support the technical context or define the scope of a related service. Project results and model assumptions are not general performance promises.