Kodu üretime güvenle göndermek: Canary, GitOps, geri alma yerine ileri sarma ve özellik bayrakları

Robert Erez, dağıtım aracı Octopus Deploy’da baş mühendis (principal engineer). 2010’ların başında sunucu Gergely Orosz’la Skype’ın web ekibinde çalışmışlar. Sohbetin kariyer ve sponsor kısımlarını atlayıp doğrudan “nasıl güvenle yayın yapılır” sorusuna odaklanıyoruz.

Sürekli teslim ile sürekli dağıtım aynı şey değil

Erez olgunluğu basamaklarla anlatıyor. En altta “YOLO” var: Sunucuya SSH ile bağlanıp elle güncellemek. Sonra sürekli entegrasyon (CI) geliyor: Herkes kodunu sık sık tek bir dala birleştiriyor, testler her seferinde çalışıyor. Sürekli teslim (continuous delivery) bir adım ileri: Her an “yayınla” düğmesine basabileceğin bir durumdasın, çünkü sadece kodu değil dağıtım sürecinin kendisini de sürekli deniyorsun. Sürekli dağıtım (continuous deployment) ise her değişikliğin kimse dokunmadan üretime çıkması.

Erez’e göre herkesin son basamağa çıkması gerekmiyor. Denetimli sektörlerde onay kurulları hâlâ var. Asıl kazanç teslimde: Riski en sona bırakmıyorsun. Skype’ta da haftalık bir değişiklik onay kurulu vardı. Ekip yine de her derlemeyi önce Yeni Zelanda’ya açıyordu. Yeni güne ilk giren büyük, İngilizce konuşan ülke orasıydı. Erez’e göre ülke, bir hatanın çabucak düzeltilebileceği kadar da küçüktü.

Canary ve blue/green

Bu Yeni Zelanda hilesi bir canary yayını. Adını madenlerde zehirli gazı ilk fark eden kanarya kuşundan alıyor. Yeni sürüm eskisinin yanında çalışıyor, trafiğin küçük bir yüzdesi ona gidiyor, sorun yoksa pay artıyor. Bunun için iyi bir gözlemlenebilirlik şart: Hata oranını görmeden payı artırıp artırmayacağına karar veremezsin. Argo Rollouts gibi araçlar bu kararı Prometheus ya da Datadog metriklerine bakarak otomatik verebiliyor.

Blue/green dağıtımda ise iki özdeş ortam var. Yeni sürümü boştaki ortamda deniyorsun, hazır olunca trafiğin tamamını oraya çeviriyorsun. Sorun çıkarsa yönlendiriciyi eski ortama geri çevirmen yetiyor.

GitOps aslında Git demek değil

GitOps, sistemin olması gereken hâlini (desired state) bir yerde tanımlayıp bir yazılım ajanının bunu sürekli uygulaması demek. Argo CD ve Flux bunu Kubernetes için yapıyor: Git’teki tanımı çekiyor, kümede sapma olursa düzeltiyor. OpenGitOps’un dört ilkesi şunlar: tanımsal (declarative), sürümlü ve değiştirilemez, otomatik çekilen, sürekli uzlaştırılan. Erez’in dikkat çektiği nokta, hiçbir ilkenin Git kelimesini içermemesi.

Erez’e göre “her şey Git’te olmalı” mutlakçılığı sorun yaratıyor. Gizli anahtarlar Git’e konmamalı. Duman testi, bildirim ya da veritabanı güncellemesi gibi adımlar da tanımsal modele pek uymuyor. Binlerce mağaza kasasında küçük Kubernetes kümeleri çalıştıran bir müşterisinde ise Git deposunun kendisi darboğaz olmuş.

Geri alma değil, ileri sarma

Müşteriler sık sık bir “geri al” düğmesi istiyor. Durumsuz (stateless) bir uygulamada bu kolay: Commit’i geri alıp yeniden dağıtırsın. Ama Erez’in sorusu şu: Bu sürümde veritabanı şeması değiştiyse ne yapacaksın? Eski kod yeni şemayla konuşamayabilir. Yedeğe dönmek de arada yazılan veriyi kaybetmek demek. O yüzden Erez’in tavsiyesi ileri sarma (roll forward): Sürüm 2’de hata varsa sürüm 1’e değil, düzeltmeyi içeren sürüm 3’e git. Octopus’un belgeleri de şema değişikliğinde aynısını öneriyor. Şemayı güvenle değiştirmenin yolu genişlet ve daralt (expand and contract): Önce yeni yapıyı eskisinin yanına ekle, kodu taşı, eskiyi en son kaldır.

Dağıtımı yayından ayır

Erez’in en sevdiği araç özellik bayrağı (feature flag). Bayrak, koddaki bir yolu dışarıdan açıp kapatmanı sağlıyor. Canary’de değişiklik birimi bütün uygulama: Son yayından beri 20 commit varsa 20’sini birden deniyorsun. Bayrakta birim tek bir özellik. Hedeflemesi daha ince, kapatması saniyeler sürüyor. Kodu pazartesi dağıtıp özelliği salı, loglar önündeyken açabiliyorsun. Erez’e göre yapay zekâ daha çok kod ürettikçe hattın hızından çok riski düşürmek önem kazanacak, bayraklar da öne çıkacak. Bu, Charity Majors’ın okumadığın kodu üretime gönderme sorusuna verdiği cevaplarla da örtüşüyor.

Bedeli ise bayrak çöplüğü. Octopus bayrakları satıcıdan bağımsız OpenFeature arayüzüyle kullanıyor. Her bayrağa sahibi olan ekibi ve bir son kullanma tarihi yazıyor. Tarih geçince CI o ekibe haber veriyor. Kaldırırken önce koddan siliyorsun, ayarı ancak o kod üretime ulaştıktan sonra temizliyorsun. Başlamak için Erez’in önerisi basit: Tek bir bayrakla başla. Gece 2’de bir hatayı tek tıkla kapatabilmenin rahatlığını bir kez yaşayınca gerisi gelir.

Düşün

• Son yayınında bir şema değişikliği vardı mı? Hata çıksaydı geri dönebilir miydin?
• Kodunda unutulmuş kaç özellik bayrağı var, hangisinin sahibi belli?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.