स्वतंत्र डिप्लॉयएबिलिटी हा संपूर्ण मुद्दा आहे, त्यामुळे प्रत्येक सर्व्हिसला स्वतःचे CI/CD पाइपलाइन आणि कमी जोखीम असलेली रिलीज स्ट्रॅटेजी —विशेषत: canary किंवा blue-green — हवी असते जेणेकरून दिवसातून अनेक वेळा सुरक्षितपणे शिप करता येईल.
प्रत्येक सर्व्हिस स्वतःच्या गतीने बिल्ड, टेस्ट आणि डिप्लॉय करते. एका सर्व्हिसमध्ये केलेला बदल कधीही संपूर्ण-सिस्टम रिलीज ट्रिगर करत नाही.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| स्ट्रॅटेजी | कसे | फायदा | नुकसान |
|---|---|---|---|
| Rolling | इन्स्टन्सेस हळूहळू बदलणे | साधे, डिफॉल्ट | थोडक्यात मिश्र व्हर्जन |
| Blue-green | दोन envs, ट्रॅफिक स्विच करणे | तात्काळ rollback | 2x infra |
| Canary | नव्या व्हर्जनला छोटा % पाठवणे | blast radius मर्यादित करते | चांगल्या मेट्रिक्स लागतात |
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
पिछड्या-सुसंगत स्कीमाशिवाय, canary/blue-green खंडित होतात कारण दोन व्हर्जन एकाच वेळी चालतात. नेहमी बदलांना व्हर्जन्सच्या पार सुसंगत असण्यासाठी डिজाइन करा.
वारंवार, कमी-जोखीम असलेले डिप्लॉयमेंट हेच आहे जे माइक्रोसर्व्हिसेसला जटिलतेची किंमत देते — हळू, धोकादायक रिलीज स्वायत्तता लाभ मिटवून देईल.
Canary आणि blue-green खराब डिप्लॉयचा blast radius मर्यादित करतात आणि जवळजवळ तात्काळ rollback देतात, डिप्लॉयमेंटला भयानक इव्हेंटमधून नियमित, स्वयंचलित, दैनिक कृत्यात रूपांतरित करतात.