Deployment stratejisi seçimi, kullanıcı deneyimi, altyapı maliyeti ve operasyonel karmaşıklık arasında kalıcı bir trade-off'tur. Rolling update ve blue-green deploy en yaygın iki yaklaşımdır; ikisi de kesinti süresini minimize etmeyi hedefler ancak farklı risk profilleri ve altyapı gereksinimleri getirir. Doğru strateji, servisin durumu (stateful/stateless), trafik hacmi, veritabanı migration baskısı ve geri alma süresi beklentisine göre belirlenir.
Rolling deployment mekanizması
Kubernetes'te Deployment controller, replicas sayısını koruyarak pod'ları kademeli günceller. maxSurge ve maxUnavailable parametreleri güncelleme hızını ve kapasite düşüşünü kontrol eder:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
maxUnavailable: 0 ile her zaman tam kapasite hedeflenir; yeni pod ready olmadan eski pod silinmez. Readiness probe yanlış yapılandırılırsa trafik henüz hazır olmayan pod'a gider; bu en sık rolling deploy incident nedenidir.
Readiness ve lifecycle hook
Readiness probe uygulama gerçekten istek kabul edebildiğinde başarılı olmalıdır; yalnızca port dinlemek yeterli değildir. preStop hook ile SIGTERM öncesi bağlantı drain edilir; load balancer'dan çıkarılma gecikmesi telafi edilir. Grace period en az 30 saniye olmalıdır.
Blue-green deployment
İki özdeş ortam vardır: blue (aktif) ve green (yeni sürüm). Green tamamen doğrulandıktan sonra trafik tek seferde veya kademeli olarak green'e yönlendirilir. Blue, sorun halinde anında geri dönüş için hazır tutulur. Bu model çift altyapı maliyeti gerektirir ancak rollback süresi saniyelerle ölçülür.
- Load balancer switch: ALB/NGINX upstream değişimi.
- DNS flip: TTL ve cache nedeniyle yavaş; kritik sistemlerde tercih edilmez.
- Service mesh: Istio/Linkerd weight-based routing ile kademeli geçiş.
# Istio VirtualService örneği — %10 green
http:
- route:
- destination:
host: api
subset: blue
weight: 90
- destination:
host: api
subset: green
weight: 10
Karşılaştırma matrisi
Rolling deploy kaynak verimlidir; ekstra cluster kapasitesi gerektirmez. Blue-green hızlı rollback ve smoke test için idealdir. Canary (rolling'in ince taneli hali) metrik bazlı otomatik geri alma sağlar. Stateful workload'larda (Veritabanı, Kafka) her iki strateji de dikkatle planlanmalıdır.
Veritabanı migration uyumu
Expand-contract pattern, deployment ile schema değişikliğini uyumlu hale getirir. Yeni sürüm geriye uyumlu schema bekler; breaking migration deploy öncesi tamamlanır. Blue-green ile birlikte "backward compatible release" zorunluluğu artar. Flyway veya Liquibase migration'ları deploy pipeline'ında ayrı aşama olarak çalıştırılır; başarısız migration deploy'u durdurur.
Health check ve smoke test
Green ortam ayağa kalktığında otomatik smoke test suite çalıştırılır: kritik API endpoint'leri, auth akışı, cache warm-up. Başarısız smoke test trafik switch'ini engeller. Synthetic monitoring ile production'da sürekli doğrulama devam eder.
Session ve cache tutarlılığı
Sticky session kullanan uygulamalarda rolling deploy session kaybına yol açabilir. Redis gibi merkezi session store bu problemi ortadan kaldırır. Local in-memory cache blue-green geçişinde tutarsızlık üretir; distributed cache invalidation planı şarttır.
Kapasite ve maliyet
Blue-green için geçici çift kapasite gerekir; cloud autoscaling ile green peak saatlerde scale-up, switch sonrası blue scale-down yapılır. FinOps açısından geçiş penceresi maliyeti kabul edilebilir olmalıdır. Spot instance green ortamında risk artırır; production switch öncesi on-demand tercih edilir.
Otomasyon ve GitOps
Argo CD ve Flux, desired state'i Git'ten alır; rolling update Kubernetes native davranışıdır. Blue-green için Argo Rollouts, Flagger veya Spinnaker gibi ileri controller'lar progressive delivery sağlar. Pipeline "deploy" aşaması yalnızca manifest günceller; geri kalanı controller yönetir.
Incident senaryoları
- Partial rollout: Yeni sürümde memory leak; canary metrikleri otomatik rollback tetikler.
- Probe flapping: Pod sürekli restart; maxUnavailable düşürülür, root cause araştırılır.
- Config drift: Blue ve green farklı ConfigMap; parity kontrolü pipeline'a eklenir.
Metrikler
Deploy sırasında izlenmesi gerekenler: error rate, p99 latency, CPU, connection pool saturation. Kaydı zero olan error rate artışı anında rollback kriteridir. SLI/SLO tabanlı otomatik karar, gece deploy'larında güven verir.
Blue-green ve rolling deploy birbirinin alternatifi değil, farklı risk iştahına hitap eden araçlardır. Stateless mikroservislerde rolling yeterli olabilir; ödeme veya kimlik gibi kritik servislerde blue-green veya canary ile kontrollü geçiş hayati önem taşır. Probe kalitesi, migration disiplini ve otomatik rollback olgunluğu, seçilen stratejiden bağımsız olarak deploy güvenilirliğinin gerçek belirleyicileridir.
Feature flag ile birlikte deploy
Kod deploy'u ile özellik açılışını ayırmak, blue-green geçişini daha güvenli kılar. Yeni sürüm trafiğe alınsa bile feature flag kapalı kalır; smoke test sonrası flag açılır. Sorun halinde flag kapatmak, tam rollback'ten daha hızlıdır. LaunchDarkly, Unleash veya kendi flag servisiniz deploy stratejisinin tamamlayıcı parçası olmalıdır.
Database bağlantı havuzu geçişi
Blue-green switch sırasında eski ve yeni sürüm aynı anda veritabanına bağlanabilir. Connection pool limitleri bu çift yükü kaldırmalıdır. PgBouncer veya RDS Proxy gibi havuzlayıcılar geçiş penceresinde bağlantı yönetimini kolaylaştırır. Read replica lag'i green ortamda doğrulanmadan trafik switch yapılmamalıdır.
Canary ve progressive delivery
Canary deploy, rolling update ile blue-green arasında bir spektrum sunar. Trafiğin küçük bir yüzdesi yeni sürüme yönlendirilir; Prometheus alert veya Kayenta gibi analiz araçları error rate ve latency karşılaştırması yapar. Metrik eşiği aşılırsa otomatik rollback tetiklenir. Argo Rollouts AnalysisTemplate ile bu döngüyü Kubernetes native hale getirir. Canary adım yüzdeleri (5, 25, 50, 100) iş kritikliğine göre ayarlanır.
Cloud platform farkları
AWS ECS blue-green deploy CodeDeploy ile ALB target group arasında switch yapar. Azure App Service staging slot swap tek tıkla geçiş sağlar; swap öncesi warm-up ve health check zorunludur. Google Cloud Run revision traffic split yüzde bazlı yönlendirme sunar. Her platformun DNS propagation, connection draining ve idle timeout davranışı farklıdır; runbook platforma özel yazılmalıdır.
Rollback tatbikatı
Rollback planı kağıt üzerinde kalmamalıdır. Ayda bir staging ortamında kasıtlı bozuk sürüm deploy edilip geri alma süresi ölçülür. Rollback süresi SLO olarak tanımlanabilir: kritik servislerde 5 dakika altı. Trafik switch, veritabanı geri alma ve cache invalidation adımları runbook'ta numaralandırılmış olmalıdır. Deploy penceresi dışında yapılan acil rollback ile planlı rollback farklı prosedürler gerektirir.
Stateful servislerde dikkat
Kafka, RabbitMQ veya Elasticsearch gibi stateful bileşenler rolling update'i cluster quorum kurallarına tabi kılar. Blue-green bu sistemlerde genellikle yeni cluster kurup veri replikasyonu gerektirir; maliyet ve süre artar. Bu durumda önce stateless katmanı deploy edip, ardından stateful upgrade planı ayrı yürütülür. Mesaj kuyruğu tüketicileri geriye uyumlu mesaj formatı beklemelidir; schema evolution deploy stratejisinin parçasıdır.
Deploy stratejisi seçerken ekip olgunluğunu da hesaba katın. Rolling update Kubernetes'te varsayılan davranış olduğundan operasyonel yük düşüktür. Blue-green ve canary ise trafik yönetimi, metrik analizi ve otomasyon olgunluğu gerektirir. Erken aşamada basit rolling ile başlayıp incident oranı ve deploy sıklığı arttıkça progressive delivery'ye geçmek pragmatik bir yol haritasıdır. Her geçişte runbook güncellenmeli ve postmortem bulguları bir sonraki deploy planına yansıtılmalıdır. Deploy metriklerini quarterly review ile değerlendirmek, strateji seçiminin hâlâ doğru olup olmadığını gerçekten gösterir ve ekip öğrenmesini önemli ölçüde hızlandırır. Bu döngü sürdürülebilir deploy kültürünün temelidir.
