Putting new code into production is the moment of greatest risk in a system's lifecycle. How you deploy — all at once, gradually, or by swapping entire environments — decides whether a bad version causes five minutes of degradation for a few users or an hour of downtime for everyone. Knowing blue-green, canary and rolling, and when to use each, is expected of anyone working in DevOps at a senior level.
Why the way you deploy matters
Every deploy carries two questions: how much downtime it causes and what the blast radius is if the version is bad. The most naive strategy — stop the application, swap it and start it again — guarantees downtime and exposes 100% of users to the bug at once. Modern strategies exist to attack these two axes: reducing or eliminating downtime and limiting how many people see a problem before you roll back.
Recreate vs rolling update
Recreate tears down the old version and brings up the new one: simple, but with a window of unavailability. A rolling update replaces instances gradually — shut down one of the old version, bring up one of the new, repeat — keeping the service always up. It's the Kubernetes default and a reasonable default for most cases. The downside: during the transition both versions coexist, so they need to be compatible (watch out for database schema changes).
Blue-green: two environments, instant switch
You keep two identical environments: blue (current, in production) and green (the new version). You deploy and test everything on green at your own pace, with no real traffic. When it's ready, you just point the router/load balancer from blue to green — the switch is instant. If something goes wrong, the rollback is just pointing back to blue, which remains intact. The analogy: two stages set up; you just decide which one the audience looks at. The cost is keeping two full environments running.
Canary: release to a fraction and observe
With canary (the name comes from the "canary in the coal mine"), you release the new version to a small fraction of traffic — 1%, then 5%, then 25% — watching metrics at each step. If errors, latency or conversion rate get worse, you abort before most people are affected. It's the strategy with the smallest blast radius.
┌──────────────┐ 95% ┌─────────────────┐
tráfego ──▶│ Load Balancer│ ─────▶│ v1 (estável) │
│ │ └─────────────────┘
│ │ 5% ┌─────────────────┐
└──────────────┘ ─────▶│ v2 (canary) 👀 │
└─────────────────┘
métricas do v2 OK? ── sim ▶ aumenta % até 100%
└─ não ▶ rollback (volta a 0%)Feature flags as a complement
Deploy and release don't have to be the same thing. With feature flags, you deploy the new code switched off behind a flag and turn it on later — for a group, a region or everyone — without a new deploy. This decouples "shipping the code" from "turning on the feature", enables canary at the feature level and gives you an instant off switch if something breaks. It pairs very well with the other strategies.
Health checks and automatic rollback
None of this works without the orchestrator knowing whether an instance is healthy. Health checks (readiness and liveness) tell you whether an instance is ready to receive traffic and whether it's still alive. In a rolling or canary deploy, if the new instances fail the health check, the orchestrator stops advancing and can roll back automatically. This "observe metric → decide → roll back" loop is what makes deploys safe — and the natural close of your CI/CD pipeline.
Comparing the strategies
| Strategy | Downtime | Cost | Blast radius | Rollback |
|---|---|---|---|---|
| Recreate | Yes | Low | Total | Slow (bring the old one back up) |
| Rolling | No | Low | Medium (grows gradually) | Medium (rolls back) |
| Blue-green | No | High (2 environments) | Total at the switch | Instant |
| Canary | No | Medium | Minimal (a fraction) | Fast (cut off the fraction) |
There is no best strategy, only the one that fits the risk. A CSS tweak can go with rolling; a checkout rewrite deserves a canary with closely watched metrics and automatic rollback armed. The right question is always "how many people suffer if this goes wrong, and how long until I roll back?".
Conclusion
Rolling eliminates downtime at low cost and serves most cases. Blue-green gives instant rollback at the price of doubling the environment. Canary minimizes the blast radius by releasing gradually under observation. Feature flags decouple deploy from release, and health checks with automatic rollback close the loop. Mastering these options and the design of cloud architecture is what turns deploying from a tense event into a routine non-event.