Blue-Green Deployment Nedir? Kesintisiz Yayın Nasıl Yapılır?

Yeni bir sürümü çalışan sunucuların üzerine doğrudan kurmak, deployment sırasında eski ve yeni kodun aynı kaynaklarda birbirine karışmasına neden olabilir. Güncelleme başarısız olduğunda ekip çoğu zaman önceki paketi yeniden dağıtmak, servisleri yeniden başlatmak ve veritabanı uyumluluğunu elle kontrol etmek zorunda kalır. Bu süreç uzadıkça kullanıcı hataları ve operasyon baskısı artar.

Blue-green deployment, mevcut sürüm ile yeni sürümü birbirinden ayrılmış iki production ortamında paralel çalıştırır. Trafik önce kararlı ortamda kalır; yeni ortam hazırlanır, test edilir ve kabul kriterlerini geçtiğinde yönlendirme yeni sürüme çevrilir. Sorun görülürse trafik önceki ortama geri alınabilir. Yöntemin gücü yalnızca iki ortam kurmakta değil, trafik geçişi ve geri dönüş kararını önceden otomatikleştirilebilir hâle getirmektedir.

Blue-green deployment nedir?

Blue-green deployment, aynı production yükünü çalıştırabilecek iki ayrı ortam üzerinden uygulama sürümü yayınlama stratejisidir. Genellikle blue mevcut ve kullanıcı trafiğini taşıyan ortamı, green ise yeni sürümün hazırlandığı ortamı temsil eder. Green ortam doğrulandıktan sonra load balancer, reverse proxy, servis yönlendirmesi veya benzeri trafik katmanı kullanıcıları yeni ortama gönderir.

AWS, yöntemi iki özdeş production ortamı arasında trafik değiştirerek kesinti ve yayın riskini azaltan bir release yaklaşımı olarak açıklar Amazon ECS Blue/Green Deployments. Microsoft da blue ve green ortamların aynı üretim yükünü taşıyabilmesini, yeni sürümün pasif ortamda doğrulanmasını ve ardından canlı trafiğin yönlendirilmesini temel model olarak tanımlar Azure Container Apps Blue-Green Deployment.

Blue ve green ortamları nasıl çalışır?

İsimlerin kalıcı bir anlamı yoktur. İlk deployment döngüsünde blue canlı, green aday ortam olabilir. Trafik green’e geçtikten sonra bir sonraki sürüm blue ortamına kurulabilir. Böylece ortamlar her yayın döngüsünde rol değiştirir. Önemli olan renk değil, hangi ortamın mevcut production ve hangisinin yeni aday sürüm olduğunun kesin biçimde bilinmesidir.

1. Canlı ortam belirlenir: Mevcut kararlı sürüm production trafiğini taşır.
2. Pasif ortam hazırlanır: Altyapı, konfigürasyon ve yeni uygulama paketi ikinci ortama dağıtılır.
3. Teknik doğrulama yapılır: Health check, smoke test, bağımlılık ve veri uyumluluğu kontrol edilir.
4. Test trafiği gönderilir: Mümkünse yalnızca iç ekip veya özel test route’u green ortama yönlendirilir.
5. Trafik anahtarı değiştirilir: Kullanıcı istekleri yeni ortama aktarılır.
6. Gözlem süresi başlar: Hata, gecikme ve kritik iş metrikleri yakından izlenir.
7. Eski ortam korunur: Rollback penceresi kapanana kadar blue ortam çalışır durumda tutulur.
8. Yeni döngüye hazırlanılır: Green kararlı production olduktan sonra blue sonraki aday ortam olur.

Bu modelin başarılı olması için iki ortamın yalnız görünüşte değil, kapasite, ağ, güvenlik, çevresel konfigürasyon ve bağımlılıklar bakımından karşılaştırılabilir olması gerekir. Green ortam yalnız küçük bir test sunucusuysa canlı trafik geldiğinde üretimde görülmeyen kapasite sorunları ortaya çıkabilir.

Blue-green deployment neden kullanılır?

