Rollback
The process of reverting a production deployment to a previous known-good version when a release introduces critical issues that cannot be quickly fixed.
A rollback restores the application to its previous state, effectively undoing a deployment. The ease of rollback depends on the deployment strategy: blue-green and canary deployments support near-instant rollback via traffic switching, while traditional deployments may require re-deploying the previous artifact. Database rollbacks are more complex because data migrations may not be easily reversible.
Teams should regularly test their rollback procedures to ensure they work under pressure. A rollback plan that has never been practiced may fail when it is needed most.
Why It Matters for QA Teams
Rollback is the emergency brake for production issues. QA teams should verify that rollback procedures actually work and understand the implications for data consistency and in-flight user sessions.
Example
A release introduces a database schema change that causes all product pages to return 500 errors. The team initiates a rollback, but the new schema migration has already altered the database. A simple code rollback is not enough; the team also needs to run a reverse migration script. The incident leads to a policy of testing rollback procedures, including database reversions, before every release.