Blue-Green Deployment Nedir? Kesintisiz Yayın Rehberi

Meta Description

Blue-green deployment ile kesintisiz deploy yapın. Trafiği güvenle yönetin, hızlı rollback alın. Adım adım rehber ve Nginx örneği.

Giriş (Introduction)

Prod’a yeni sürüm çıkınca birkaç dakika bile kesinti yaşamak, hem kullanıcıyı hem geliri etkileyebilir. Daha kötüsü: “Deploy ettik, bir şeyler ters gitti ama geri dönemiyoruz” senaryosu.

Blue-green deployment, bu riski minimize eden, trafiği iki ayrı ortama (eski ve yeni sürüm) yöneterek kesintisiz yayın yapmanızı sağlayan pratik bir yöntemdir. Bu yazıda, blue-green deployment’ı ne zaman kullanmanız gerektiğini, nasıl kurulduğunu ve gerçek hayatta nasıl uygulandığını adım adım göreceksiniz.

---

Blue-Green Deployment Nedir?

Blue-green deployment, uygulamanın iki canlı ortamla çalıştığı bir dağıtım stratejisidir:

• Blue (mavi): Şu an trafiği alan, aktif üretim sürümü
• Green (yeşil): Yeni sürümün hazırlandığı paralel ortam

Yeni sürümü (green) hazırlayıp test edersiniz; her şey doğruysa trafiği bir “switch” ile green’e alırsınız. Sorun çıkarsa anında blue’ya geri dönersiniz (rollback).

Ana fikir: Yeni sürümü canlıya çıkarmadan önce canlıya çok benzeyen bir ortamda hazırla ve trafiği tek hamlede değiştir.

---

Blue-Green Deployment’ı Neden Yapmalıyım?

Blue-green deployment’ın en büyük avantajı “deploy korkusunu” azaltmasıdır.

Kazanımlar

• Kesintisiz yayın (zero-downtime): Trafik switch’ine kadar kullanıcı etkilenmez.
• Hızlı rollback: DB migration gibi geri dönüşü zor noktaları ayrı yönetirseniz, rollback saniyeler içinde olur.
• Risk izolasyonu: Yeni sürüm, prod trafiği almadan önce doğrulanır.
• Release güveni: Her deploy “büyük olay” olmaktan çıkar.

Ne zaman özellikle mantıklı?

• E-ticaret / ödeme / kritik akışlar
• Trafiğin yoğun olduğu saatlerde deploy ihtiyacı
• Mikroservis veya monolit fark etmeksizin “sık release” yapan ekipler

LSI anahtar kelimeler: kesintisiz deploy, zero downtime deployment, rollback stratejisi, trafik yönlendirme, release yönetimi, deployment stratejileri

---

Blue-Green vs Rolling Deploy vs Canary (Kısa Karşılaştırma)

Aşağıdaki tablo “hangi strateji ne zaman?” sorusunu netleştirir:

Strateji	Trafik Geçişi	Risk	Rollback	Ne zaman?
Blue-Green Deployment	Tek hamlede (switch)	Orta	Çok hızlı	Kesintisiz ve hızlı geri dönüş isteniyorsa
Rolling Deployment	Kademeli instance değişimi	Orta	Orta	Basit, altyapı hazırsa
Canary Release	Yüzdeyle kademeli	Düşük	Orta	Deney/ölçüm, kademeli doğrulama gerekiyorsa

Blue-green deployment özellikle “geri dönüş hızının kritik olduğu” ortamlarda öne çıkar.

---

Mimari: Trafik Switch’i Nerede Yapılır?

Blue-green deployment’ta kritik nokta, trafiği hangi katmanda yönettiğinizdir:

Yaygın seçenekler

1. Load balancer (ALB/NLB, GCLB, Nginx, HAProxy)
2. Ingress Controller (Kubernetes Ingress / NGINX Ingress)
3. DNS switch (daha yavaş; TTL ve cache yüzünden gecikmeli)

Pratik öneri: Mümkünse load balancer / ingress üzerinden switch yapın. DNS tabanlı switch, rollback’te can yakabilir.

---

Adım Adım Blue-Green Deployment (Uygulanabilir Plan)

Bu bölüm, gerçek hayatta uygulanabilir bir check-list gibi tasarlandı.

1) Blue ve Green ortamlarını tanımla

• Aynı uygulamanın iki kopyası: app-blue ve app-green
• Aynı bağımlılıklar (env vars, secrets, network rules)
• Log/metric/trace aynı standarda göre

İpucu: Green ortamı “prod’a benzer” değil, prod ile aynı olmalı (mümkün olduğunca).

2) Green’e yeni sürümü deploy et

• CI/CD pipeline: build → test → deploy to green
• Trafik henüz green’e gitmiyor

Bu aşamada yapılacaklar:

• Smoke test
• En kritik user journey testleri (login, ödeme, arama, kayıt)

3) Green’de doğrulama (verification)

“Çalışıyor” demek için minimum kontrol:

• Health check endpoint: /health veya /ready
• Kritik bağımlılıklar: DB bağlantısı, cache, queue
• Temel performans: cevap süreleri, error rate

