Canary Release Nedir? Yeni Sürüm Küçük Grupta Nasıl Test Edilir?

Yeni bir sürüm test ortamında sorunsuz çalışsa bile gerçek kullanıcı trafiğinde beklenmeyen davranışlar gösterebilir. Üretim verisinin dağılımı, cihaz çeşitliliği, yoğunluk, üçüncü taraf servisler ve kullanıcıların izlediği gerçek yollar laboratuvar koşullarından farklıdır. Sürümü bütün kullanıcılara aynı anda açmak, küçük bir uyumsuzluğun geniş çaplı hataya dönüşmesine neden olabilir.

Canary release, yeni sürümü önce sınırlı bir kullanıcı veya trafik grubuna açar. Ekip bu küçük grubun hata, gecikme ve iş sonuçlarını kararlı sürümle karşılaştırır; kabul kriterleri sağlanırsa yeni sürüm kademeli olarak daha geniş kitleye yayılır. Sorun görülürse canary trafiği durdurulur ve kullanıcıların büyük bölümü etkilenmeden geri dönüş yapılır.

Canary release nedir?

Canary release, yeni uygulama sürümünün production ortamında eski sürümle birlikte çalıştırıldığı ve trafiğin yalnızca küçük bir bölümünün yeni sürüme yönlendirildiği kademeli yayın stratejisidir. Kubernetes dokümantasyonu, yeni uygulama sürümünün önceki sürümün yanında çalıştırılarak tam rollout öncesinde canlı production trafiği almasının yaygın bir canary uygulaması olduğunu belirtir Kubernetes Workload Management.

Yöntemin amacı hatayı sıfırlamak değil, hatanın etkisini sınırlı tutarak daha erken kanıt üretmektir. Küçük grup teknik veya iş riski gösterirse rollout durdurulur. Sonuçlar kabul edilebilir kalırsa kapsam aşamalı biçimde artırılır.

Canary release nasıl çalışır?

Kararlı sürüm production trafiğinin büyük bölümünü taşımaya devam ederken yeni sürüm ayrı instance, pod, revision veya deployment grubu olarak çalıştırılır. Load balancer, service mesh, API gateway, ingress controller ya da uygulama yönlendirme katmanı trafiğin belirli kısmını canary sürümüne gönderir.

1. Aday sürüm hazırlanır: Build, test, güvenlik ve deployment kontrolleri tamamlanır.
2. Canary grubu seçilir: Trafiğin veya uygun kullanıcıların küçük bölümü yeni sürüme yönlendirilir.
3. Gözlem penceresi açılır: Teknik sağlık, kullanıcı etkisi ve kritik iş metrikleri izlenir.
4. Kararlı sürümle karşılaştırılır: Aynı zaman aralığındaki iki sürümün sonuçları değerlendirilir.
5. Promote, pause veya rollback kararı verilir: Kapsam artırılır, bekletilir ya da trafik geri alınır.
6. Tam yayın tamamlanır: Yeterli kanıt oluştuğunda bütün uygun trafik yeni sürüme aktarılır.

AWS CodeDeploy; canary, linear ve all-at-once trafik geçişlerini ayrı deployment yapılandırmaları olarak sunar. Canary modelinde önce sabit bir trafik yüzdesi yeni sürüme geçirilir, belirlenen bekleme süresinin ardından kalan trafik aktarılır AWS CodeDeploy Deployment Configurations.

Canary grubu nasıl seçilir?

Canary grubu yalnızca rastgele seçilmiş küçük bir yüzde değildir. Seçim, yeni sürümün riskini gösterecek kadar temsil edici; olası arızanın etkisini sınırlayacak kadar dar olmalıdır. İlk aşamada şirket içi kullanıcılar veya gönüllü pilot hesaplar tercih edilebilir. Daha sonra gerçek trafikten tutarlı kullanıcı grupları seçilebilir.

• Şirket içi kullanıcılar ve test hesapları
• Özelliği önceden kabul etmiş pilot müşteriler
• Kullanıcı veya tenant kimliğine göre kararlı yüzde grubu
• Belirli istemci sürümü ya da cihaz tipi
• Teknik gerekçesi varsa belirli bölge veya trafik kaynağı

