Part 9 · 1 chapters · ~8 min
Rollback, Roll-Forward and Release Engineering
When to roll back and when to roll forward, what makes rollback unsafe (migrations, data written by the new version, external side effects), practising rollbacks, release trains versus continuous deployment, deploy freezes, and release engineering as a role.
10
Rollback or roll forward
| situation | choose | why |
|---|---|---|
| bad code, compatible schema, no new data shapes | roll back | fastest path to known good |
| new version already wrote data the old version cannot read | roll forward with a fix | rollback would break on the new data |
| a destructive migration ran | restore or roll forward | code rollback cannot bring dropped data back |
| external side effects (emails, payments) already happened | roll back the code, then compensate | side effects need their own repair |
| feature problem behind a flag | flip the flag | no deploy at all |
making rollback safe
- Follow expand and contract, so the previous version always works with the current schema.
- Practise: roll back a harmless deploy every few weeks so the path is known and fast.
- Keep the previous artifact and its config ready; never rebuild to roll back.
- Decide in advance who can call a rollback (anyone on call, without asking).
Release engineering as a role owns the pipeline, the release calendar, freezes (tied to error budgets, SRE part 5), versioning and changelogs, and the tooling that lets product teams deploy safely many times a day.