स्वतंत्र तैनातीता पूरा मुद्दा है, इसलिए प्रत्येक सेवा को अपनी स्वयं की CI/CD पाइपलाइन और कम-जोखिम वाली रिलीज़ रणनीति की आवश्यकता है — आमतौर पर canary या blue-green — दिन में कई बार सुरक्षित रूप से शिप करने के लिए।
प्रत्येक सेवा अपनी गति से बनाई जाती है, परीक्षण की जाती है और तैनात की जाती है। एक सेवा में कोई परिवर्तन कभी भी पूर्ण-सिस्टम रिलीज़ को ट्रिगर नहीं करता है।
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategy | How | Pro | Con |
|---|---|---|---|
| Rolling | Replace instances gradually | Simple, default | Mixed versions briefly |
| Blue-green | Two envs, switch traffic | Instant rollback | 2x infra |
| Canary | Send small % to new version | Limits blast radius | Needs good metrics |
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 एक खराब तैनाती के विस्फोट के दायरे को सीमित करते हैं और लगभग तत्काल रोलबैक देते हैं, जो तैनाती को एक डरावनी घटना से एक दिनचर्या, स्वचालित, दैनिक गतिविधि में बदल देते हैं।