Aynı kullanıcı bir istekte canary, sonraki istekte kararlı sürüme düşerse oturum, cache ve deneyim tutarsızlaşabilir. Bu nedenle kullanıcı veya tenant kimliği kararlı bir hashing yöntemiyle bucket'a atanmalıdır. Kimlik bulunmayan trafikte anonim oturum anahtarı kullanılabilir; ancak gizlilik tercihleri gözetilmelidir.

Canary yüzdesi ve bake time nasıl belirlenir?

Bütün projeler için geçerli tek bir ideal yüzde yoktur. Trafiği düşük bir uygulamada yüzde 1 anlamlı veri üretmeyebilir; çok yüksek trafikli sistemde aynı oran binlerce kullanıcıyı etkileyebilir. Aşama büyüklüğü toplam trafik, işlemin kritikliği, gözlem süresi ve geri dönüş kapasitesine göre seçilmelidir.

AWS, canary yapılandırmalarında sabit yüzde ile bake time kullanır. Bake time, yeni sürümün belirli trafik altında ölçüm toplanması için bekletildiği süredir Amazon ECS Canary Deployments. Süre yalnız teknik metric'lerin değil, gecikmeli iş akışlarının da sonuçlanmasına yetecek kadar uzun olmalıdır.

Hangi metrikler izlenmelidir?

Canary kararını yalnız CPU veya uptime ile vermek yetersizdir. Yeni sürüm teknik olarak ayakta dururken ödeme, form gönderimi veya sipariş tamamlama oranı bozulabilir. Guardrail metric'ler, yayının ilerlemesine izin veren sınırları ve yayını durduracak koşulları tanımlar.

Canary ve kararlı sürüm aynı trafik koşullarında karşılaştırılmalıdır. Sabah düşük trafikteki yeni sürüm ile akşam yoğunluğundaki eski sürümü karşılaştırmak yanıltıcıdır. Sürüm, endpoint, istemci ve uygun iş boyutları telemetride ayrı etiketlerle izlenmelidir.

Microsoft Azure Well-Architected Framework, progressive exposure modelinde değişikliğin küçük gruplarda başlayıp sağlık sinyallerine göre daha geniş gruplara ilerletilmesini önerir Azure Safe Deployment Practices.

Başarı ve durdurma kriterleri nasıl yazılır?

“Dashboard'a bakıp karar veririz” yaklaşımı yeterli değildir. Yayın başlamadan önce hangi koşulda ilerleme, bekleme ve rollback yapılacağı yazılmalıdır. Eşikler geçmiş normal davranış, hizmet hedefleri ve işlemin kritikliği üzerinden belirlenmeli; kaynaksız evrensel oranlar kullanılmamalıdır.

• Canary hata oranı kararlı sürümden anlamlı biçimde kötüleşirse rollout durdurulur.
• Kritik işlem başarısı kabul edilen alt sınırın altına düşerse trafik geri alınır.
• Yüksek yüzdelik gecikme toleransı aşarsa kapsam artırılmaz.
• Veri bütünlüğü veya güvenlik hatasında beklemeden rollback uygulanır.
• Yeterli trafik ve süre oluşmadıysa başarılı kabul edilmez.
• Telemetri eksik veya yanlış etiketleniyorsa rollout durdurulur.

Canary release ile A/B testi aynı şey mi?

Hayır. Canary release'in amacı yeni yazılım sürümünün güvenilirliğini sınırlı maruziyetle doğrulamaktır. A/B testi ise ürün veya arayüz varyantlarının kullanıcı davranışına etkisini hipotez ve istatistiksel yöntemle karşılaştırır. İki yaklaşım trafik bölme kullanabilir; fakat karar hedefleri farklıdır.

Canary'de temel soru “yeni sürüm eski sürüm kadar güvenilir ve hızlı mı?” olur. A/B testinde ise “hangi varyant belirlenen ürün metriğinde daha iyi sonuç veriyor?” araştırılır. Teknik guardrail'ler geçilmeden ürün deneyi sonuçları yorumlanmamalıdır.

Canary release ile blue-green deployment farkı nedir?

Blue-green deployment iki ayrı production ortamı hazırlar ve trafik eski ortamdan yeni ortama kontrollü biçimde taşınır. Canary release ise yeni sürüme maruz kalan kullanıcı veya trafik oranını aşamalar hâlinde büyütür. İki strateji birlikte kullanılabilir.

