Niezależna wdrażalność to cały sens, więc każda usługa potrzebuje własny pipeline CI/CD oraz strategię wydania o niskim ryzyku — zazwyczaj canary lub blue-green — aby bezpiecznie wydawać wiele razy dziennie.
Per-service pipelines
Każda usługa buduje, testuje i wdraża w swoim własnym tempie. Zmiana w jednej usłudze nigdy nie wyzwala wydania całego systemu.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
Release strategies
| Strategia | Jak | Zaleta | Wada |
|---|---|---|---|
| Rolling | Stopniowa zamiana instancji | Proste, domyślne | Mieszane wersje krótko |
| Blue-green | Dwa środowiska, zmiana ruchu | Natychmiastowy rollback | 2x infrastruktura |
| Canary | Wysłanie małego % do nowej wersji | Ogranicza promień wybuchu | Wymaga dobrych metryk |
Canary in practice
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
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle ├─ flip router ─▶ Green is live; Blue is instant rollback
Pitfall
Bez schematów kompatybilnych wstecz, canary/blue-green się psują, ponieważ dwie wersje działają jednocześnie. Zawsze projektuj zmiany aby były kompatybilne między wersjami.
Dlaczego to ważne
Częste, niskoryzyczne wdrażania to to, co sprawia że mikrousługi są warte złożoności — wolne, ryzykowne wydania uniemożliwiłyby autonomię.
Canary i blue-green ograniczają promień wybuchu złego wdrożenia i zapewniają niemal natychmiastowy rollback, zamieniając wdrożenie z przeraźliwego zdarzenia w rutynową, zautomatyzowaną, codzienną czynność.