Progressive delivery
Blue/green, canary, rolling, automated rollback.
Shipping often is only safe if each release limits its blast radius and can be undone fast. Progressive delivery strategies — blue/green, canary, rolling — plus automated rollback are how a DevOps team deploys frequently without frequent outages.
The strategies and their trade-offs
All-at-once replaces everything simultaneously — fastest but highest risk, since a bad version hits all traffic. Rolling updates instances in batches, keeping the rest serving, which limits impact but briefly runs mixed versions. Blue/green stands up a complete new (green) environment alongside the old (blue), shifts traffic once healthy, and keeps blue for instant rollback — safest but doubles resources during cutover. Canary exposes the new version to a small percentage of traffic first, watches metrics, then ramps up — the best blast-radius control for gradual confidence. You choose based on risk tolerance, cost, and how quickly you need to detect problems; canary and blue/green are the professional defaults for production.
# STRATEGY BLAST RADIUS ROLLBACK COST# all-at-once ALL traffic redeploy old low# rolling one batch at a time redeploy old low# canary small % first shift back low–med# blue/green 0 until cutover instant (blue) high (2x briefly)## Production defaults: canary or blue/green + automated rollback on alarms.
Automated rollback and confidence
The strategy is only half the safety story; the other half is automated rollback tied to observability. Bind every deployment to CloudWatch alarms on the signals that matter (error rate, latency) and health checks, so a degradation automatically reverts to the last known-good version within minutes — no human required. Bake validation into the deployment (smoke tests at appspec/lifecycle hooks) so a broken release fails before it takes traffic. The combination — progressive exposure to limit who sees a bad version, plus alarm-triggered automatic rollback to end its exposure fast — is what gives teams the confidence to deploy many times a day. Frequent, small, reversible changes are safer than rare big-bang releases precisely because each one is contained and recoverable.