4) Trafiği green’e al (switch)

Bu, load balancer/ingress seviyesinde bir ayar değişikliğidir.

5) İzle ve karar ver (observe)

Trafik geçişinden sonraki ilk 5–15 dakika çok kritiktir:

• 5xx artışı var mı?
• Latency yükseldi mi?
• CPU/RAM anormal mi?
• Business metrikleri (checkout success vs.)

6) Sorun varsa anında rollback

Rollback, trafiği tekrar blue’ya çevirmek demektir. Green ortamı durur veya debug için açık kalır.

---

Nginx ile Basit Blue-Green Trafik Switch Örneği

Aşağıdaki örnekte Nginx upstream ile trafiği blue’dan green’e geçiriyoruz.

Nginx config (upstream switch)

upstream app_backend {

# Başlangıçta blue aktif
    server 10.0.1.10:8080;

# app-blue

# server 10.0.2.10:8080;

# app-green
}

server {
    listen 80;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Green’e geçiş nasıl yapılır?

• Blue satırını comment’leyip green’i açın:

upstream app_backend {

# server 10.0.1.10:8080;

# app-blue
    server 10.0.2.10:8080;

# app-green
}

• Ardından:

nginx -t && nginx -s reload

Rollback aynı işlemin tersidir. Bu kadar.

Not: Gerçek sistemlerde daha güvenli olması için iki backend’i de tanımlayıp weight kullanabilir veya upstream’te “backup” kurgusu yapabilirsiniz.

---

En Büyük Tuzak: Veritabanı Değişiklikleri (DB Migration)

Blue-green deployment uygulamada kolaydır; zor olan genelde veri katmanıdır.

Neden zor?

Blue ve green aynı DB’yi kullanıyorsa, schema değişikliği:

• Blue’yu bozabilir
• Green’i beklenmedik şekilde etkileyebilir

Güvenli yaklaşım: Expand/Contract

1. Expand: Geriye dönük uyumlu değişiklik (yeni kolon ekle, eskiyi silme)
2. Uygulamayı deploy et (green)
3. Trafiği geçir
4. Contract: Eski alanları temizle (daha sonra)

Kural: Önce şemayı genişlet, sonra kodu değiştir, en son temizle.

---

Gerçek Hayat Senaryosu: E-ticarette Kampanya Günü Deploy

Bir kampanya gününde ödeme servisinde yeni bir “kupon doğrulama” akışı çıkacaksınız.

• Green’e yeni sürümü deploy ettiniz.
• Green ortamında gerçek ödeme sağlayıcısına gitmeden sandbox ile smoke test yaptınız.
• Trafiği green’e aldınız.
• İlk 3 dakikada 5xx artışı gördünüz (kupon servisi timeout).

Blue-green sayesinde:

• Trafiği saniyeler içinde tekrar blue’ya aldınız.
• Satış kaybını minimize ettiniz.
• Green ortamında hatayı debug edip fix’i tekrar green’e deploy ettiniz.

Bu modelin değeri, “hata olmayacak” varsayımı değil; hata olduğunda hasarı sınırlamaktır.

---

Sık Sorulan Sorular (FAQ)

1) Blue-green deployment ile gerçekten sıfır kesinti mümkün mü?

Evet, doğru health check ve doğru trafik switch katmanı ile genelde kullanıcı fark etmeyecek kadar kesintisiz olur. En büyük risk DB değişiklikleridir.

2) Blue-green deployment Kubernetes’te nasıl yapılır?

Genelde iki Deployment (blue/green) ve bir Service/Ingress’in selector veya route ayarını değiştirerek yapılır. Argo Rollouts gibi araçlar da kullanılabilir.

3) DNS ile blue-green switch yapmak mantıklı mı?

Genelde önerilmez. TTL ve cache yüzünden geçiş/rollback gecikebilir. Load balancer veya ingress daha güvenlidir.

4) Blue-green deployment pahalı mı?

İki ortam aynı anda çalıştığı için kısa süreliğine maliyeti artırabilir. Ancak downtime maliyeti yüksek ürünlerde bu maliyet genelde daha düşüktür.

5) Her deploy’da blue ve green’i yer değiştirmek gerekir mi?

Hayır. İsterseniz “blue hep prod, green staging” gibi kullanabilirsiniz; ancak pratikte her release’te aktif taraf değiştirerek ilerlemek yaygındır.

---

Sonuç

Blue-green deployment, kesintisiz yayın yapmak ve gerektiğinde saniyeler içinde rollback alabilmek için en net ve uygulanabilir stratejilerden biridir. Trafiği “tek hamlede” yönettiğiniz için release süreci sadeleşir; risk yönetimi güçlenir.

Bir sonraki deploy’unuzda şunu deneyin:

1. Green ortamı hazırlayın
2. Smoke test + health check ekleyin
3. Trafiği load balancer/ingress üzerinden switch edin

Sorunuz varsa yorumda altyapınızı (VM/Kubernetes, Nginx/ALB, DB tipi) yazın; senaryonuza uygun blue-green planını birlikte netleştirelim.