Yöntem, çalışan ortamın üzerine değişiklik uygulamak yerine yeni sürümü ayrı bir yerde doğrulama fırsatı verir. Bu ayrım deployment hatasının doğrudan bütün kullanıcıları etkilemesini önlemeye yardımcı olur. Aynı zamanda önceki sürüm bozulmadan tutulduğu için geri dönüş, eski paketi yeniden kurmaktan daha hızlı olabilir.

• Yeni sürüm production’a benzer kaynaklar üzerinde test edilebilir.
• Trafik geçişi tek ve kontrollü bir operasyon noktasına dönüştürülebilir.
• Önceki sürüm rollback için hazır durumda korunabilir.
• Deployment sırasında çalışan uygulamanın dosyaları ve süreçleri değiştirilmez.
• Altyapı, runtime veya temel konfigürasyon değişiklikleri izole ortamda doğrulanabilir.
• Başarısız aday sürüm kullanıcı trafiği almadan incelenebilir.
• Yayın penceresi ile uygulama paketinin hazırlanma zamanı birbirinden ayrılabilir.

AWS blue-green yaklaşımının yeni sürümün production trafiği yönlendirilmeden önce test edilmesine ve gerektiğinde hızlı geri dönüşe imkân verdiğini belirtir AWS Blue/Green Deployments Whitepaper. Ancak bu avantajlar otomatik değildir; veri, oturum ve background işlerinin iki ortam arasında nasıl yönetileceği ayrıca tasarlanmalıdır.

Blue-green deployment gerçekten sıfır kesinti sağlar mı?

Blue-green deployment çoğu uygulamada kesintiyi çok düşük seviyeye indirebilir; fakat “zero downtime” koşulsuz garanti değildir. Trafik anahtarı hızlı olsa bile devam eden HTTP istekleri, WebSocket bağlantıları, upload işlemleri, background job’lar veya istemci DNS cache’i kullanıcıların bir bölümünü kısa süreyle eski ortamda tutabilir. Yeni ortam yeterli kapasiteye ulaşmadan trafik açılırsa hata oranı artabilir.

Kesintisiz yayın, yalnızca iki ortamın mevcut olması değil; yeni ortamın hazır olduğunun kanıtlanması, devam eden işlemlerin güvenli tamamlanması ve rollback kararının veri kaybı üretmeden uygulanabilmesidir.

Kesinti hedefi uygulamanın yapısına göre tanımlanmalıdır. Salt okunur web içeriğinde trafik değişimi oldukça hızlı olabilir. Ödeme, dosya işleme, canlı bağlantı veya uzun süren işlemlerin bulunduğu sistemlerde connection draining, graceful shutdown, idempotency ve iş kuyruğu koordinasyonu gerekir.

Trafik blue ortamdan green ortama nasıl aktarılır?

Trafik geçişi load balancer, reverse proxy, API gateway, service mesh, container platform revision’ı veya DNS üzerinden yapılabilir. Uygulama seviyesine yakın yönlendirme genellikle DNS değişikliğinden daha hızlı ve kontrol edilebilirdir; çünkü DNS TTL ve istemci önbelleği nedeniyle bütün kullanıcılar aynı anda yeni hedefe geçmeyebilir.

Azure Architecture Center, iki ortamın tam production yükünü taşıyabilmesini ve trafik değişiminin güvenilir yönlendirme mekanizmasıyla yapılmasını önerir Azure Safe Deployment Practices. Yönlendirmenin kendisi deployment pipeline içinde otomatikleştirilebilir; ancak manuel acil geri dönüş yolu da erişilebilir tutulmalıdır.

Green ortam yayına hazır olmadan önce neler test edilmelidir?

Health endpoint’in HTTP 200 döndürmesi tek başına hazır olma kanıtı değildir. Uygulama çalışıyor görünürken veritabanı bağlantısı, queue consumer, dosya depolama veya dış servis kimlik bilgileri hatalı olabilir. Green ortamın kabul kriterleri uygulamanın kritik yolculuklarını kapsamalıdır.

