sdlc.dev

CI/CD and DevOps path · Release · Topic 8 of 13

Rolling, blue-green and canary deploys

Not started

A deployment strategy is how traffic moves from the old version to the new one. The three common ones trade cost against blast radius: **rolling** swaps instances gradually, **blue-green** swaps all traffic at once between two full copies, and **canary** gives the new version a small slice first and widens only if its metrics look healthy.

Why it matters: Most outages start with a change. How you roll a change out decides how many users a bad version reaches, and how quickly you can take it back.

  1. 1Rolling

    Replace instances a few at a time. Cheap and the default in Kubernetes, but old and new versions serve traffic side by side for a while.

  2. 2Blue-green

    Run the new version alongside the old one, then switch all traffic at once. Rollback is switching back, at the cost of double capacity during the swap.

  3. 3Canary

    Send a small slice of traffic to the new version, compare its metrics with the old one, then widen step by step or abort.

  4. 4Automate the rollback

    Decide in advance which signals (error rate, latency, saturation) mean abort, and let the pipeline act on them without waiting for a human.

1

How it works

The explanation, with examples you can run.

Rolling updates

Instances are replaced a few at a time: start a new one, wait until it is ready, stop an old one, repeat. Kubernetes Deployments do this by default (maxSurge, maxUnavailable). It needs no extra capacity beyond the surge and no special routing. The catch is that for the length of the rollout, old and new versions serve traffic together. Every change must work in that mixed state, and a bad version is gradually reaching everyone unless something stops the rollout.

Blue-green

Run the current version (blue) and the new version (green) as two complete environments. Test green privately, then switch the router or load balancer so all traffic goes to green. If something breaks, switch back: rollback takes seconds. The costs are double capacity during the switch, and shared state. There is usually one database, so schema changes must work with both colours (see the migrations topic).

Canary

Route a small share of real traffic, say 1% then 5% then 25%, to the new version, and compare it with the old version serving the rest. Compare like with like: the canary against a baseline of the same size started at the same time, on the metrics users feel (error rate, latency, saturation). Tools like Argo Rollouts and Flagger, service meshes and cloud load balancers can do the traffic split and the analysis.

This toy analysis compares each step's canary error rate with the baseline and stops at the first bad step:

⌘/Ctrl + Enter
OutputNot run yet

Press Run to see what your code prints, in order.

Runs in this browser, in an isolated frame with no access to this page. console.log, info, warn and error are shown; code runs as a classic script, so use an async function for await.

Real analysis also needs enough traffic for the difference to mean something; a canary that served 40 requests proves very little.

Rollback that doesn't need a meeting

Decide before the deploy what "bad" means, and wire it to an automatic action: pause the rollout, shift traffic back, or redeploy the previous digest. Keep the previous version's artifact and configuration ready. And remember that rolling back code doesn't roll back data. If the new version wrote data the old one can't read, rollback fails, which is why database changes are split into backward-compatible steps.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.Why must a change deployed with a rolling update be backward compatible?
  2. 2.A canary at 5% shows 2.1% errors; the baseline shows 0.3%. What should happen?
  3. 3.What is the main cost of blue-green deployment?

0 of 3 right so far. Get all three to finish this topic.

Go deeper