Deployment strategies
Summary: putting a new version into production can be done in five very different ways, with clear trade-offs between infrastructure cost, risk taken and rollback speed. This lesson details recreate, rolling update, blue-green, canary release and feature flags, and gives you a clear rule for choosing.
1. The problem to solve
No strategy is optimal on all four constraints. Each one is a trade-off, and that is precisely why several exist.
2. Strategy 1 — Recreate (stop everything, restart everything)
| Criterion | Assessment |
|---|---|
| Service interruption | Yes, complete |
| Blast radius if bug | 100% of users |
| Rollback time | Slow (restart v1) |
| Infrastructure cost | The lowest — no duplicated machines |
| Complexity | Very low |
When it is relevant: development and staging environments, internal applications used during office hours, database migrations incompatible between versions (sometimes unavoidable), low-criticality applications.
Do not dismiss this strategy on principle. For an internal tool used by 20 people during the day, a recreate deployment at 10pm is perfectly reasonable — and infinitely simpler to operate.
3. Strategy 2 — Rolling update (progressive replacement)
This is Kubernetes' default strategy and the most widespread in 2026.
| Criterion | Assessment |
|---|---|
| Service interruption | None |
| Blast radius if bug | Growing — from 33% to 100% as the deployment progresses |
| Rollback time | Medium — a rolling update in the opposite direction is needed |
| Infrastructure cost | Low — only one extra instance at a time |
| Complexity | Low (native in Kubernetes) |
The major trap of the rolling update: during the transition, v1 and v2 coexist and both serve traffic. This imposes a strong constraint, often forgotten:
This expand and contract pattern (also called parallel change) is one of the most valued skills in senior DevOps interviews. Many candidates know the rolling update but are unaware of this constraint.
4. Strategy 3 — Blue-green (instant switch)
| Criterion | Assessment |
|---|---|
| Service interruption | None |
| Blast radius if bug | 100% — but detected and cancelled in seconds |
| Rollback time | The best — a few seconds, router switch-back |
| Infrastructure cost | High — double infrastructure during the transition |
| Complexity | Medium |
Blue-green's decisive asset: it is the strategy with the fastest rollback in existence. When every minute of incident costs thousands of euros, that doubled infrastructure cost is instantly justified.
Its limit: the database. If blue and green share the same database (the near-universal case), an application rollback does not undo a schema migration already applied. Blue-green protects against the application bug, not against the data problem.
5. Strategy 4 — Canary release (measured progressive deployment)
The name comes from the canaries that miners took underground: the bird, more sensitive to toxic gases, gave the alert before the humans were in danger.
| Criterion | Assessment |
|---|---|
| Service interruption | None |
| Blast radius if bug | The best — only 1 to 5% of users |
| Rollback time | Fast — a few seconds of rerouting |
| Infrastructure cost | Moderate |
| Complexity | High — requires fine-grained routing and solid observability |
The absolute prerequisite of the canary: quality observability. Without reliable metrics to objectively compare v1 and v2, the canary brings nothing — you expose 5% of users without being able to detect the degradation.
Tools that automate the canary in 2026: Argo Rollouts, Flagger, or a service mesh like Istio / Linkerd for weighted routing.
6. Strategy 5 — Feature flags (decoupling deployment and activation)
This approach is of a different nature from the four previous ones: it does not concern how the code reaches production, but when the feature becomes visible.
This is the key that makes continuous deployment practicable at large scale. Facebook, Google and Netflix deploy hundreds of times a day precisely because deploying no longer means delivering a feature to users. The two events are decoupled.
The cost to know about: the technical debt of flags. A flag forgotten for two years becomes a code path that nobody understands anymore and that nothing tests anymore. Essential discipline: every flag must have a planned removal date from its creation.
Common tools: LaunchDarkly, Unleash (open source), Flagsmith, OpenFeature (emerging CNCF standard).
7. The complete comparison table
| Strategy | Interruption | Blast radius | Rollback | Infra cost | Complexity |
|---|---|---|---|---|---|
| Recreate | Yes | 100% | Slow | The lowest | Very low |
| Rolling update | No | Growing | Medium | Low | Low |
| Blue-green | No | 100% (brief) | The fastest | High | Medium |
| Canary | No | The lowest | Fast | Moderate | High |
| Feature flags | No | Finely controlled | Instant | Low | Medium |
Important clarification: these strategies combine. A common configuration in 2026 at a mature company is rolling update for the infrastructure, plus feature flags for functional activation, plus canary for the most sensitive changes.
8. How to choose — decision tree
Recommendation for a team getting started: begin with rolling update (free and native if you are on Kubernetes), then add feature flags for risky features. Canary and blue-green will come when your observability and your budget allow it.
9. Two related terms to know
The canary / A/B testing distinction is an excellent test of understanding: both split traffic, but the canary answers "does it break?" while A/B testing answers "does it convert better?". A canary lasts minutes, an A/B test lasts weeks.
Remember in 30 seconds
- Five strategies, each a trade-off between interruption, blast radius, rollback and cost.
- Recreate: accepted interruption, the simplest. Perfect for internal tools and staging.
- Rolling update: Kubernetes' default. Watch out for backward-compatible migrations (expand and contract pattern).
- Blue-green: the fastest rollback, but double infrastructure.
- Canary: the smallest blast radius, but requires solid observability.
- Feature flags: decouple deploying from releasing. This is what makes continuous deployment practicable.
- These strategies combine — rolling + feature flags is the sound baseline in 2026.
- Canary validates technical stability, A/B testing compares business effectiveness.
Next: The tools compared: GitHub Actions, GitLab CI, Jenkins and the others →