Rollback
Restoring the last known-good release when a deploy goes wrong, instead of scrambling to fix it live.
See it
What it is
A rollback restores the last release that was known to work. How it happens depends on the platform. Hosts that keep previous builds warm make it a pointer flip: you change which already-running version traffic hits, and nothing gets rebuilt. Elsewhere it means pulling a stored artifact or image back out of the registry and redeploying or restarting on it, which takes minutes rather than seconds. Either way the goal is the same, get back to known-good, and it beats fixing forward at 2am when you are tired and the fix is untested.
Reach for it the moment a deploy causes user-visible breakage and the cause is not obvious within a few minutes. Roll back first, diagnose second, on a calm branch with the site healthy. Teams with automated rollback wire it to a post-deploy smoke test or an error-rate alert, so a bad release reverts itself before anyone is paged.
The big gotcha: code rolls back cleanly, data does not. A migration that dropped a column or rewrote rows leaves the old build talking to a schema it has never seen, so the 'safe' rollback becomes the outage. Ship schema changes in backward-compatible steps (add the new column, dual-write, remove the old one in a later release) and keep half-finished features behind a feature flag, which you can flip off instantly without touching the deployed build at all.
Ask AI for it
Add a rollback path to this project's deploy process. Keep the last five builds immutable and instantly promotable, give me a single documented command that promotes the previous known-good build back to live, and run a post-deploy smoke test (homepage plus health endpoint plus one critical flow) that triggers an automatic rollback when it fails. Audit the database migrations for anything that is not backward compatible and rewrite them as expand-and-contract steps so the previous build still runs against the new schema.