What deployment strategies (CI/CD, canary, blue-green) suit microservices?

Question

Accepted Answer

Independent deployability is the whole point, so each service needs its **own CI/CD pipeline** plus a **low-risk release strategy** — typically canary or blue-green — to ship safely many times a day.

## Per-service pipelines

Each service builds, tests, and deploys on its own cadence. A change to one service never triggers a full-system release.

```text
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
```

## Release strategies

| Strategy | How | Pro | Con |
|---|---|---|---|
| Rolling | Replace instances gradually | Simple, default | Mixed versions briefly |
| Blue-green | Two envs, switch traffic | Instant rollback | 2x infra |
| Canary | Send small % to new version | Limits blast radius | Needs good metrics |

## Canary in practice

```text
v1 ████████████████ 95%   ← watch error rate / latency
v2 █                 5%   ← promote if healthy, roll back if not
  └─ automated check on SLOs decides promote vs abort
```

## Blue-green

```text
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle  ├─ flip router ─▶ Green is live; Blue is instant rollback
```

## Pitfall

Without backward-compatible schemas, canary/blue-green break because two versions run simultaneously. Always design changes to be compatible across versions.

## Why it matters

Frequent, low-risk deploys are what make microservices worth the complexity — slow, risky releases would erase the autonomy benefit.

Canary and blue-green limit the blast radius of a bad deploy and give near-instant rollback, turning deployment from a scary event into a routine, automated, daily activity.

Strategy	How	Pro	Con
Rolling	Replace instances gradually	Simple, default	Mixed versions briefly
Blue-green	Two envs, switch traffic	Instant rollback	2x infra
Canary	Send small % to new version	Limits blast radius	Needs good metrics