Lesson 4 of 5

Deployment Strategies

The tested artifact is ready. Now the sharpest question in the whole discipline: how do you swap what production is currently running for the new version — with users on the site the entire time? Every strategy below is a different trade of infrastructure cost against blast radius, and they answer to the same iron rule: never deploy anything you can't quickly un-deploy.

💡 The Bottom Line

Rolling: replace instances a few at a time (cheap, default). Blue-green: run two full environments and flip traffic between them (instant rollback, double cost). Canary: send a small slice of real traffic to the new version and watch before going wide (lowest risk, needs monitoring). Feature flags: decouple deploying code from releasing features entirely.

Rolling deployment

With several instances behind a load balancer, replace them in waves: take one out, update it, return it healthy, repeat. No extra infrastructure, no downtime — it's what Kubernetes Deployments do out of the box. The trade-offs: mid-rollout, both versions serve traffic simultaneously (so changes must be compatible across one version's distance — the migration rule from Lesson 3), and rollback means rolling all the way back through the same waves.

Blue-green deployment

Two identical production environments: blue runs the live version, green sits idle. Deploy to green, test it with no users watching, then flip the router — green is live, blue becomes the idle one. The killer feature is instant rollback: something's wrong, flip back — seconds, not a re-deploy. The cost is literal: you run double the infrastructure, and stateful pieces (the shared database) still need the compatibility discipline, since a flip-back means old code reads whatever new code wrote.

Canary release

Named for the coal-mine canary: route a small slice — say 5% — of real traffic to the new version, and watch error rates, latency, and business metrics against the 95% baseline. Healthy? Widen to 25%, 50%, 100%. Unhealthy? Pull the canary; only 5% of users ever saw the problem. It's the gentlest strategy — real traffic finds bugs staging never will — but it demands real monitoring (a canary nobody watches is just a slow rollout) and versions that coexist, like rolling.

Feature flags: the strategy that isn't a deployment

if (flags.newCheckout) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Ship the new code dark — deployed but switched off — then turn it on from a dashboard: for staff first, then 1% of users, then everyone. Deploying (moving code to servers) and releasing (exposing behavior to users) become independent decisions, and "rollback" becomes toggling a flag — no deploy at all. The tax: every flag is an if living in your codebase, so retire them once fully rolled out, or accrue an unmaintainable thicket.

🙋 There Are No Dumb Questions

Q: Which one should I use?
A: The cheapest one that fits the blast radius you can tolerate. A small internal tool: rolling (or even a brief maintenance stop) is honest and fine. Revenue-critical checkout flow: canary plus a feature flag. Blue-green earns its double cost when instant rollback is worth paying for. These compose, too — a canary rollout of code whose features hide behind flags is a very normal setup.

⚠️ Watch Out

Every strategy above quietly assumes health checks — some machine-readable way to ask "is this instance actually OK?" A rolling update that can't tell a healthy instance from a broken one just replaces good pods with bad ones on schedule; a canary without metrics is a coin flip. Before choosing a strategy, make sure your app exposes a real health signal (an endpoint checking its critical dependencies) — it's the foundation all four strategies stand on.

🔧 Try It Yourself

For your own project, answer the strategy-choosing questions in writing:

1. If a bad version reached 100% of users, what's the worst hour like?
2. Can I afford to run two copies of production? (blue-green)
3. Do I have metrics good enough to judge a 5% canary?
4. Which upcoming risky feature deserves a flag instead of a branch?

Question 1's answer usually picks the strategy for you: mild pain → rolling; real money or reputation → canary and/or flags.

✅ Quick Check

What is the defining advantage of blue-green deployment?

Last lesson: the failure modes — flaky tests, leaked secrets, snowflake agents, and the other ways good pipelines go bad.

← Back to