• Uygulama ve bağımlılık health check’leri başarılı mı?
• Migration işlemleri tamamlandı mı ve eski sürümle uyumlu mu?
• Giriş, form, ödeme, sipariş veya raporlama gibi kritik akışlar çalışıyor mu?
• Green ortam production kapasitesini taşıyabilecek instance veya pod sayısına ulaştı mı?
• Cache ve connection pool’lar yeterince ısındı mı?
• Log, metric ve trace verileri doğru ortam ve sürüm etiketiyle geliyor mu?
• Secret, sertifika ve çevresel konfigürasyonlar production değerleriyle uyumlu mu?
• Background job ve scheduler’ların iki ortamda aynı işi iki kez çalıştırması önlendi mi?
• Rollback sonrasında eski sürümün yeni veriyi okuyabildiği doğrulandı mı?

Teknik smoke test’lerin yanında mümkünse production’a zarar vermeyen sentetik işlemler çalıştırılmalıdır. Yeni ortam gerçek kullanıcı verisine bağlıysa test hesapları, test siparişleri veya işaretlenmiş sentetik trafik kullanılabilir. Kontrol süreci yazılım geliştirme pipeline’ının tekrarlanabilir bir aşaması olmalıdır.

Veritabanı değişiklikleri neden en büyük risktir?

Uygulama ortamları ikiye ayrılabilir; ancak çoğu sistem blue ve green sürümlerinin eriştiği ortak bir veritabanı kullanır. Green sürüm bir kolonu yeniden adlandırır veya eski sürümün beklediği alanı kaldırırsa blue ortam rollback için hazır görünse bile artık çalışmayabilir. Bu durumda trafik geri çevrildiğinde uygulama hata üretir.

AWS, blue-green yayınlarda veritabanı güncellemelerinin eski uygulama sürümüyle backward compatible olması gerektiğini; alternatif olarak yeni kodun eski şemayla çalışacak biçimde hazırlanmasını önerir AWS Data Synchronization and Schema Changes. Bu nedenle kırıcı şema değişiklikleri tek deployment içinde yapılmamalıdır.

Pratikte yeni kolon veya tablo önce eklenir, yeni sürüm eski ve yeni alanlarla uyumlu dağıtılır, veri gerekiyorsa kontrollü olarak doldurulur ve bütün trafik yeni sürüme geçtikten sonra eski alan daha sonraki bir release’te kaldırılır. AWS RDS dokümantasyonu da yeniden adlandırma gibi bazı şema değişikliklerinin replikasyonu bozabileceğini ve yalnız uyumlu değişikliklerin yapılmasını önerir Amazon RDS Blue/Green Best Practices.

Session, cache ve dosya durumu nasıl yönetilmelidir?

Kullanıcı oturumu uygulama sunucusunun yerel belleğinde tutuluyorsa trafik green ortama geçtiğinde kullanıcı çıkış yapmış görünebilir. Benzer biçimde local disk’e yazılan dosyalar, geçici export çıktıları veya uygulama içi cache yeni ortamda bulunmayabilir. Blue-green mimaride çalışma zamanı durumunun mümkün olduğunca ortam dışındaki paylaşımlı ve dayanıklı sistemlerde tutulması gerekir.

• Session verisini paylaşımlı ve yüksek erişilebilir store içinde yönetin.
• Dosyaları instance local disk yerine ortak object storage veya dayanıklı dosya sisteminde tutun.
• Cache anahtarlarında sürüm uyumluluğunu ve eski veri formatını hesaba katın.
• Yeni sürümün cache’i ısıtması için kontrollü test veya warm-up trafiği kullanın.
• Uzun bağlantılar için connection draining ve yeniden bağlanma davranışını test edin.
• İki ortamın aynı queue mesajını eş zamanlı tüketmesini bilinçli olarak yönetin.

Sticky session kullanmak kısa vadede oturum geçişini kolaylaştırabilir; fakat kullanıcıları eski ortama bağlamaya devam ederek tam switch süresini uzatabilir. Kalıcı çözüm, stateless uygulama yaklaşımı ve paylaşımlı session yönetimidir.

