Blue-Green ve Canary Deployment Nedir? Sıfır Kesinti Rehberi

Her deployment'ta kalp krizi mi geçiriyorsunuz? Geri alma imkânınız var mı? Blue-Green ve Canary Deployment ile sıfır kesinti ve güvenli release yapın.

Geleneksel Deployment Sorunu

1. Sunucuyu durdur      → 🔴 Kesinti başladı
2. Eski kodu kaldır
3. Yeni kodu yükle
4. Sunucuyu başlat     → 🟢 Kesinti bitti

Kesinti süresi: 5-30 dakika

1. Blue-Green Deployment

İki özdeş ortam: Blue (mevcut) ve Green (yeni). Trafik anında geçirilir.

Öncesi:
  Load Balancer → [Blue v1.0] ← Tüm trafik
                  [Green] (boş)

Deploy:
  Load Balancer → [Blue v1.0]
                  [Green v2.0] ← Yeni sürüm yüklendi, test ediliyor

Geçiş:
  Load Balancer → [Blue v1.0] (standby)
                  [Green v2.0] ← Tüm trafik buraya!

Sorun çıkarsa:
  Load Balancer → [Blue v1.0] ← Anında geri al!
                  [Green v2.0] (devre dışı)

Avantajlar

• ✅ Sıfır kesinti
• ✅ Anında geri alma (saniyeler)
• ✅ Production'da test imkânı (smoke test)
• ✅ Basit ve anlaşılır

Dezavantajlar

• ❌ İki kat kaynak maliyeti
• ❌ Veritabanı şema değişiklikleri karmaşık
• ❌ Tüm trafik bir anda geçer (risk)

Kubernetes'te Blue-Green

# Green deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.0
---
# Service'i green'e yönlendir
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    version: green  # blue → green

2. Canary Deployment

Yeni sürümü önce küçük bir kullanıcı grubuna açın, sorun yoksa kademeli artırın.

Aşama 1:  %5 trafik  → v2.0  |  %95 trafik → v1.0
Aşama 2:  %25 trafik → v2.0  |  %75 trafik → v1.0
Aşama 3:  %50 trafik → v2.0  |  %50 trafik → v1.0
Aşama 4:  %100 trafik → v2.0  → Full rollout ✅

Avantajlar

• ✅ Riskin kademeli yönetimi
• ✅ Gerçek kullanıcı verisiyle doğrulama
• ✅ Küçük patlama yarıçapı
• ✅ A/B test ile birleştirilebilir

Dezavantajlar

• ❌ Daha karmaşık altyapı
• ❌ İki sürümün aynı anda çalışması gerekir
• ❌ Monitoring ve otomatik rollback gerektirir

Nginx ile Canary

upstream backend {
    server v1-server:3000 weight=95;
    server v2-server:3000 weight=5;
}

Kubernetes ile Canary (Istio)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
    - route:
        - destination:
            host: app
            subset: stable
          weight: 95
        - destination:
            host: app
            subset: canary
          weight: 5

3. Rolling Update

Pod'ları birer birer güncelleme (Kubernetes varsayılanı):

[v1] [v1] [v1] [v1]
[v2] [v1] [v1] [v1]  → 1 pod güncellendi
[v2] [v2] [v1] [v1]  → 2 pod güncellendi
[v2] [v2] [v2] [v1]  → 3 pod güncellendi
[v2] [v2] [v2] [v2]  → Tamamlandı ✅

Karşılaştırma

| Strateji | Kesinti | Geri Alma | Risk | Maliyet | |----------|---------|-----------|------|---------| | Recreate | Var | Yavaş | Yüksek | Düşük | | Rolling | Yok | Orta | Orta | Düşük | | Blue-Green | Yok | Anında | Düşük | Yüksek | | Canary | Yok | Hızlı | En düşük | Orta |

Database Migration Stratejisi

En kritik sorun: veritabanı şema değişiklikleri.

1. Expand — Yeni kolon/tablo ekle (geriye uyumlu)
2. Migrate — Veriyi yeni yapıya taşı
3. Contract — Eski kolon/tabloyu kaldır (sadece v2 tamamen geçtikten sonra)

Best Practices

1. Feature flag ile birleştirin — Deployment ≠ release
2. Health check zorunlu — Sağlıksız pod'u otomatik geri al
3. Otomatik rollback — Hata oranı eşiği belirleyin
4. DB backward compatible — Şema değişikliklerini ayrı deploy edin
5. Smoke test — Deploy sonrası otomatik doğrulama
6. Monitoring — Golden signals'ı deploy sırasında yoğun izleyin

Sonuç

Sıfır kesintili deployment, modern yazılım geliştirmenin standardıdır. Blue-Green hızlı geçiş ve geri alma sağlar, Canary ise riski kademeli olarak yönetmenizi sağlar. Ekibinizin ihtiyacına göre doğru stratejiyi seçin.

Deployment stratejilerini LabLudus platformunda öğrenin.