Independen deployability yaiku pokok pokuane, dadi saben layanan butuh pipeline CI/CD sariri plus strategi rilis sing rendah risiko — biasane canary utawa blue-green — kanggo ngirim kanthi aman akeh kali saben dina.
Saben layanan build, test, lan deploy kanthi irama dewe. Owah-owahan ing salah sawijining layanan ora bakal nduweni pengaruh release sistem lengkap.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategi | Cara | Kauntungan | Kakirangan |
|---|---|---|---|
| Rolling | Ganti instance kanthi bertahap | Prasaja, default | Versi campur-aduk sakdurunge |
| Blue-green | Rong environment, alih traffic | Rollback langsung | 2x infrastruktur |
| Canary | Kirim % cilik menyang versi anyar | Batasi blast radius | Butuh metrik apik |
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
Tanpa schema sing kompatibel mundur, canary/blue-green rusak amarga loro versi mlaku bebarengan. Tansah desain owah-owahan supaya kompatibel lintang versi.
Deploy asring lan rendah risiko yaiku apa sing ndadekake microservices layak kanggo kompleksitas — rilis lambat lan berisiko bakal ngilangi kauntungan autonomi.
Canary lan blue-green mbatesi blast radius deploy sing awon lan menehi rollback cepet, ngowahi deployment saka acara sing nggemetaken dadi aktivitas rutin, otomatis, saben dina.