Stop 06 · CI/CD PipelinesTopics · 8/10

Deployment Strategies (Blue-Green, Canary, Rolling)

In short

Deploying shouldn't mean 'pray and refresh'. The right strategy lets you release in the middle of the day, spot problems with a few users first, and roll back in seconds.

Blue-green switches all traffic to a fully new environment at once (easy rollback), canary gradually shifts a small percentage of traffic to test a new version, rolling updates replace instances incrementally.

The mascot serves a new crispy dosa to one table while other tables still eat the usual dish.

Think of it like this

A new dosa on the menu

A restaurant adds a cheese masala dosa. Wise owners serve it to two or three regular tables first and watch their faces. If they love it, more tables get it. If not, it quietly disappears. That's a canary release: try the new version on a few, then widen.

Watch it happen

A rolling update across 6 servers

1/5Six servers all run v1 behind the load balancer.

The big ideas

What you need to know

Rolling

Replace instances a few at a time. Uses no extra servers, but old and new versions run side by side for a while.

Blue-green

Run a full new environment (green) next to the old (blue), then switch all traffic at once. Rollback is just switching back.

Canary

Send a small slice, say 5%, of traffic to the new version. Watch error rates and latency, then increase step by step.

Mind the database

Old and new code may share one database. Make schema changes backward compatible so both versions keep working.

See it in code

Walk through the code

nginx

1upstream api_stable { server 10.0.1.11:3000; server 10.0.1.12:3000; }2upstream api_canary { server 10.0.1.21:3000; }3 4split_clients "$remote_addr" $api_pool {5    10%     api_canary;6    *       api_stable;7}8 9server {10    listen 80;11    location / {12        proxy_pass http://$api_pool;13    }14}

1/3Two pools: the stable version on two servers, and the canary on one.

This lives in nginx's http block. Real canaries usually also watch metrics and roll back automatically, using tools like Argo Rollouts or a cloud load balancer's weighted routing.

Save yourself the pain

Common mistakes

Oops

Doing a canary but not watching any metrics, then promoting it on a timer.

Do this instead

Decide success numbers first, like error rate and p95 latency, and promote only when the canary meets them.

Oops

Dropping a database column in the same release that stops using it.

Do this instead

Split it up: release code that no longer needs the column, then remove the column in a later release.

Your mission

Run your own canary

~30 min

Quick check

Which strategy lets you switch 100% of traffic back to the old version almost instantly, at the cost of running two full environments?

Go deeper

1Diagram all 3 deployment strategies and compare their rollback speed and risk profile.
2Learn which strategy fits which scenario (canary for gradual risk validation, blue-green for instant rollback).
3Understand why 'just deploy and hope' is the strategy all of these are designed to replace.