RELEASE STRATEJİLERİ: CANARY, BLUE/GREEN VE ROLLBACK TASARIMINDA İNCELİKLER

Yeni bir sürümü canlıya almak artık “deploy edip dua etmek” değil; trafik yönetimi, ölçülebilir doğrulama ve iyi tasarlanmış bir geri dönüş yolu gerektiren mühendislik disiplini. Canary, Blue/Green ve Rollback birlikte ele alındığında, sadece riski azaltmaz; aynı zamanda değişiklik hızını da artırır.

Bu makalede “release stratejileri” başlığı altında canary ve blue/green yaklaşımlarını ince detaylarıyla karşılaştıracak, hangi koşulda hangisinin daha iyi sonuç verdiğini konuşacağız. En kritik nokta ise çoğu ekibin sonradan fark ettiği gerçek: Rollback bir düğme değil, baştan kurgulanan bir tasarımdır.

Hedefimiz, üretimdeki davranışa dayanarak karar veren (metric-driven) ve geri dönüşü otomatikleştiren bir yaklaşım kurmak. Eğer ekibiniz CI/CD olgunluğunu ilerletmek istiyorsa, ilgili program için CI/CD DevOps Eğitimi sayfasına da göz atabilirsiniz.

Primary odak: Release stratejileri ile risk, hız ve kaliteyi birlikte yönetmek

“Release stratejileri” dediğimizde aslında tek bir konu konuşmuyoruz; riskin dağıtılması, geri bildirim döngüsünün kısaltılması ve “yanlış giden şeyi hızlıca sınırlama” kabiliyetini konuşuyoruz. Canary ve Blue/Green bu hedeflere farklı yollardan gider: biri kademeli doğrulama, diğeri çevre izolasyonu üzerinden.

Bu stratejilerin başarısı, yalnızca deployment tekniğiyle değil; observability, veri modeli, veritabanı şeması, cache davranışı, sürüm uyumluluğu ve operasyonel prosedürlerle birlikte belirlenir. Yani strateji seçiminden önce “sisteminizin hangi tür hatalara açık olduğunu” netleştirmek gerekir.

Başarı kriteri: “Değişiklik güvenilirliği” ve ölçülebilir sinyaller

Çoğu ekip “deploy başarılı mı?” sorusunu yanlış tanımlar. Deployment pipeline’ı yeşil olabilir ama kullanıcı tarafı kırılmış olabilir. Bu yüzden doğrulama sinyallerini en baştan tanımlamak gerekir: hata oranı, gecikme yüzdelikleri (p95/p99), doygunluk (CPU, queue depth), iş metriği (checkout success, ödeme dönüş oranı) ve SLO ihlal göstergeleri.

Release stratejisi seçerken temel sorular

• Değişiklik, kullanıcı deneyimini anında etkiliyor mu, yoksa gecikmeli mi?
• Hata geri alınabilir mi, yoksa veri kalıcı şekilde bozulabilir mi?
• İki sürümün aynı anda çalışması gerekiyor mu (backward compatibility)?
• Trafik yönlendirme altyapısı hazır mı (Ingress, service mesh, LB)?
• Geri dönüş süresi hedefi nedir (MTTR, RTO)?

Canary deployment: Kademeli trafik ve metrik temelli doğrulama

Canary deployment, yeni sürümü küçük bir kullanıcı kitlesine açıp, davranışı ölçerek kademeli şekilde genişletme yaklaşımıdır. En büyük avantajı, problemi küçük bir yüzdede yakalayıp etki alanını sınırlamasıdır. Ancak canary “sadece yüzdeyi artırmak” değildir; asıl mesele doğru metrikleri doğru süre boyunca izlemek ve kararları otomatikleştirmektir.

Canary tasarımında en sık kaçırılan detay, sinyal gecikmesidir. Örneğin ödeme hatası 2 dakika sonra log’a düşüyor, alarm 5 dakika sonra tetikleniyor, dashboard gecikmesi 1 dakika… Bu durumda 10 dakikalık bir canary adımı, gerçek hatayı “görmeden” bir sonraki adıma geçebilir. Adım süreleri, metriklerin gecikme özelliklerine göre belirlenmelidir.

Canary adımları: Yüzde, süre ve durdurma kriterleri

İyi bir canary planı “%1 → %5 → %25 → %50 → %100” gibi bir merdivenden fazlasıdır. Her adımın bir bekleme süresi, bir başarı eşiği ve başarısızlıkta uygulanacak aksiyonları vardır. Bu aksiyonlar çoğu durumda otomatik geri alma (abort + rollback) veya trafik geri yönlendirme şeklinde olmalıdır.

Service mesh ve Ingress ile trafik yönlendirme seçenekleri

Canary, farklı katmanlarda uygulanabilir: L7 Ingress (Nginx, ALB), service mesh (Istio/Linkerd) veya platform özellikleri (Argo Rollouts). Hangi katmanı seçerseniz seçin, “tutarlı yönlendirme” kritik hale gelir. Oturumlu kullanıcılar için sticky session, region bazlı trafik, header/cookie ile segmentasyon gibi ihtiyaçlar planlanmalıdır.