Background job ve scheduler’lar çift çalışmayı nasıl önler?

Blue ve green ortamlar aynı anda aktif olduğunda zamanlanmış görevler iki kez başlayabilir. İki ortamın da fatura oluşturması, e-posta göndermesi veya stok senkronizasyonu yapması çift işleme neden olur. Trafik yalnız HTTP isteklerini etkiler; scheduler ve queue consumer gibi süreçler load balancer yönlendirmesinden bağımsız çalışabilir.

Bu nedenle pasif ortamda job worker’lar kapalı tutulabilir, leader election veya distributed lock kullanılabilir ya da consumer group tasarımıyla mesajın tek kez işlenmesi hedeflenebilir. Ödeme ve entegrasyon işlemlerinde idempotency uygulanması, yeniden deneme veya çift tetiklenme hâlinde aynı iş sonucunun ikinci kez üretilmesini önlemeye yardımcı olur.

Yayın sırasında hangi süreçlerin trafik geçişiyle, hangilerinin ayrı activation adımıyla yönetileceği runbook içinde açıkça belirtilmelidir. Bu ayrım özellikle yoğun entegrasyon barındıran özel yazılım projelerinde önemlidir.

Rollback nasıl planlanmalıdır?

Rollback, sorun görüldüğünde yalnızca load balancer hedefini blue ortama çevirmek değildir. Eski sürümün veritabanı, queue mesajı, cache formatı ve kullanıcı tarafından yeni sürümde oluşturulan verilerle çalışabilmesi gerekir. Green ortam kullanıcı trafiği aldıktan sonra geri dönüş kararı geciktikçe iki sürüm arasındaki veri farkı büyüyebilir.

1. Rollback tetikleyicilerini önceden tanımlayın: hata oranı, gecikme, işlem başarısı veya kritik alarm.
2. Trafik yönünü geri çeviren komutu pipeline ve manuel acil yöntem olarak hazır tutun.
3. Connection draining süresini ve aktif işlemlerin nasıl tamamlanacağını belirleyin.
4. Green ortamda yazılan verinin blue sürümle okunabilir olduğunu doğrulayın.
5. Background job ve consumer rollerini eski ortama güvenli biçimde geri aktarın.
6. Rollback sonrasında gözlem süresini ve kullanıcı iletişimi gereksinimini tanımlayın.
7. Başarısız green ortamı hemen silmeyin; kök neden analizi için erişimi kontrollü biçimde koruyun.

Eski ortamın tutulacağı rollback penceresi sabit bir sayı olmamalıdır. Trafik hacmi, kritik işlemlerin tamamlanma süresi, veri değişiminin geri döndürülebilirliği ve maliyet birlikte değerlendirilmelidir.

Blue-green ile rolling ve canary deployment farkı nedir?

Blue-green deployment iki tam ortam arasında sürüm değiştirir. Rolling deployment, çalışan instance’ları gruplar hâlinde yeni sürümle değiştirir; süreç boyunca eski ve yeni sürüm aynı servis havuzunda bulunabilir. Canary yaklaşımı ise yeni sürümü önce küçük bir gerçek kullanıcı grubuna açarak riski kademeli biçimde ölçer.

Blue-green ve canary birlikte de kullanılabilir. Green ortam hazırlandıktan sonra trafiğin küçük bölümü yeni sürüme gönderilebilir; metrikler kabul edilirse tam switch yapılabilir. Ancak sonraki içerikte ele alınacak canary modelinin ana amacı progressive exposure iken blue-green’in temel amacı iki izole production ortamı arasında güvenli geçiştir.

Blue-green deployment maliyeti neden yükselebilir?

Green ortamın gerçek production yükünü taşıyabilmesi için uygulama sunucuları, ağ bileşenleri ve bazı durumlarda veri katmanları iki kez hazırlanır. Bu kaynaklar yalnız yayın penceresinde çalıştırılsa bile ek maliyet oluşturur. Stateful servislerin çoğaltılması ve veri senkronizasyonu daha da pahalı olabilir.

