Blue-Green / Canary Deployment

Imagine a restaurant testing a new recipe. Instead of serving it to every table at once, the kitchen quietly gives it to just 1 in every 5 tables first. If those diners are happy, more tables get the new dish. If someone complains, the kitchen stops before anyone else is affected. That's a 'canary' release. A small slice of real users try the new version of your app (called v2). Everyone else keeps using the old, proven version (v1). This way, you can watch the small slice closely before you trust it with everyone.

1. 1Deploy the new version (v2) alongside the old one (v1). Both run at the same time; nothing is switched off yet.
2. 2Send only a small share of incoming requests to v2, the 'canary.' Send the rest to v1, the 'stable' version.
3. 3Watch v2's slice for errors. If it looks healthy, send it more traffic over time. If something's wrong, send all traffic back to v1. Most users never even notice.

Use this when you ship a risky change, such as a new payment flow or a rewritten checkout page, to a live app. You can't afford to break things for every user at once, so you want a small, safe group of users affected if something's wrong.

• ⚠Watching the canary for only a few seconds. Some bugs, like a memory leak or a slow database query, only show up after steady traffic over time.
• ⚠Sending the same user to v1 on one request and v2 on the next. Their experience flips back and forth instead of staying consistent.
• ⚠Forgetting that 'blue-green' and 'canary' are two different strategies. Blue-green is an instant full switch between two complete environments. Canary is a gradual ramp-up in traffic share. This lesson's code shows the canary style.