Progressive Delivery 2026: Canary, Blue-Green ve Feature Flag Birlikte

Progressive Delivery Nedir ve Neden 2026’da Standart Oldu?

Progressive Delivery, yeni bir sürümü tüm kullanıcılara aynı anda açmak yerine, riski kademeli kontrol ederek yayma pratiğidir: değişiklik önce küçük bir kullanıcı dilimine gider, metrikler izlenir ve sorun yoksa kapsam yavaşça genişletilir. Üç temel tekniği bir arada kullanır: canary (yüzdesel kademeli yayma), blue-green (anlık geçiş + anında geri alma) ve feature flag (kodda saklı özelliği çalışma anında açıp kapama). Tek başına hiçbiri yeterli değildir; gücü birlikte kullanımdadır.

DORA State of DevOps araştırması, yüksek performanslı ekiplerin değişiklik başarısızlık oranını %15’in altında tutarken günde defalarca dağıttığını gösterir. Bu hız ve güvenliğin aynı anda elde edilmesinin yolu progressive delivery’dir: dağıtım (deploy) ile yayınlama (release) ayrıştırılır, böylece kod prod’a çıkar ama özellik kontrollü açılır. Bu rehber üç tekniği, birlikte kullanım desenlerini ve otomatik geri alma stratejilerini sayısal olarak açar.

Progressive delivery’nin 2026’da standart haline gelmesinin altında somut bir ölçüm yatar. DORA çerçevesinin dört temel metriği (dağıtım sıklığı, değişiklik öncü süresi, değişiklik başarısızlık oranı ve hizmeti geri yükleme süresi) bir araya getirildiğinde, geleneksel “tümünü aynı anda yayınla” yaklaşımının hem riski hem geri yükleme süresini artırdığı görülür: bir sorun çıktığında tüm kullanıcı kitlesi etkilenir ve geri alma tüm sistemi kapsar. Progressive delivery, başarısızlık oranını düşürmez ama başarısızlığın etki yüzeyini (blast radius) küçültür; bir hata yalnızca %5’lik bir dilime ulaşır ve saniyeler içinde geri çekilir. Yani metrik iyileşmesi, hataları yok etmekten değil, hataların maliyetini düşürmekten gelir. Bu, dağıtım sıklığını korkmadan artırmayı mümkün kılar; ekipler günde defalarca dağıtırken her dağıtımın riski yapısal olarak sınırlıdır.

Canary Deployment: Yüzdesel Kademeli Yayma

Canary deployment, yeni sürümü önce kullanıcıların %1-5’ine yönlendirir, hata oranı ve gecikme gibi metrikleri izler, sorun yoksa %10, %25, %50 ve %100 olarak kademeli artırır. Adını maden işçilerinin zehirli gazı erken sezmek için kullandığı kanaryadan alır: sorun, tüm kullanıcıyı etkilemeden küçük dilimde yakalanır.

• Metrik tabanlı ilerleme: Her adımda hata oranı, P95 gecikme ve CPU izlenir; eşik aşılırsa otomatik durur.
• Otomatik analiz: Argo Rollouts ve Flagger, Prometheus metriklerine bakarak ilerleme/geri alma kararını otomatik verir.
• Trafik kontrolü: Service mesh (Istio, Linkerd) veya ingress ağırlık tabanlı yönlendirme sağlar.
• Hızlı geri alma: Sorun görülürse trafik anında eski sürüme döner, etki dilimle sınırlı kalır.

Blue-Green Deployment: Anlık Geçiş ve Anında Geri Alma

Blue-green, iki özdeş üretim ortamı tutar: blue (canlı) ve green (yeni sürüm). Trafik tek bir anahtarla green’e geçirilir; sorun çıkarsa anında blue’ya dönülür. Canary’den farkı, kademeli değil ani geçiş yapmasıdır; en büyük gücü ise saniyeler içinde geri alma (rollback) sağlamasıdır.

Blue-green’de en kritik nokta veritabanı şema uyumudur: green ve blue aynı şemayı paylaştığı için değişiklikler geriye uyumlu (backward compatible) olmalıdır. GitOps ile Argo CD/Flux bu geçişleri bildirimsel ve denetlenebilir kılar.