AWS, canary'yi daha riskten kaçınan aşamalı bir blue-green yaklaşımı olarak tanımlar AWS Canary Deployments.

Kubernetes'te canary release nasıl uygulanır?

Kubernetes eski ve yeni uygulama sürümlerini farklı Deployment veya ReplicaSet gruplarında yan yana çalıştırabilir. Service selector, ingress controller, service mesh veya progressive delivery aracı trafiği sürümler arasında dağıtabilir. Kubernetes dokümantasyonu, farklı release veya konfigürasyonları ayırmak için birden fazla label kullanılabileceğini ve canary deployment'ın ayrı Deployment'lar üzerinden uygulanabileceğini belirtir Kubernetes Deployments.

Yalnız replica sayısını değiştirmek her durumda hassas trafik yüzdesi sağlamaz. Pod kapasitesi, bağlantı süreleri ve load balancing davranışı gerçek dağılımı etkileyebilir. Header, kullanıcı veya tenant bazlı yönlendirme için ingress ya da service mesh düzeyinde daha ayrıntılı kurallar gerekebilir.

Türkiye'de resmî bir teknoloji kaynağı olan TÜBİTAK BİLGEM Yazılım Teknolojileri Araştırma Enstitüsü blogu; Canary, Blue-Green, A/B, Shadow ve Progressive Delivery yaklaşımlarını Kubernetes dağıtım stratejileri arasında sınıflandırır. Kaynak, gelişmiş stratejilerin çoğunlukla ek konfigürasyon veya bileşen gerektirdiğini de belirtir TÜBİTAK BİLGEM YTE Kubernetes Dağıtım Stratejileri.

Rollback nasıl yapılmalıdır?

Canary rollback, yeni sürüme giden trafiği durdurup kullanıcıları kararlı sürüme döndürür. Ancak yeni sürüm veritabanına eski sürümün okuyamayacağı veri yazdıysa, kuyruk mesajı biçimini değiştirdiyse veya geri döndürülemez dış işlem başlattıysa yalnız trafik anahtarı yeterli olmaz.

1. Canary'ye yeni trafik gönderimini durdurun.
2. Devam eden istek ve uzun bağlantılar için draining uygulayın.
3. Background worker ve queue consumer'ların hangi sürümde çalışacağını netleştirin.
4. Yeni sürümün oluşturduğu verinin kararlı sürümle uyumunu kontrol edin.
5. Gerekirse feature flag veya kill switch ile riskli davranışı kapatın.
6. Kararlı sürüm metriklerinin normale döndüğünü doğrulayın.

Güncel Amazon ECS dokümantasyonu, otomatik tetikleyicilerin yakalayamadığı sorunlar için açık manuel rollback prosedürleri önerir Amazon ECS Canary Deployments.

Veritabanı ve veri uyumluluğu nasıl korunur?

Canary süresince eski ve yeni uygulama sürümü aynı anda çalışır. Ortak veritabanına erişiyorlarsa şema ve veri biçimi iki sürümle uyumlu olmalıdır. Yeni sürüm bir alanı zorunlu hâle getirirken eski sürüm bu alanı yazmıyorsa canary testi sırasında veri tutarsızlığı oluşabilir.

• Şema değişikliklerini genişletme, geçiş ve temizlik aşamalarına ayırın.
• Yeni alanları geçici olarak eski sürümle uyumlu tutun.
• Mesaj, cache ve API sözleşmelerini backward compatible geliştirin.
• Yeni yazma davranışını gerekirse ayrı flag ile kontrollü açın.
• Rollback penceresi kapanmadan eski alanları silmeyin.

Bu gereksinimler canary release'i yalnız altyapı ekibinin görevi olmaktan çıkarır. Uygulama, veri ve entegrasyon sözleşmeleri birlikte ele alınmalıdır. Çok sayıda servis içeren yazılım geliştirme projelerinde release tasarımı kodlama aşamasından önce planlanmalıdır.

Canary release hangi durumlarda yanıltıcı olabilir?

