DevOps Peach| Strategy | How | Downtime | Rollback | Cost / notes |
|---|---|---|---|---|
| Recreate | Stop all of v1, then start v2 | Yes | Slow (redeploy v1) | Simple, cheap |
| Rolling (ramped) | Replace instances one batch at a time | No | Slow | v1 and v2 run together for a while |
| Blue/Green | Build green (v2) alongside, switch 100% of traffic at once | No | Very fast (switch back) | Double resources; DB must work with both |
| Canary | Send 5–10% of traffic to v2, raise it if healthy | No | Fast | Needs good metrics to decide |
| A/B Testing | Route a user group (header, region, device) to v2 | No | Fast | Goal is measuring business impact |
flowchart LR
U["Users"] --> LB{"Router / LB"}
LB -- "90%" --> V1["v1 (stable)"]
LB -- "10% canary" --> V2["v2 (new)"]
V2 -. "healthy metrics → 50% → 100%" .-> LB
On Azure:
- Blue/Green: App Service deployment slots — deploy to staging, warm up, then swap with production; roll back by swapping again.
- Canary: App Service "traffic routing %" sends part of the traffic to a slot; on Kubernetes, a deployment job uses strategy: canary (increments: [10, 20]) or rolling (maxParallel).
- A/B: route by header/cookie (through Front Door, Application Gateway or feature flags, for example).
Traps: - Canary splits by traffic % to cut technical risk; A/B splits by user group to measure outcomes — they are not the same. - Rolling always has a period where two versions run, so APIs and schemas must be backward compatible. - Blue/Green switches traffic fast, but a shared database must still work with both v1 and v2.
| Command | Meaning |
|---|---|
az webapp deployment slot swap -g rg-devops-lab -n app-devops-lab-01 --slot staging --target-slot production |
Blue/Green with slots |
kubectl rollout status deployment/web |
Watch a rolling update |
Feature flags: deploy is not release
A feature flag wraps new code in a switch read at runtime, so code can reach production turned off and be enabled later for some users, or all, without a redeploy. This separates deployment (a technical event) from release (a business decision) and gives an instant "kill switch". Azure App Configuration, LaunchDarkly, and open-source tools such as Unleash or OpenFeature provide flag management.
Shadow (dark) launches
A shadow deployment copies real production traffic to the new version without returning its responses to users. It tests performance and behaviour under real load with no user impact, at the cost of extra infrastructure and care with side effects such as sending emails twice.
Rollback versus roll forward
| Approach | When it fits |
|---|---|
| Rollback | Return to the last good version quickly: swap slots back, redeploy the previous artifact, kubectl rollout undo |
| Roll forward | Ship a small fix on top when rolling back is harder, for example after a data migration |
Database changes decide which is possible. The expand and contract pattern keeps both directions open: first add new columns or tables that the old version ignores (expand), deploy the new code, migrate data, and only later remove the old structures (contract).
Choosing a strategy
| Situation | Reasonable choice |
|---|---|
| Internal tool, downtime acceptable | Recreate |
| Stateless service on Kubernetes | Rolling update with readiness probes |
| Critical web app on App Service | Blue/green with slots |
| Large user base, risky change | Canary with automated metric checks |
| Product experiment | A/B testing with feature flags |
What every strategy needs
Health checks, monitoring of error rate and latency during the rollout, clear rollback steps written in advance, and backward-compatible APIs. Automated canary analysis tools (for example Argo Rollouts or Flagger on Kubernetes) compare metrics between versions and promote or abort without a human watching dashboards.