Bağımsız dağıtılabilirlik tam olarak bu noktadır, bu nedenle her hizmetin kendi CI/CD pipeline'ı ve düşük riskli bir yayın stratejisi —tipik olarak canary veya blue-green— olması gerekir; böylece günde birçok kez güvenli bir şekilde yayın yapılabilir.
Her hizmet kendi hızında inşa edilir, test edilir ve dağıtılır. Bir hizmetteki bir değişiklik asla tam sistem yayınını tetiklemez.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strateji | Nasıl | Avantaj | Dezavantaj |
|---|---|---|---|
| Rolling | Örnekleri kademeli olarak değiştir | Basit, varsayılan | Kısaca karışık sürümler |
| Blue-green | İki ortam, trafiği değiştir | Anında geri alma | 2x altyapı |
| Canary | Küçük % yeni sürüme gönder | Etkilenen alanı sınırla | İyi metrikler gerekir |
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
Geri uyumlu şemaları olmadan, canary/blue-green kırılır çünkü iki sürüm aynı anda çalışır. Her zaman değişiklikleri sürümler arasında uyumlu olacak şekilde tasarlayın.
Sık, düşük riskli dağıtımlar mikro hizmetleri karmaşıklığa değer kılan şeydir —yavaş, riskli yayınlar özerklik avantajını ortadan kaldırırdı.
Canary ve blue-green, hatalı bir dağıtımın etki alanını sınırlar ve neredeyse anında geri alma sağlar; dağıtımı korkutucu bir olaydan, rutinleştirilmiş, otomatikleştirilmiş, günlük bir aktiviteye dönüştürür.