CLOUD & DEVOPS / CI/CD
A Practical Guide to Deployment Strategies
Blue-green, canary and rolling releases in plain engineering terms.
Key Insight: The right deployment strategy isn't the most sophisticated one available — it's the one that matches how expensive a bad release would actually be for your specific system. A blog with ten daily readers and a payments system have very different answers.
Deployment strategy conversations often jump straight to "we should do canary deployments" without first asking whether the system's actual risk profile justifies the added complexity. Each strategy is a real trade between deployment simplicity, resource cost, and how gracefully a bad release is caught and contained.
Rolling deployment: the sensible default
A rolling deployment replaces instances of the old version with the new version gradually — a few at a time — rather than all at once. At any given moment during the rollout, both versions are serving traffic simultaneously. This is the default in most container orchestration platforms (Kubernetes' standard deployment strategy is a rolling update) because it requires no extra infrastructure and provides a meaningful safety improvement over an all-at-once replacement: if the new version is badly broken, only a fraction of traffic hits it before the rollout is paused or reversed.
The real requirement rolling deployments impose, and the one teams most often skip: your application needs to genuinely support both versions running simultaneously and handling the same traffic and, if applicable, the same data — including database schema compatibility during the transition window. A rolling deployment with a breaking database migration mid-rollout is a self-inflicted incident.
Blue-green: full isolation, at double the resource cost
Blue-green maintains two complete, independent environments — one live (blue), one idle (green) — and deploys the new version entirely to the idle environment, testing it there before switching all traffic over at once, typically via a load balancer or DNS change. The appeal is a genuinely fast, clean rollback: if something's wrong, switch traffic back to blue, which never stopped running the known-good version.
The cost is real: you're running two full production-sized environments, at least during the deployment window, and any stateful component (a database, in particular) needs a careful strategy for how it's shared or synchronized between the two environments — this is usually the hardest part to get right, and the part most tutorials gloss over.
Canary: the most gradual, the most operationally demanding
A canary deployment routes a small percentage of real traffic — often starting at 1-5% — to the new version, while most traffic still goes to the old version, and gradually increases that percentage as confidence builds, based on real metrics from real production traffic. This is the strategy that best limits blast radius for genuinely risky changes, because a problem is caught while affecting a small fraction of users, not all of them.
The real cost is operational sophistication: canary deployments only work if you have strong, automated metrics comparing the canary's behavior to the baseline (error rate, latency, business metrics), and ideally automated rollback triggered by those metrics rather than a person watching a dashboard and hoping to notice in time. Without that instrumentation, a canary deployment is really just a manual, slower rolling deployment with extra steps.
Rolling: [old][old][new][old] → [old][new][new][new] → [new][new][new][new] Blue-green: blue (live) ←──switch──→ green (new, tested idle) Canary: 99% old + 1% new → 90% old + 10% new → ... → 100% newMatching the strategy to the actual risk
For most internal tools, low-traffic services, and systems where a bad release is annoying but not costly, a rolling deployment with solid automated tests and quick manual rollback is entirely sufficient — reaching for canary infrastructure here is solving a problem you don't have. For customer-facing systems where a bad release has real business or safety cost, and especially where changes are frequent enough that the investment pays off repeatedly, canary deployments with real automated metrics and rollback are worth the operational investment. Blue-green earns its place specifically when you need a very fast, very clean full rollback and can justify the doubled resource cost, often for systems with infrequent, high-stakes releases rather than continuous deployment.
Key takeaways
Rolling deployment is the sensible default — cheap, built into most orchestration platforms, and adequate when your application genuinely supports mixed-version operation safely. Blue-green trades resource cost for a fast, clean full rollback — worth it for infrequent, high-stakes releases. Canary limits blast radius the most, but only delivers real value with genuine automated metrics and rollback, not manual dashboard-watching. Choose based on your system's actual cost of a bad release, not based on which strategy sounds most sophisticated.