A rollback returns production to a previous known-good version. It is easiest when builds are immutable and previous artifacts are available.
Rollbacks are unsafe when the new version already changed data in a way old code cannot read.
TIP
If rollback is risky, a small forward fix may be safer than deploying old code.
Further Learning
“deployment rollback strategy” — release recovery
“immutable build artifacts” — reliable versions
“rollback database migration risks” — data compatibility
Rollbacks
Sometimes a new release breaks something. A rollback means going back to the last known-good version — your emergency exit. Having this ready before you need it is what turns a scary incident into a quick, calm fix.
The easy case
If your builds are saved and don’t depend on anything that’s changed, rolling back is simple: just redeploy the previous version. This works cleanly when nothing about the data has changed — only the code.
The tricky case: when data already changed
WARNING
If the new version already changed data in a way the old code can’t understand, a rollback isn’t safe anymore — the old code might crash or corrupt things when it hits the new data shape. In that situation, a small forward fix (patching the current version) is often safer than reverting.
Practice it before you need it
TIP
Test your rollback process on a calm day, not during a real outage at 2am. If nobody’s ever actually run the rollback command, you don’t really have a rollback plan — you have a hope.
In one sentence
A rollback returns to the last known-good version — easy when only code changed, risky when data already changed in a way old code can’t read — and you should practice it before you actually need it in an emergency.
Want to go deeper?
Switch to Expert mode above for immutable build artifacts and database rollback risks.