Canary Deployment
A deployment strategy that routes a small percentage of production traffic to the new version while the majority continues using the current version, allowing teams to monitor for issues before a full rollout.
Named after canaries used in coal mines to detect dangerous gases, canary deployments serve as an early warning system. A typical canary starts by sending 1-5% of traffic to the new version while monitoring error rates, response times, and key business metrics. If metrics remain healthy, traffic is gradually increased (10%, 25%, 50%, 100%). If problems are detected, traffic is immediately routed back to the stable version.
Canary deployments require robust monitoring, alerting, and traffic management capabilities. They work well with containerized applications and load balancers that support weighted routing.
Why It Matters for QA Teams
Canary deployments limit the blast radius of production issues to a small percentage of users. QA teams should understand canary strategies to know how releases are validated in production and what monitoring to watch during rollouts.
Example
A new payment processing integration is deployed as a canary to 2% of checkout traffic. Within 30 minutes, monitoring detects a 15% error rate for the canary group compared to 0.1% for the control group. The canary is automatically rolled back, and only 2% of users were affected instead of 100%. Investigation reveals a misconfigured API timeout that only manifests under production load.