Rollbacks: when the deploy goes wrong

Deploys fail. Plan for it

Some bug will pass your tests and reach production. The professional metric is not "never break", it is time to recover. And containers make recovery beautiful:

A rollback is just deploying the previous image tag. Because lesson 7-3 tagged every image with its commit hash and lesson 6-1's registry keeps them all, last week's known-good build is still sitting there, byte-identical:

docker pull ghcr.io/ada/shop:41a9c02   # the previous good build
docker stop web && docker rm web
docker run -d --name web -p 80:8000 ghcr.io/ada/shop:41a9c02

No rebuilding under pressure, no reverting commits at 3am first. Restore service in seconds, then fix the code calmly. This only works if tags are immutable (never overwritten), which is the real argument against deploying :latest from lesson 6-1.

Deploying without downtime

Stopping the old container before starting the new one leaves a gap where users see errors. Two standard patterns avoid it:

• Rolling deploy: run several identical app containers behind a load balancer, a small server that receives all incoming traffic and spreads it across the healthy containers (nginx from unit 2 is often exactly this). Replace the containers one at a time: users are always served by the remaining ones, and old and new versions briefly serve together
• Blue-green: run a full new copy (green) next to the current one (blue), test it, then flip traffic all at once. Rollback is flipping back, instant

Both patterns depend on the platform knowing whether the new version is actually healthy before sending it traffic. That signal is the health check, and it is the centerpiece of lesson 9-2.