مائیکروسروسز کے لیے کون سی ڈپلائمنٹ سٹریٹجیز (CI/CD، canary، blue-green) موزوں ہیں؟

Question

Accepted Answer

آزاد ڈپلائمنٹ ممکنات ہی اصل مقصد ہے، اس لیے ہر سروس کو اپنی **اپنی CI/CD pipeline** اور **کم خطرے والی رہائی کی حکمت عملی** کی ضرورت ہے — عام طور پر canary یا blue-green — تاکہ محفوظ طریقے سے دن میں کئی بار جاری کیا جا سکے۔

## فی سروس pipelines

ہر سروس اپنی رفتار سے بناتا، ٹیسٹ کرتا اور ڈپلائے کرتا ہے۔ ایک سروس میں تبدیلی کبھی بھی مکمل سسٹم رہائی کو متحرک نہیں کرتی۔

```text
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
```

## رہائی کی حکمت عملی

| حکمت عملی | کیسے | فوائل | نقصانات |
|---|---|---|---|
| Rolling | بتدریج instances کو بدلیں | سادہ، ڈیفالٹ | مختصر وقت کے لیے ملے ہوئے ورژن |
| Blue-green | دو ماحول، ٹریفک سوئچ کریں | فوری rollback | 2x infra |
| Canary | نئے ورژن کو چھوٹا % بھیجیں | Blast radius کو محدود کریں | بہترین metrics کی ضرورت ہے |

## Canary عملی طریقے میں

```text
v1 ████████████████ 95%   ← watch error rate / latency
v2 █                 5%   ← promote if healthy, roll back if not
  └─ automated check on SLOs decides promote vs abort
```

## Blue-green

```text
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle  ├─ flip router ─▶ Green is live; Blue is instant rollback
```

## خطرناک نقطہ

بغیر backward-compatible schemas کے، canary/blue-green ٹوٹ جاتے ہیں کیونکہ دونوں ورژن بیک وقت چلتے ہیں۔ ہمیشہ ورژنز میں تبدیلیوں کو مطابقت پذیر ہونے کے لیے ڈیزائن کریں۔

## یہ کیوں اہم ہے

بار بار، کم خطرے والی ڈپلائمنٹ وہ ہے جو مائیکروسروسز کو پیچیدگی کے قابل بناتی ہے — سست، خطرناک رہائی خودمختاری کے فوائل کو ختم کر دے گی۔

Canary اور blue-green خراب ڈپلائمنٹ کے blast radius کو محدود کرتے ہیں اور فوری rollback دیتے ہیں، ڈپلائمنٹ کو خوفناک واقعے سے روزمرہ، خودکار، روزانہ کی سرگرمی میں بدل دیتے ہیں۔

حکمت عملی	کیسے	فوائل	نقصانات
Rolling	بتدریج instances کو بدلیں	سادہ، ڈیفالٹ	مختصر وقت کے لیے ملے ہوئے ورژن
Blue-green	دو ماحول، ٹریفک سوئچ کریں	فوری rollback	2x infra
Canary	نئے ورژن کو چھوٹا % بھیجیں	Blast radius کو محدود کریں	بہترین metrics کی ضرورت ہے