Altyapıyı kod olarak tanımlamak, green ortamı gerektiğinde üretip daha sonra kapatmak maliyeti azaltabilir. Fakat green ortamın her deployment’ta sıfırdan kurulması uzun provisioning süresi ve çevresel fark riski yaratır. Kalıcı iki ortam ile geçici ortam arasında sistemin yayın sıklığı, kurulum süresi ve kritikliği üzerinden karar verilmelidir.

Azure Well-Architected Framework, iki havuzun tam üretim yükünü taşıyabilmesinin blue-green modelinin temel maliyetlerinden biri olduğunu vurgular Azure Safe Deployment Practices. Düşük trafikli basit bir uygulamada rolling deployment daha ekonomik olabilir.

Blue-green deployment hangi projeler için uygundur?

• Kesinti maliyetinin yüksek olduğu müşteri veya operasyon uygulamaları
• Deployment sıklığı yüksek ve geri dönüş süresi kritik olan sistemler
• Production benzeri ortamın otomatik kurulabildiği container veya bulut altyapıları
• Uygulama süreçlerinin büyük ölçüde stateless tasarlandığı projeler
• Veritabanı değişikliklerinin backward compatible yapılabildiği sistemler
• Sağlık, performans ve iş metriklerinin yayın kapısı olarak kullanılabildiği ekipler

Tek sunuculu, local disk’e bağımlı ve manuel yönetilen küçük bir web sitesinde iki tam ortam kurmak gereksiz karmaşıklık yaratabilir. Önce otomatik deployment, yedekleme, health check ve rollback disiplini kurulmalıdır. Blue-green modeli, temel operasyon süreçlerinin yerine geçen değil, onların üzerine kurulan bir yayın stratejisidir.

Blue-green deployment kontrol listesi

1. Blue ve green ortamların altyapı, kapasite ve güvenlik bakımından eşdeğer olduğunu doğrulayın.
2. Ortam konfigürasyonunu kod ve sürüm kontrolüyle yönetin.
3. Health check dışında kritik kullanıcı akışları için smoke test hazırlayın.
4. Veritabanı şema değişikliklerini iki sürümle backward compatible tasarlayın.
5. Session, cache, dosya ve queue durumunu ortam dışı dayanıklı sistemlerde yönetin.
6. Scheduler ve background worker’ların çift çalışmasını engelleyin.
7. Trafik switch, connection draining ve rollback komutlarını otomatikleştirin.
8. Hata, gecikme ve iş metrikleri için yayın kabul eşikleri belirleyin.
9. Rollback penceresi kapanmadan eski ortamı ve uyumlu kod yolunu kaldırmayın.
10. Her deployment sonrasında runbook ve başarısızlık senaryolarını güncelleyin.

Yayın mekanizmasının yalnız normal senaryoda değil, load balancer hatası, eksik migration, kapasite yetersizliği ve telemetry kesintisi gibi durumlarda da test edilmesi gerekir. Bu testler web sitesi bakım ve canlı sistem operasyonunun düzenli parçası olmalıdır.

Sonuç: İki ortam değil, kontrollü geçiş sistemi kurun

Blue-green deployment, mevcut ve yeni sürümü iki ayrı production ortamında çalıştırarak deployment riskini izole eder. Green ortam doğrulanır, trafik kontrollü biçimde yeni sürüme aktarılır ve sorun görülürse blue ortama geri dönülür. Bu yaklaşım çalışan sunucuların üzerine doğrudan güncelleme yapmaya kıyasla daha hızlı ve öngörülebilir rollback sağlayabilir.

Gerçek güvenlik; ortamların eşdeğerliğinden, kapsamlı health ve smoke test’lerden, backward compatible veritabanı değişikliklerinden, paylaşımlı durum yönetiminden ve ölçülebilir yayın kapılarından gelir. Trafiği değiştirmek kolay olabilir; veriyi ve devam eden işleri güvenle geri çevirmek asıl mühendislik problemidir. Bu nedenle blue-green deployment bir sunucu çoğaltma işlemi değil, uygulama, veri ve operasyon katmanlarını birlikte yöneten yayın mimarisidir.