Blue-green’in en sık göz ardı edilen maliyeti, geçiş penceresi boyunca iki tam ortamın aynı anda çalışmasıdır; bu, o süre için compute maliyetini ikiye katlar. Bu yüzden olgun ekipler green ortamını yalnızca geçiş penceresinde tam kapasitede tutar, geçiş tamamlanıp blue doğrulama amacıyla bir süre beklendikten sonra eski ortamı ölçekleyerek maliyeti normale döndürür. Bir diğer incelik, oturum durumudur (session state): trafik anlık olarak green’e geçtiğinde, blue’da açık olan kullanıcı oturumları kesilmemelidir. Bu nedenle blue-green, durumun uygulama dışında (örneğin paylaşımlı bir oturum deposunda) tutulduğu durumsuz (stateless) uygulamalarda en sorunsuz çalışır. Canary ile karşılaştırıldığında blue-green daha hızlı geri alma sunar ama daha kaba taneli (granularity) bir kontrol verir: ya tüm trafik eski sürümde ya tüm trafik yeni sürümdedir, ikisinin arası yoktur. Bu yüzden hata oranının kademeli gözlemlenmesi gereken yüksek trafikli API’lerde canary, anında ve toplu geri alma gereken kritik sistemlerde blue-green tercih edilir.

Feature Flag: Dağıtımı Yayınlamadan Ayırmak

Feature flag (özellik bayrağı), bir özelliği kodda hazır tutar ama çalışma anında açıp kapatılan bir anahtarla kontrol eder. Bu sayede kod prod’a dağıtılır ancak özellik kullanıcıya kapalı kalır; istediğiniz an, istediğiniz segmente açarsınız. Dağıtım ile yayınlamayı tamamen ayırır, bu da progressive delivery’nin temel taşıdır.

• Kill switch: Sorun çıkan özellik deploy beklemeden anında kapatılır.
• Aşamalı açılış: Özellik önce iç ekibe, sonra %5 kullanıcıya, sonra herkese açılır.
• A/B testi: İki varyant farklı segmentlere sunulur, metrik karşılaştırılır.
• İzin tabanlı erişim: Premium özellikler abonelik segmentine bağlanır.

Standart ve araç seçimi için feature flag pazar manzarası ve OpenFeature ile vendor-neutral standart derinleşir. Vendor-neutral standart için OpenFeature (CNCF projesi) sağlayıcı bağımlılığını azaltır. Uzun ömürlü bayraklar teknik borç yaratır; her bayrağın bir son kullanma tarihi olmalıdır.

Feature flag’in dağıtımı yayınlamadan ayırması, mühendislik kültürünü kökten değiştirir. Geleneksel modelde bir özelliğin tamamlanması, prod’a çıkmasıyla eş anlamlıdır; bu yüzden yarım kalan kod uzun ömürlü dallarda (feature branch) bekletilir ve birleştirme zamanı geldiğinde büyük, riskli bir çatışma yaratır. Flag yaklaşımında ise kod, henüz tamamlanmamış olsa bile bayrak arkasında kapalı olarak ana dala (trunk) sürekli birleştirilir; bu, trunk-based development pratiğinin temelidir ve büyük birleştirme acılarını ortadan kaldırır. Bayrakların türleri de farklı yaşam döngülerine sahiptir: yayın bayrakları (release flags) bir özellik tam açıldıktan sonra temizlenmelidir, deney bayrakları (experiment flags) testin süresi kadar yaşar, operasyonel bayraklar (kill switch) ise kalıcı olabilir. Bu türleri ayırmamak, en yaygın teknik borç kaynağıdır; binlerce eskimiş bayrak kod tabanını okunamaz hale getirir ve her bayrak bir dallanma noktası olduğu için test yüzeyini katlanarak büyütür. Bu yüzden disiplinli ekipler her yayın bayrağına bir sahip ve bir son kullanma tarihi atar, süresi dolan bayrakları düzenli temizler.

Üç Tekniği Birlikte Kullanmak

Progressive delivery’nin asıl gücü, üç tekniğin tek bir akışta birleşmesindedir. Tipik bir olgun pipeline şöyle çalışır: feature flag ile özellik kapalı dağıtılır (deploy), canary ile altyapı sürümü kademeli yayılır, blue-green ile ani geri alma güvencesi verilir, sonra flag kademeli açılır (release).

1. Dağıt: Yeni kod feature flag arkasında kapalı olarak prod’a çıkar — risk sıfıra yakın.
2. Altyapı canary: Yeni sürüm %5-25-50 trafiğe canary ile yayılır, sistem metrikleri izlenir.
3. Flag aç: Özellik önce %1 kullanıcıya açılır, iş metrikleri (dönüşüm, hata) izlenir.
4. Genişlet veya geri al: Sonuç iyiyse flag kademeli %100 olur; kötüyse flag anında kapanır (kill switch).

Veritabanı Değişiklikleri: Expand-Contract Deseni