• Canary grubu gerçek kullanıcı dağılımını temsil etmiyorsa sonuç eksik kalır.
• Gözlem süresi iş akışının tamamlanma süresinden kısaysa geç hatalar görülmez.
• Düşük trafik istatistiksel gürültüyü artırır.
• Kararlı ve canary sürüm farklı kapasitede çalışıyorsa kıyaslama bozulur.
• Metric etiketleri yanlışsa iki sürümün sonuçları birbirine karışır.
• Canary yalnız HTTP trafiğini kapsayıp background işlerini dışarıda bırakabilir.

Canary “küçük yüzdeye aç ve bekle” biçiminde uygulanmamalıdır. Temsil gücü, gözlem süresi ve karşılaştırma yöntemi tasarımın parçasıdır.

Türkiye ve Samsun bağlamında canary release

Canary release için Samsun'a özgü ayrı bir teknik standart bulunmaz; yöntem uygulamanın altyapısı, risk profili ve kullanıcı dağılımına göre planlanır. Türkiye ölçeğinde kullanılabilecek yerel teknik referanslardan biri TÜBİTAK BİLGEM YTE'nin Kubernetes dağıtım stratejileri içeriğidir. Uluslararası uygulama ayrıntılarında Kubernetes, AWS ve Microsoft'un resmî dokümantasyonu temel kaynak olarak kullanılabilir.

Webioo'nun resmî sitesinde şirketin Samsun merkezli olduğu ve Türkiye genelinde web tasarım, e-ticaret, özel yazılım, SEO, mobil uygulama ve reklam yönetimi alanlarında hizmet verdiği belirtilir Webioo Resmî Sitesi. Bu bilgi, Webioo'nun canary release kullandığına veya belirli bir müşteri projesinde uyguladığına kanıt değildir. Bu nedenle içerikte böyle bir proje, başarı oranı veya birinci elden deneyim iddiası kullanılmamıştır.

Samsun'daki veya Türkiye'nin başka bir ilindeki ekipler için temel karar değişmez: trafik yönlendirme, telemetri, geri dönüş ve veri uyumluluğu yoksa yalnız “canary” adını kullanmak güvenli yayın sağlamaz. Yerel destek teknik kanıtın yerine geçmez; mimari ve operasyon süreçleri ayrıca doğrulanmalıdır.

Canary release kontrol listesi

1. Canary'nin hangi riski azaltacağını ve hangi kullanıcı akışını kapsayacağını yazın.
2. Kararlı ve yeni sürüm için ayrı deployment ve sürüm etiketleri oluşturun.
3. Kullanıcıların tutarlı gruplara atanmasını sağlayın.
4. Hata, gecikme, kapasite, iş sonucu ve veri bütünlüğü metriklerini seçin.
5. Promote, pause ve rollback kriterlerini yayın başlamadan belirleyin.
6. Yeterli trafik ve bake time oluşmadan başarılı karar vermeyin.
7. Veritabanı, API, queue ve cache biçimlerini iki sürümle uyumlu tutun.
8. Background job ve consumer trafiğini ayrıca planlayın.
9. Otomatik alarmların yanında manuel rollback prosedürü hazırlayın.
10. Canary tamamen yayıldığında eski sürümü kontrollü biçimde kaldırın.

İzleme, bakım ve rollback kontrolleri canlı sistem bakım sürecinin kalıcı parçası olmalıdır. API ve servis trafiğinin güvenli yönlendirilmesi ise API entegrasyonu tasarımında dikkate alınmalıdır.

Sonuç: Yeni sürümü bir anda değil, kanıt oluşturarak yayınlayın

Canary release, yeni sürümü önce küçük bir production grubuna açarak teknik ve iş etkisini gerçek trafik altında ölçer. Guardrail metrikleri kabul edilebilir kaldıkça rollout genişletilir; hata, gecikme veya veri riski görülürse sürüm durdurulur ya da geri alınır. Bu yaklaşım bütün riski ortadan kaldırmaz, fakat hata etkisini sınırlı tutarak karar için daha erken kanıt üretir.

Başarılı süreç; temsil edici kullanıcı seçimi, kararlı trafik dağıtımı, yeterli gözlem süresi, sürümler arası karşılaştırılabilir telemetri ve test edilmiş rollback yoluna dayanır. Sadece küçük yüzdeyle trafik göndermek canary release değildir. Güvenli yayın, her aşamanın ilerleme ve durdurma koşullarının önceden tanımlandığı kontrollü progressive delivery sürecidir.