Deployment strategies

Replacing a running service with a new version is its own problem: do it wrong and users see errors or downtime. Several deployment strategies let you ship safely, and all of them prize one thing above cleverness — the ability to undo quickly.

The strategies

• Rolling: replace instances a few at a time. Old and new run side by side briefly; no downtime, but both versions are live at once (so they must be compatible).
• Blue-green: run two full environments. "Blue" serves traffic while you deploy to idle "green"; flip traffic over once green is verified. Rollback is just flipping back — instant.
• Canary: release to a small slice of users first, watch the metrics, then widen if healthy. Limits the blast radius of a bad release.

Each trades cost and complexity for safety. Canary gives the earliest warning; blue-green gives the cleanest rollback; rolling is the simplest default.

Rollback beats perfection

You will ship bad releases — everyone does. The mature goal isn't zero defects; it's mean time to recovery. A team that can roll back in 30 seconds is far safer than one that deploys rarely and panics when something breaks. Make rollback a tested, one-command path, not an improvisation.

Deploy ≠ release

A powerful idea: deploying code and releasing a feature are separate events. Ship the code dark behind a feature flag, then turn it on for users when ready — and off instantly if it misbehaves. This decouples the risky act (deploying) from the visible one (releasing), and turns "roll back the deploy" into "flip the flag."

Where to go next

Both strategies assume you can configure the new version per environment. Next: configuration and environments.