Progressive delivery’nin en sık kırıldığı nokta veritabanı şema değişiklikleridir. Canary veya blue-green’de eski ve yeni sürüm aynı anda çalıştığı için şema, her iki sürümle de uyumlu olmalıdır. Bu zorluğu çözen yöntem expand-contract (genişlet-daralt) desenidir: önce şema yeni alanı ekleyerek genişletilir (her iki sürüm de çalışır), sürüm tamamlanınca eski alan kaldırılarak daraltılır.

Bu desen, kesintisiz şema evrimini mümkün kılar ve geri alma sırasında veri kaybını önler. Yıkıcı (destructive) değişiklikler asla tek adımda yapılmaz; her zaman önce genişletilir, sürüm oturduktan sonra daraltılır.

Otomatik Geri Alma ve Metrik Tabanlı Kararlar

Manuel izleme ile progressive delivery yarım kalır; gerçek değer otomatik analiz ve geri almadadır. Argo Rollouts ve Flagger, her canary adımında Prometheus metriklerini sorgular, başarı oranını hesaplar ve eşik altına düşünce dağıtımı otomatik durdurup geri alır. İnsan gece yarısı uyanmadan sistem kendini korur.

Otomatik analizin güvenilirliği, hangi metriklere bakıldığına bağlıdır. Yalnızca hata oranına bakan bir canary analizi yanıltıcıdır; bir sürüm hatasız ama belirgin biçimde yavaş olabilir veya bellek sızıntısıyla kademeli doygunluğa gidebilir. Bu yüzden olgun canary kuralları, gözlemlenebilirliğin dört altın sinyalini (golden signals) birlikte değerlendirir: gecikme (latency), trafik (traffic), hata (errors) ve doygunluk (saturation). Bunların üzerine iş metrikleri (dönüşüm oranı, sepete ekleme, ödeme tamamlama) eklenir; çünkü teknik olarak sağlıklı görünen bir sürüm, kullanıcı davranışını sessizce bozuyor olabilir. Bir diğer kritik tasarım kararı, her canary adımının minimum gözlem süresi ve minimum istek eşiğidir: düşük trafikte birkaç istek üzerinden hesaplanan bir başarı oranı istatistiksel olarak anlamsızdır. Bu yüzden canary, yeterli örnek toplanana kadar bir sonraki adıma ilerlemez; aksi halde gürültüyü sinyal sanıp yanlış kararlar verir.

Tipik Sorunlar ve Çözümleri

Progressive delivery yanlış kurulduğunda güvenlik ağı olmaktan çıkıp ek karmaşıklığa dönüşür. En sık karşılaşılan sorunlar ve çözümleri:

• Yetersiz canary metriği: Yalnızca hata oranına bakılıyor, gecikme kaçıyor. Çözüm: hata, gecikme, doygunluk ve iş metriği birlikte izle (golden signals).
• Veritabanı uyumsuzluğu: Blue-green geçişte şema kırılıyor. Çözüm: geriye uyumlu migrasyon (expand-contract deseni) uygula.
• Bayrak çöplüğü: Eski feature flag’ler birikip teknik borç oluyor. Çözüm: her bayrağa son kullanma tarihi koy, düzenli temizle.
• Yavaş canary penceresi: Az trafikte metrik anlamlı olmuyor. Çözüm: minimum gözlem süresi ve istek eşiği tanımla.
• Manuel geri alma gecikmesi: İnsan müdahalesi yavaş kalıyor. Çözüm: metrik tabanlı otomatik rollback kur.
• Çift maliyet: Blue-green sürekli 2x ortam tutuyor. Çözüm: green’i yalnızca geçiş penceresinde aç, sonra ölçekle.

Sonuç ve Öneriler

Progressive delivery, hız ile güvenliği aynı anda sunan modern yayınlama disiplinidir. Canary riski trafik yüzdesiyle, blue-green ani geri almayla, feature flag ise dağıtımı yayınlamadan ayırarak kontrol eder; gerçek güç üçünün birlikte kullanılmasındadır. Olgun akış, kodu flag arkasında kapalı dağıtır, altyapıyı canary ile yayar, flag’i kademeli açar ve sorun anında kill switch ile kapatır. Manuel izleme yetmez: Argo Rollouts veya Flagger ile metrik tabanlı otomatik geri alma kurun, golden signal’ları izleyin ve her feature flag’e son kullanma tarihi verin. Veritabanı değişikliklerini her zaman geriye uyumlu yapın; aksi halde en güçlü güvenlik ağı bile geçişte kırılır.

Sıkça Sorulan Sorular