Independent deployability पूरै बिन्दु हो, त्यसैले प्रत्येक सेवालाई आफ्नो CI/CD pipeline र कम जोखिमको रिलिज स्ट्र्यातेजी चाहिन्छ — सामान्यतः canary वा blue-green — दिनमा धेरै पटक सुरक्षित रूपमा शिप गर्न।
प्रत्येक सेवा आफ्नो cadence मा बिल्ड, टेस्ट र डिप्लोइ गर्छ। एक सेवामा गरिएको परिवर्तनले कहिले पनि पूरै-प्रणाली रिलिज ट्रिगर गर्दैन।
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategy | कसरी | फाइदा | कमजोरी |
|---|---|---|---|
| Rolling | Instances को क्रमशः बदलना | सरल, पूर्वनिर्धारित | छोटो समयको लागि मिश्रित संस्करण |
| Blue-green | दुई envs, ट्राफिक स्विच | तत्काल rollback | 2x infra |
| Canary | नयाँ संस्करणमा साना % पठाना | Blast radius सीमित गर्छ | राम्रो 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
बिना backward-compatible schemas को, canary/blue-green विफल हुन्छन् किनभने दुई संस्करण एकै साथ चल्छन्। सधैं परिवर्तनहरू संस्करण भरि compatible हुन डिजाइन गर्नुहोस्।
बारम्बार, कम जोखिमको डिप्लोइमेन्ट माइक्रोसर्भिसेसको जटिलता लायक बनाउने कुरा हो — ढिलो, जोखिमपूर्ण रिलिजले autonomy लाभ मेटाएर फेल्छ।
Canary र blue-green ले खराब डिप्लोइमेन्टको blast radius सीमित गर्छन् र लगभग-तत्काल rollback प्रदान गर्छन्, डिप्लोइमेन्टलाई डरलाग्दो घटना बाट दिनिक, स्वचालित, दैनिक गतिविधिमा रूपान्तरित गर्छन्।