Argo Rollouts ile canary örneği

Aşağıdaki örnek, canary adımlarını ve analiz penceresini gösteren gerçekçi bir progressive delivery kurgusudur. Buradaki mantık, yeni ReplicaSet’i küçük yüzdelerle devreye alıp, her adımda metrik analizi yapmaktır.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout-service
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 5
      - pause: { duration: 5m }
      - setWeight: 20
      - pause: { duration: 10m }
      - setWeight: 50
      - pause: { duration: 15m }
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      containers:
      - name: checkout
        image: registry.example.com/checkout:1.8.0
        ports:
        - containerPort: 8080

Blue/Green deployment: Çevre izolasyonu ile hızlı geçiş

Blue/Green deployment’ta iki tam çevre düşünürsünüz: “blue” mevcut üretim, “green” yeni sürüm. Yeni sürüm green üzerinde hazırlandığında, trafik bir anda green’e alınır. En büyük avantajı, geçişin hızlı ve geri dönüşün basit olmasıdır; ancak maliyet (çift kapasite), veri uyumluluğu ve stateful bileşenler nedeniyle planlama ister.

Blue/Green özellikle büyük değişikliklerde, UI veya routing üzerinde net ayrımlar olduğunda ve “tam bir doğrulama ortamı” gerektiğinde güçlüdür. Bununla birlikte, gerçek dünya trafiği ile tam yük testi yapmak istiyorsanız shadow traffic veya request mirroring gibi teknikler devreye girebilir.

Blue/Green geçişinde en kritik konu: Veri ve şema uyumluluğu

Trafiği bir anda yeni sürüme almak kolay, veriyi uyumlu hale getirmek zordur. Şema değişiklikleri için “expand/contract” modeli, geriye dönük uyumlu migration’lar, çift yazım (dual-write) ve kademeli okuma gibi desenler Blue/Green’i güvenli kılar. Eğer veritabanı migration’ı geri alınamıyorsa, rollback sadece uygulama sürümünü geri almakla sınırlı kalır ve gerçek sorun çözülmez.

Load balancer switch ve smoke test akışı

Blue/Green’de, switch öncesi green üzerinde smoke test, sentetik kontrol ve kısa süreli load test yapılır. Switch sonrası ise hızlı doğrulama gerekir. Burada otomatik geri dönüş koşulları belirlemek büyük fark yaratır: kritik endpoint hata oranı, p99 gecikmesi, saturation ve iş metriği eşiği.

Rollback tasarımında incelikler: “Geri al” butonu değil, sistem davranışı

Rollback, hatayı sıfırlamak değildir; etki alanını sınırlamak ve stabil duruma dönmektir. İyi bir rollback tasarımı, “hangi bileşenler hangi sırayla geri alınacak?” sorusunu baştan yanıtlar. Uygulama sürümü, config, feature flag, veritabanı şeması, cache ve mesaj kuyruğu tüketicileri birbirine bağlıdır.

Rollback planı yoksa, canary veya blue/green sadece “daha sofistike bir hata üretme yöntemi”ne dönüşebilir. Bu yüzden geri dönüş stratejisinin üç boyutu olmalı: teknik (deployment), veri (migration), ürün (özellik kapanması).

Feature flag ile geri dönüş: En hızlı sigorta

Geri dönüşü hızlandırmanın en pratik yollarından biri, riskli fonksiyonları feature flag arkasına almaktır. Böylece deploy geri almadan, işlevi kapatabilirsiniz. Bu yaklaşım, özellikle anlık üretim riski taşıyan akışlarda önemlidir. Ancak flag yönetimi disiplinsiz yapılırsa, teknik borç hızla büyür.

Konfigürasyon ve secret değişiklikleri için “versiyonlama”

Birçok kesinti, uygulama kodundan değil konfigürasyondan gelir. Config değişikliklerini de sürümlemek, değişiklikleri audit edilebilir kılar. Blue/Green’de green çevresinin config’i blue ile uyumlu değilse, switch anında beklenmeyen davranışlar ortaya çıkar.

Gözlemlenebilirlik ve doğrulama: Sinyaller olmadan progressive delivery olmaz

Canary ve Blue/Green, observability yoksa kör sürüş gibidir. Log, metric ve trace üçlüsü; ayrıca iş metrikleri, SLO ve hata bütçesiyle tamamlanmalıdır. “Hangi metrikleri izleyeceğim?” sorusunun cevabı, sisteminizin kullanıcıya verdiği sözle (SLO) başlar.

Doğrulama otomasyonu için iki yaklaşım öne çıkar: threshold bazlı basit kurallar ve istatistiksel karşılaştırmalar (baseline vs canary). Basit kurallar hızlıdır; istatistiksel yaklaşım gürültüye daha dayanıklıdır. İkisini birlikte kullanmak çoğu ekipte iyi sonuç verir.

