"Deploy" can mean several genuinely different mechanisms, each with a different risk profile for the moment the new version goes live:
| Strategy | How it works | Rollback speed | Cost |
|---|---|---|---|
| Recreate | Stop the old version, start the new one | Slow — redeploy the old version | None extra — simplest |
| Rolling update | Replace instances one (or a few) at a time, old and new versions both serve traffic briefly | Moderate — halt and reverse the rollout | None extra |
| Blue-green | Deploy the new version fully alongside the old one, then switch traffic all at once | Instant — switch traffic back | Double the infrastructure while both exist |
| Canary | Route a small percentage of real traffic to the new version, increase gradually while watching for errors | Fast — pull the canary out of rotation | Some — needs traffic-splitting infrastructure and monitoring per version |
Rolling updates (the default in most container orchestrators, including Kubernetes) mean there's a window where old and new versions of the application are serving traffic simultaneously — this makes backward-incompatible changes (a new version expecting a database column an old version's code doesn't know about yet) a real, common source of incidents, which is why database migrations for a rolling-deployed system generally need to be backward compatible with the previous version for the duration of the rollout, not just correct for the final state.
Blue-green avoids that mixed-version window entirely by cutting over all at once, at the cost of running two full copies of the infrastructure during the switch. Canary deployments are the most cautious option — they accept a little bit of mixed-version exposure (a small traffic percentage) specifically to catch a bad deploy against real production traffic and real production data patterns, which staging can approximate but never perfectly replicate, before it's rolled out to everyone.