Jaké strategie nasazení (CI/CD, canary, blue-green) jsou vhodné pro mikroslužby?

Question

Accepted Answer

Nezávislá nasaditelnost je celý smysl mikroslužeb, takže každá služba potřebuje svůj **vlastní CI/CD pipeline** a **nízkorizikovou strategii vydání** — typicky canary nebo blue-green — aby byla schopna bezpečně nasadit mnoikrát za den.

## Pipelines per-služba

Každá služba se builduje, testuje a nasazuje na vlastní kadenci. Změna v jedné službě nikdy nespustí vydání celého systému.

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

## Strategie vydání

| Strategie | Jak | Výhoda | Nevýhoda |
|---|---|---|---|
| Rolling | Postupná výměna instancí | Jednoduché, výchozí | Krátce smíšené verze |
| Blue-green | Dvě prostředí, přesměrování provozu | Okamžité vrácení | 2x infrastruktura |
| Canary | Poslání malého % na novou verzi | Omezuje dopad selhání | Vyžaduje dobré metriky |

## Canary v praxi

```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
```

## Úskalí

Bez zpětně kompatibilních schémat se canary/blue-green rozbijí, protože běží současně dvě verze. Vždy navrhujte změny, které jsou kompatibilní napříč verzemi.

## Proč to má значenie

Časté, nízkorizikové nasazení je to, co činí mikroslužby hodné jejich složitosti — pomalé, riziková vydání by zničila výhodu autonomie.

Canary a blue-green omezují dopad špatného nasazení a poskytují téměř okamžité vrácení, přeměňují nasazení z děsivé akce na rutinní, automatizovanou, každodenní aktivitu.

Strategie	Jak	Výhoda	Nevýhoda
Rolling	Postupná výměna instancí	Jednoduché, výchozí	Krátce smíšené verze
Blue-green	Dvě prostředí, přesměrování provozu	Okamžité vrácení	2x infrastruktura
Canary	Poslání malého % na novou verzi	Omezuje dopad selhání	Vyžaduje dobré metriky