Deployability independentă este tot scopul, deci fiecare serviciu are nevoie de propriul pipeline CI/CD plus o strategie de lansare cu risc scăzut — de obicei canary sau blue-green — pentru a expedia în siguranță de mai multe ori pe zi.
Fiecare serviciu construiește, testează și deployează în propriul ritm. O schimbare într-un serviciu nu declanșează niciodată o lansare pe întreg sistemul.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategie | Cum | Avantaj | Dezavantaj |
|---|---|---|---|
| Rolling | Înlocuiți instanțele treptat | Simplu, implicit | Versiuni mixte scurt |
| Blue-green | Două medii, comutare trafic | Rollback instant | 2x infrastructură |
| Canary | Trimiteți mic % la versiune nouă | Limitează raza de explozie | Necesită metrici bune |
v1 ████████████████ 95% ← watch error rate / latency
v2 █ 5% ← promote if healthy, roll back if not
└─ automated check on SLOs decides promote vs abort
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle ├─ flip router ─▶ Green is live; Blue is instant rollback
Fără scheme compatibile cu versiunile anterioare, canary/blue-green se defectează deoarece două versiuni rulează simultan. Proiectați întotdeauna modificări pentru a fi compatibile între versiuni.
Deploy-urile frecvente și cu risc scăzut sunt ceea ce face microserviciile demne de complexitate — lansările lente și riscante ar anula beneficiul autonomiei.
Canary și blue-green limitează raza de explozie a unui deployment defectuos și oferă rollback aproape instantaneu, transformând deployment-ul din eveniment înfricoșător într-o activitate de rutină, automatizată, zilnică.