Örnek doğrulama kuralları seti

• HTTP 5xx oranı: canary, baseline’ın %20 üzerine çıkarsa durdur
• p95 gecikme: 3 dakika boyunca eşiği aşarsa geri al
• Ödeme başarı oranı: %0.5 düşerse müdahale et
• Queue lag: belirli bir lag üzerinde ölçekle, düzelmiyorsa rollback

Pipeline kurgusu: Gate’ler, otomasyon ve operatör deneyimi

İyi bir CI/CD hattı, release stratejisini “son adım” olarak görmez; her aşamayı stratejiye hizmet edecek şekilde tasarlar. Örneğin canary yapacaksanız, image build sonrası otomatik smoke test, staging’te sentetik test, ardından canary adımlarına geçiş ve her adımda analiz gate’i gerekir.

Operatör deneyimi de önemli bir parça: “Şu an hangi yüzde, hangi metrik, hangi karar bekleniyor?” sorularının tek ekranda görülebilmesi gerekir. Aksi halde insanlar panikle manuel müdahaleye gider ve süreç standardizasyonu bozulur.

GitHub Actions ile kontrollü release örneği

Aşağıdaki örnek, release’i manuel onay (environment gate) ve otomatik rollback tetikleyicisiyle birleştiren basitleştirilmiş bir akışı gösterir. Burada amaç, kritik adımlarda insan onayıyla birlikte metrik kontrollü otomasyonu bir araya getirmektir.

name: deploy-production
on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build and push
        run: |
          docker build -t registry.example.com/checkout:${{ github.sha }} .
          docker push registry.example.com/checkout:${{ github.sha }}
      - name: Apply rollout
        run: |
          kubectl set image rollout/checkout-service checkout=registry.example.com/checkout:${{ github.sha }}
          kubectl argo rollouts promote checkout-service
      - name: Verify metrics
        run: |
          ./scripts/verify_slo.sh --service checkout --window 10m

Canary mi Blue/Green mi: Karar matrisi ve pratik seçimler

Tek bir doğru yok; sistemin doğası ve risk profili seçimi belirler. Canary, kademeli risk azaltır ve sürekli teslimatta çok güçlüdür. Blue/Green ise büyük sıçramalarda, geri dönüş hızının kritik olduğu durumlarda ve çevre izolasyonunun değer kattığı senaryolarda avantaj sağlar.

Hangi durumda canary daha iyi çalışır?

• Trafiği kademeli artırarak güven toplamak istiyorsanız
• İyileştirme küçük ve sık değişikliklerle geliyorsa
• Observability olgun ve metrik analizi güvenilir ise
• İki sürümün bir süre birlikte çalışması mümkünse

Hangi durumda Blue/Green daha iyi çalışır?

• Geçişin “tek hamle” olması isteniyorsa
• Geri dönüşün saniyeler içinde olması kritikse
• Çevre izolasyonu ile kapsamlı doğrulama gerekiyorsa
• Önceden hazırlanmış kapasite ve otomasyon varsa

Yaygın tuzaklar ve ince ayarlar: Başarıyı belirleyen detaylar

Stratejiyi seçmek işin küçük kısmı; onu doğru uygulamak asıl zorluk. Canary’de en büyük tuzak, yanlış metrik veya yanlış zaman penceresiyle karar vermek. Blue/Green’de ise en büyük tuzak, veri uyumluluğunu ihmal edip “switch” anında geri dönüşü anlamsız kılmak.

Bir diğer tuzak, release stratejisini ürün stratejisinden kopuk düşünmek. Örneğin riskli bir özelliği canary ile açıyorsunuz ama kullanıcı segmentasyonu yoksa, en değerli müşterilerinizi %1’lik dilimde yakalama ihtimaliniz bile vardır. Burada segment bazlı canary (header/cookie) veya feature flag ile kontrollü açılış devreye girmelidir.

İnce ayar önerileri

1. Adım sürelerini metrik gecikmesine göre ayarlayın
2. Rollback’ı “uygulama + veri + ürün” boyutlarında planlayın
3. Önce küçük değişikliklerle canary pratikleri oturtun
4. Şema değişikliklerinde expand/contract yaklaşımını standartlaştırın
5. Runbook’ları otomasyona yakın yazın, stres anında okunabilir tutun

Sonuç: Progressive delivery kültürüyle sürdürülebilir hız

Canary ve Blue/Green, tek başlarına sihirli çözümler değil; doğru metrikler, doğru otomasyon ve iyi tasarlanmış rollback ile birlikte anlam kazanır. Bu üçlü bir araya geldiğinde, ekipler hem daha hızlı release yapar hem de üretimde daha az sürpriz yaşar.

Başlangıç için küçük bir adım bile büyük fark yaratır: bir serviste canary yüzdesi ve net bir doğrulama penceresi tanımlayın, ardından rollback koşullarını otomatikleştirin. Zamanla bu pratik, release stratejilerini “istisna” olmaktan çıkarıp günlük rutine dönüştürür.