Rollback
🏠The everyday picture
A tightrope walker uses a safety net, not because they expect to fall, but because the net lets them walk with confidence.
📘What it really is
- Every deploy needs a rollback plan: a quick way back to the last working version.
-
With versioned images, rollback is redeploying the previous tag:
./deploy.sh <previous-commit>. Keep a record of what was deployed when (a deploy log, or your CI history, Module 71). -
Database changes are the hard part. Code can be rolled back in seconds; data changes can't simply be undone. So:
- make migrations backward-compatible (Module 58): the old code must still work with the new schema;
- expand first, contract later: add new columns and tables, deploy code that uses them, remove old ones in a later release;
-
for risky data changes, take a backup immediately before.
-
Decide in advance when to roll back: for example, if error rates double or the health check fails after a deploy. Roll back first, investigate after. Users care about the site working, not about you finding the bug live.
-
Practise rollbacks on staging, so the first one isn't during an emergency.
🖱️Try it
Deploy a version with a deliberate bug to staging (a route that throws). Notice it in logs or error reporting, roll back to the previous tag with your deploy script, and time how long recovery took. Write the rollback steps in your operations notes.
✅Quick check
Why must database migrations be backward-compatible?
Show the answer
So the previous code version still works after the migration, keeping rollback possible.
After a bad deploy, should you fix the bug live or roll back first?
Show the answer
Roll back first to restore service, then investigate.