Canary deployment
What it is
Canary deployment is a progressive rollout technique that sends the new version to a small subset of real users or servers first (“canaries”), monitors their behavior and telemetry, and only if they look healthy expands the rollout to a wider audience until all traffic is on the new version. The name comes from coal-mine canaries — a warning system for the rest of the flock.
Why it exists
You get real-world validation on live traffic with a small blast radius. A bad change only affects the canary cohort initially; you detect it from metrics (errors, latency) before exposing everyone, then either continue the rollout or roll back the canary.
Key ideas
- Small %, real traffic: route e.g. 5–10% of traffic to the new version (via load balancer weight, traffic manager, service mesh, or slot swap that takes a fraction).
- Driven by telemetry: decide to expand only when health/error/latency metrics for the canary stay within thresholds. Automated via deployment gates (e.g. monitoring gates).
- Controlled expansion: 5% → 25% → 50% → 100% as each step validates.
- Rollback is easy: remove the canary / route traffic back to the stable version.
- Often combined with feature flags to gate functionality exposure independently of the code rollout.
How it fits
Canary is a progressive-delivery pattern under the release strategy. It gives gradual, metric-gated exposure — unlike blue/green, which switches everything at once.
Exam notes
- Canary = release to a small percentage, monitor, then expand; driven by health/error telemetry, not time alone.
- Distinguish from rings (canary = random/small traffic %; rings = defined user cohorts) and blue/green (full swap).
- Use a monitoring/health gate (deployment-gate) to automate the canary → full rollout decision.
Related
release-strategy · deployment-ring · feature-flags · rollback-strategy · deployment-gate
📘 Source: Microsoft Learn — Canary Deployment