ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਲਈ ਕਿਹੜੀਆਂ ਡਿਪਲਾਇਮੈਂਟ ਸਟ੍ਰੈਟੀਜੀ (CI/CD, canary, blue-green) ਠੀਕ ਹਨ?

Question

Accepted Answer

Independent deployability ਪੂਰਾ ਮੁਦਾ ਹੈ, ਇਸਲਈ ਹਰੇਕ ਸੇਵਾ ਨੂੰ ਆਪਣਾ **CI/CD pipeline** ਅਤੇ **ਘੱਟ-ਜੋਖਮ ਵਾਲੀ ਰੀਲਿਜ਼ ਸਟ੍ਰੈਟੀਜੀ** ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ canary ਜਾਂ blue-green — ਪ੍ਰਤਿਦਿਨ ਕਈ ਵਾਰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਲਈ।

## Per-service pipelines

ਹਰੇਕ ਸੇਵਾ ਆਪਣੀ ਗਤੀ ਨਾਲ ਬਿਲਡ, ਟੈਸਟ ਅਤੇ ਡਿਪਲਾਇ ਕਰਦੀ ਹੈ। ਇੱਕ ਸੇਵਾ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਕਦੇ ਪੂਰੇ-ਸਿਸਟਮ ਰੀਲਿਜ਼ ਨੂੰ ਟ੍ਰਿਗਰ ਨਹੀਂ ਕਰਦੀ।

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

## Release strategies

| Strategy | ਕਿਵੇਂ | ਫਾਇਦਾ | ਨੁਕਸਾਨ |
|---|---|---|---|
| Rolling | Instances ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਬਦਲੋ | ਸਧਾਰਨ, ਪੂਰਵ-ਨਿਯੁਕਤ | ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਮਿਲੀ-ਜੁਲੀ ਵਰਜਨ |
| Blue-green | ਦੋ envs, ਟ੍ਰਾਫਿਕ ਬਦਲੋ | ਤੁਰੰਤ rollback | 2x infra |
| Canary | ਨਵੀਂ ਵਰਜਨ ਲਈ ਛੋਟਾ % ਭੇਜੋ | ਬਲਾਸਟ ਰੇਡੀਅਸ ਸੀਮਿਤ ਕਰੋ | ਚੰਗੇ metrics ਦੀ ਲੋੜ |}

## Canary in practice

```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
```

## Pitfall

backward-compatible schemas ਦੇ ਬਿਨਾ, canary/blue-green ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਦੋ ਵਰਜਨ ਇਕੱਠੇ ਚਲਦੇ ਹਨ। ਹਮੇਸ਼ਾ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸਮਾਂਤਰ ਵਰਜਨਾਂ ਵਿੱਚ ਅਨੁਕੂਲ ਹੋਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ।

## ਇਹ ਜ਼ਰੂਰੀ ਕਿਉਂ ਹੈ

ਲਗਾਤਾਰ, ਘੱਟ-ਜੋਖਮ ਵਾਲੀ ਡਿਪਲਾਇਮੈਂਟ ਉਹ ਹੈ ਜੋ microservices ਨੂੰ ਜ਼ਟਿਲਤਾ ਦੇ ਲਾਇਕ ਬਣਾਉਂਦੀ ਹੈ — ਧੀਮੀ, ਜੋਖਮ ਵਾਲੀ ਰੀਲਿਜ਼ ਆਟੋਨਮੀ ਦਾ ਲਾਭ ਮਿਟਾ ਦੇਵੇਗੀ।

Canary ਅਤੇ blue-green ਇੱਕ ਬੁਰੀ ਡਿਪਲਾਇਮੈਂਟ ਦੇ ਬਲਾਸਟ ਰੇਡੀਅਸ ਨੂੰ ਸੀਮਿਤ ਕਰਦੇ ਹਨ ਅਤੇ ਲਗਭਗ-ਤੁਰੰਤ rollback ਦਿੰਦੇ ਹਨ, ਡਿਪਲਾਇਮੈਂਟ ਨੂੰ ਇੱਕ ਡਰਾਵਨੇ ਘਟਨਾ ਤੋਂ ਇੱਕ ਨਿਯਮਿਤ, ਸਵੈਚਲਿਤ, ਦੈਨਿਕ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲਦੇ ਹਨ।

Strategy	ਕਿਵੇਂ	ਫਾਇਦਾ	ਨੁਕਸਾਨ
Rolling	Instances ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਬਦਲੋ	ਸਧਾਰਨ, ਪੂਰਵ-ਨਿਯੁਕਤ	ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਮਿਲੀ-ਜੁਲੀ ਵਰਜਨ
Blue-green	ਦੋ envs, ਟ੍ਰਾਫਿਕ ਬਦਲੋ	ਤੁਰੰਤ rollback	2x infra
Canary	ਨਵੀਂ ਵਰਜਨ ਲਈ ਛੋਟਾ % ਭੇਜੋ	ਬਲਾਸਟ ਰੇਡੀਅਸ ਸੀਮਿਤ ਕਰੋ	ਚੰਗੇ metrics ਦੀ ਲੋੜ