What is Rollback?

#How rollback works

The simplest form redeploys the previous artifact version. Faster forms avoid a deploy cycle entirely: blue-green switches traffic back to the environment still running the old version, and feature flags disable the new behavior without touching what is deployed.

The essential property is speed and reliability, not elegance. A rollback path that takes twenty minutes and occasionally fails is not a mitigation you can depend on during an incident, which is precisely when it will be used.

#Why rollback matters

Rollback works without requiring you to understand what went wrong, which is what makes it valuable under pressure.

• Cause independent: reverting works whether or not the defect is understood.
• Fast mitigation: user impact stops before diagnosis begins.
• Reduced pressure: the fix can then be developed calmly rather than in an emergency.
• Deploy confidence: a trustworthy rollback path makes teams willing to ship more often.

#Limits and things that cannot be rolled back

Database migrations are the hard case. Reverting application code does not revert a schema change, and a rollback into an incompatible schema fails or corrupts data. Expand and contract migration patterns exist specifically to keep rollback possible across schema changes.

Some effects are irreversible regardless. Emails sent, payments processed, external webhooks delivered, and data deleted cannot be undone by redeploying. Rollback restores code, not consequences, and changes that produce external side effects need a different safety strategy.

#Rollback vs roll forward

Rolling forward means fixing the defect and deploying the corrected version rather than reverting. It is appropriate when the previous version has its own serious problem, when the fix is trivial and well understood, or when rollback is genuinely impossible.

Rollback is the default under pressure because it is faster and lower risk. Rolling forward requires writing correct code during an incident, and code written in that state is more likely to introduce a second problem. The reasonable rule is to roll back first and roll forward once the situation is calm.

#Key takeaways

• Rollback mitigates without requiring the cause to be understood, which is why it is the default first action.
• The path must be fast and reliable, since it is used exclusively under pressure.
• Schema changes break naive rollback, which is why expand and contract migration patterns exist.
• External side effects such as sent emails and processed payments cannot be reversed by redeploying.

#Frequently asked

When should you roll back rather than fix forward?

Almost always during an incident. Rolling back is faster and lower risk than writing correct code under pressure.

How do you keep rollback possible across schema changes?

Expand and contract: add the new schema element, deploy code that works with both, migrate data, then remove the old element in a later release.

How often should rollback be tested?

Regularly, as part of normal deployment practice. An untested rollback path is discovered to be broken at the worst possible moment.