Deployment strategies
🎯You'll be able to
Compare recreate, rolling, blue-green and canary deployments, and choose one based on risk, cost and how quickly you need to undo.
🏠The everyday picture
A restaurant changing its menu can close for a day to reprint everything (recreate), change one table's menu at a time (rolling), set up a fully new dining room next door and move everyone at once (blue-green), or give the new dish to a few tables first and watch their faces (canary).
📘What it really is
- Recreate: stop all old copies, then start new ones. Simple, but there's downtime. Acceptable for internal tools or batch jobs.
-
Rolling: replace copies a few at a time, each new one becoming healthy before an old one goes. No downtime, little extra capacity, but for a while old and new versions serve side by side. Kubernetes Deployments and RouteRani's
create_before_destroywork this way. -
Blue-green: run the full new version ("green") next to the old ("blue"), test it, then switch all traffic at once (at the load balancer or DNS). Rollback is switching back, which is fast. It needs double capacity during the switch.
-
Canary: send a small share of traffic (say 5%) to the new version, compare its errors and speed with the old one, then increase step by step. Problems hit few users. It needs traffic splitting and good metrics (CD9). Tools include Argo Rollouts, Flagger and cloud load balancers' weighted routing.
-
Whatever the strategy, old and new may run together, so each release must work alongside the previous one: the same API shapes, the same database schema (Lesson 5).
-
Choosing:
| Strategy | Downtime | Extra capacity | Speed of undo | Users exposed to a bad release |
|---|---|---|---|---|
| Recreate | yes | none | slow (redeploy) | all |
| Rolling | none | a little | medium | growing share during the roll |
| Blue-green | none | double, briefly | fast (switch back) | all, after the switch |
| Canary | none | a little | fast | a small share at first |
📝A worked example
Input: RouteRani's finished Terraform with 2 copies, deploying 1.0.2 while tools/load.js sends traffic.
Expected output: docker ps during the deploy shows four copies for a few seconds (two 1.0.1, two 1.0.2, each new one becoming healthy),
then only the two new ones. The x-version header switches from 1.0.1 to 1.0.2 during the overlap, with some requests on each. This is a
rolling-style deploy where all new copies start together, then the old ones are removed.
🌍Where it's used
- Rolling: the default for most container platforms.
- Blue-green: systems where a clean switch matters, such as payment gateways during low-traffic windows.
- Canary: large consumer apps, where 1% of users is still thousands of people, enough to spot problems.
📝Case scenario
A music streaming service released a new recommendations engine to everyone at once. It worked in tests but used three times the expected memory under real traffic, and copies started crashing within minutes. With a canary, 5% of traffic would have shown the memory climb and stopped the rollout. They moved to canary releases with automatic comparison of error rates and memory.
🖱️Try it
For each of these, choose a strategy and give one reason: an internal report generator used once a day; RouteRani's booking API; a payment gateway's new fraud rules; a new mobile app home screen. Success: you've used at least three different strategies, each with a reason about risk, cost or speed of undo.
⚠️Common mistakes
- Recreate for user-facing services. Sign: errors at every deploy. Fix: rolling, blue-green or canary.
- Assuming old and new never overlap. Sign: errors during rollouts when a new version changes an API. Fix: keep releases compatible with the previous one.
- Canary without good metrics. Sign: canaries that "pass" because nobody measured. Fix: automatic comparison of errors and latency.
🛠️For your project
Project 2's deploys use a rolling-style replacement through create_before_destroy, and test 6 checks no requests fail during it.
✅Quick check
What does blue-green need that rolling doesn't?
Show the answer
Enough capacity to run two full versions at once, briefly.
Why is a canary safer for big changes?
Show the answer
Only a small share of users sees the new version until its metrics look good.