Deployment Strategies

Why the deploy stage needs a strategy at all#

The pipelines built earlier in this track end with a deploy job that pushes a new version out once build and test pass. What that job doesn't answer is how the new version actually replaces the old one while real users are hitting the system — replace everything instantly, replace it gradually, or test it on a slice of traffic first. That choice is a deployment strategy, and it's really a trade-off between three things: how fast the rollout completes, how much infrastructure it costs to run, and how much of the blast radius a bad release is exposed to before anyone notices.

This page covers the three strategies real systems use: rolling, blue-green, and canary.

Rolling deployment#

A rolling deployment replaces old instances (or Pods, containers, servers) with new ones a few at a time, rather than all at once — the same mechanism the Kubernetes track's Deployment RollingUpdate strategy uses under the hood.

Before:  [v1] [v1] [v1] [v1]
Step 1:  [v2] [v1] [v1] [v1]   <- one v1 replaced with v2, traffic still flows to all
Step 2:  [v2] [v2] [v1] [v1]
Step 3:  [v2] [v2] [v2] [v1]
After:   [v2] [v2] [v2] [v2]

At every step, some fraction of instances run the old version and some run the new one, and both serve real traffic simultaneously throughout the rollout. This requires no extra infrastructure beyond what's already running — you never need double the fleet — but it does mean the old and new versions must be able to coexist safely for the duration of the rollout: a database schema change deployed alongside new application code has to remain compatible with whichever old instances are still serving traffic during that window.

Trade-offs: Cheapest option (no extra capacity needed), but rollback isn't instant — reverting means running the rolling update again in the opposite direction, and a bad version is live for real users, even if only a fraction of them, for as long as the rollout takes to detect and reverse.

Blue-green deployment#

Blue-green keeps two complete, independent production environments — conventionally named "blue" (the current live version) and "green" (the new version being deployed) — and switches all traffic from one to the other at once, only after the new environment is confirmed healthy.

Before:  [ Blue: v1 ] <--- 100% of traffic (via router/load balancer)
         [ Green: v2 ]      (deployed, tested, no live traffic yet)

Switch:  [ Blue: v1 ]        (kept warm, idle)
         [ Green: v2 ] <--- 100% of traffic (switched instantly)

The switch itself is typically a load balancer or router reconfiguration (repointing which target group receives traffic) rather than anything happening to the application — from the moment the switch happens, every new request goes to green and blue receives nothing. Crucially, blue is kept running and ready for a period after the switch rather than torn down immediately: if green turns out to be broken, rolling back means switching the router back to blue — a change measured in seconds, not a redeploy.

Trade-offs: The fastest possible rollback of the three strategies, and testing can happen against the green environment with real production configuration before it ever receives live traffic. The cost is running two full production environments simultaneously (at least during the deploy window), and — like rolling deployments — anything involving a shared database schema needs to work correctly against both versions until blue is finally decommissioned.

Canary deployment#

A canary deployment routes a small percentage of real traffic to the new version first, monitors it closely, and gradually increases that percentage only if it looks healthy — the name comes from the historical practice of miners carrying a caged canary into a mine as an early warning sign of dangerous gas.

Stage 1:  95% traffic -> v1      5% traffic -> v2   (watch error rate, latency)
Stage 2:  75% traffic -> v1     25% traffic -> v2   (still healthy? proceed)
Stage 3:  25% traffic -> v1     75% traffic -> v2
Stage 4:   0% traffic -> v1    100% traffic -> v2   (fully rolled out)

Unlike blue-green's instant, all-at-once switch, a canary rollout is deliberately gradual, and each stage is a decision point: if error rates or latency on v2 degrade at any stage, traffic is shifted back to v1 (or the rollout is simply paused) while only a small slice of users were ever exposed to the problem, rather than everyone at once. This makes canary the strategy of choice when the risk of a subtle, hard-to-catch-in-testing regression is high and real production traffic is the only reliable way to find out — the trade-off is a slower full rollout and the need for solid real-time metrics (error rate, latency, business metrics) to actually judge whether each stage is safe to proceed from.

Comparing all three#

None of these is strictly "better" — a small internal tool with low traffic and low risk is usually well served by a plain rolling deployment, while a payments system might justify the doubled infrastructure cost of blue-green for the instant-rollback guarantee, and a high-traffic consumer product with a history of subtle production-only bugs might specifically want canary's gradual, metrics-gated exposure. Many real organizations use different strategies for different services within the same company, matched to each service's actual risk profile.

Common mistakes#

• Choosing blue-green without budgeting for running two full environments simultaneously, then being surprised by the cost or by resource contention when both are up at once.
• Running a canary stage with no real monitoring wired up — the entire point of gradual exposure is deciding whether to proceed based on live metrics; without them, a canary rollout is just a slower rolling deployment with extra steps.
• Deploying a backward-incompatible database migration alongside a rolling or canary release — both strategies require the old and new application versions to run against the same schema simultaneously for a period, so the migration itself needs to be compatible with both.
• Assuming any of these strategies replaces the need for a fast rollback path — all three still require someone (or something automated) actually watching for trouble and pulling the trigger to roll back.