Yeni özelliği herkese aynı anda mı açmalı? Özellik bayrakları ve kademeli yayın

Bir özelliği tüm kullanıcılara aynı anda açmak, tek seferde oynanan ve geri alınması yeni bir sürüm gerektiren bir bahistir. Alternatifi şudur: kodu kapalı halde yayına alın, önce kendi ekibinize sonra kullanıcıların küçük bir dilimine açın, önceden belirlediğiniz metriği izleyin, bozulma görürseniz bayrağı kapatın, her şey yolundaysa yüzdeyi kademeli yükseltin ve iş bittiğinde bayrağı koddan silin. Bu mekanizmanın adı özellik bayrağı (feature flag). Zor kısmı bayrağı açmak değil, bayrakların yaşam döngüsünü yönetmek: kim açabilir, hangi koşulda kapanır, ne zaman koddan çıkar.

Yayına almak ile açmak aynı şey değil

Klasik akışta bir özellik tamamlandığında yayına çıkar ve aynı anda görünür olur. Bu iki olayı üst üste bindirmek, dağıtım riskiyle ürün riskini tek pakete koyar. Bir sorun çıktığında elinizde tek bir hamle kalır: sürümü geri alıp o dağıtımdaki diğer tüm değişiklikleri de geri götürmek.

Bayrak bu ikisini ayırır. Kod üretimde durur ama kapalıdır. Açma kararı ürün tarafının, dağıtım kararı mühendisliğin olur. Bunun yan etkisi uzun süren özellik dallarının (feature branch) da ortadan kalkmasıdır: yarım kalmış iş, ana dala kapalı halde girip birleştirme acısı yaratmadan büyüyebilir. Dağıtımın kendisini kesintisiz yapmak ayrı bir konu, onu sıfır kesintili yayına alma yazısında ele almıştık.

Dört farklı bayrak, dört farklı ömür

Pete Hodgson'ın martinfowler.com'da Ekim 2017'de yayımladığı sınıflandırma bugün hâlâ en kullanışlı çerçeve. Bayraklar ömür ve değişkenlik eksenlerinde dörde ayrılıyor.

• Sürüm bayrağı: yarım kalmış özelliği kapalı taşır. Ömrü haftalarla ölçülür, kararı statiktir, işi bitince silinir.
• Deney bayrağı: A/B testi için kullanıcıyı farklı yollara ayırır. Aynı kullanıcı hep aynı kolda kalmalıdır, yoksa ölçüm anlamsızlaşır.
• Operasyon bayrağı: yük altında pahalı bir özelliği kapatmaya yarar. Çoğu kısa ömürlüdür, bir kısmı acil kapatma anahtarı olarak kalıcıdır.
• Yetki bayrağı: özelliği belirli bir gruba (beta kullanıcıları, kurumsal paket, iç ekip) açar. Yıllarca yaşayabilir.

Bu dördünü aynı listede, aynı isimlendirmeyle ve aynı sahiplik kurallarıyla yönetmek karışıklığın başladığı yerdir. Üç haftada silinmesi gereken bir sürüm bayrağı ile üç yıl yaşayacak bir yetki bayrağı aynı muameleyi görmemeli.

Bayrak yanlış yönetilince: Knight Capital örneği

Konunun en pahalı dersi 1 Ağustos 2012'de yaşandı. SEC'in 16 Ekim 2013 tarihli kararı olayı adım adım anlatıyor ve neredeyse bir bayrak yönetimi kontrol listesi gibi okunuyor.

Knight Capital, "Power Peg" adlı bir işlevi 2003'te kullanmayı bıraktı ama kodu üretim sunucularından silmedi. 2005'te bu kodun içindeki kümülatif miktar sayacı başka bir yere taşındı ve Power Peg tekrar test edilmedi. Temmuz 2012'de yeni bir sipariş yönlendirme özelliği yazıldığında, ekip eskiden Power Peg'i çağıran bayrağı yeniden kullandı. 27 Temmuz'da başlayan dağıtımda bir teknisyen yeni kodu sekiz sunucudan birine kopyalamadı; ikinci bir kişinin kontrol etmesini isteyen yazılı bir prosedür yoktu.

1 Ağustos sabahı saat 08:01'den itibaren şirketin sistemleri "Power Peg disabled" diyen 97 otomatik e-posta üretti. Bu mesajlar uyarı olarak tasarlanmamıştı ve piyasa açılmadan önce kimse üzerine gitmedi. Açılışta yeniden kullanılan bayrak sekizinci sunucuda eski kodu tetikledi. 212 müşteri emri 45 dakika içinde 154 hissede 4 milyonun üzerinde işleme ve 397 milyon hisseye dönüştü. Şirket 460 milyon doları aşan zarar yazdı, SEC 12 milyon dolar para cezası kesti. Olay sırasında ekip sorunu ararken doğru kodun bulunduğu yedi sunucudan yeni kodu kaldırdı, yani hatalı davranışı sekiz sunucunun tamamına yaydı.

Buradan çıkan dört kural doğrudan uygulanabilir: eski bir bayrağın adını asla yeni bir işlev için geri dönüştürmeyin, ölü kodu üretimde bırakmayın, bayrağın durumu her sunucuda aynı olmak zorundadır, ve bayrakla ilgili hata mesajları e-posta kutusuna değil alarm kanalına düşmelidir.

Kademeli yayın nasıl yapılır

Yüzde yüze bir adımda gitmek yerine dilimleyin. İşleyen bir sıra şöyle: iç ekip, sonra gönüllü beta grubu, sonra yüzde 1, yüzde 5, yüzde 25 ve yüzde 100. Her adımda üç şey önceden yazılı olmalı: hangi metriğe bakılacak, ne kadar beklenecek ve hangi eşikte geri dönülecek.

Yüzde dağıtımı rastgele yapılmaz. Kullanıcının kalıcı kimliği (kullanıcı numarası, hesap numarası) bir hash fonksiyonundan geçirilir ve dilim ona göre belirlenir. Böylece yüzdeyi 5'ten 25'e çıkardığınızda ilk gruptaki kimse dışarı düşmez. Aksi halde kullanıcı bir gün gördüğü ekranı ertesi gün bulamaz ve destek ekibiniz açıklayamadığı biletlerle uğraşır.

Aşamalı dağıtımın sadece uygulama koduyla ilgili olmadığını 19 Temmuz 2024'teki CrowdStrike olayı gösterdi. Bir güvenlik ürününün içerik güncellemesi (Channel File 291) dünya genelinde aynı anda dağıtıldı ve Microsoft'un tahminine göre yaklaşık 8,5 milyon Windows cihazı etkilendi. Şirketin yayımladığı kök neden analizindeki taahhütlerden biri açık: içerik şablonları da aşamalı olarak dağıtılacak. Yapılandırma, kural dosyası ve model güncellemesi de en az kod kadar dağıtım disiplini ister.

Acil kapatma anahtarı ve bayrak servisinin kendisi

Kademeli yayının değeri, geri dönüşün hızlı olmasından gelir. Kritik entegrasyonlar ve pahalı işlemler için ayrı birer kapatma anahtarı tanımlayın: ödeme sağlayıcısı, arama servisi, öneri motoru, toplu e-posta gönderimi. Bu anahtarların nasıl kapatılacağı olay anında aranacak bir bilgi olmamalı, olay müdahale planınızın içinde yazılı durmalı.

Bir sonraki soru şu: bayrak servisi çökerse ne olur? Unleash'in yayımladığı ilkeler arasında bunun net bir cevabı var, erişilebilirlik tutarlılığın önüne konur. SDK yerel önbellekle çalışmaya devam etmeli, ağ bağlantısı kopsa bile son bilinen değerle karar verebilmelidir. Uygulamanızın her isteğinde uzaktaki bir servise senkron çağrı yapan bir bayrak kütüphanesi, riski azaltmak için eklediğiniz şeyi tek hata noktasına çevirir.

Bayrak bir yetkilendirme mekanizması değildir

Yetki bayrakları ile yetkilendirme sık karıştırılır. Tarayıcıda değerlendirilen bir bayrak, kapalı olsa bile kodun içinde durur: JavaScript paketini açan biri özelliğin varlığını, çoğu zaman uç nokta adreslerini de görebilir. Bayrak arayüzü gizler, erişimi engellemez.

Pratik ayrım basit. Kim neyi görebilir sorusunun cevabı sunucuda, yetkilendirme modelinin içinde durur. Bayrak yalnızca bir özelliğin hangi kitleye açık olduğunu belirler ve sunucu tarafında değerlendirilir. Aynı ilke kişisel veri için de geçerlidir: kullanıcıyı dilimlere ayırmak için e-posta adresini ya da kimlik bilgilerini bayrak servisine göndermek yerine, hedeflemeyi kendi tarafınızda yapıp servise anonim bir anahtar verin.

Bir de yönetişim tarafı var. Üretimde bayrak açıp kapatabilmek, sürüm sürecinden geçmeden davranış değiştirebilmek demektir. Bu yetki dar tutulmalı, her değişiklik kim, ne zaman, hangi değer diye kaydedilmeli, yüksek riskli bayraklarda ikinci onay istenmelidir. Bayrak değişikliği de bir dağıtımdır; panolarınıza dağıtım gibi işaretleyin, çünkü bir hafta sonra grafikteki kırılmayı açıklayan tek şey o olabilir.

Bayrak borcu: asıl maliyet burada

Her bayrak koda bir çatal ekler ve iki yolu birden canlı tutar. On bayrak teoride bin kombinasyon demektir; hiçbir ekip bunu test edemez. Hodgson'ın önerisi makul olanı yapmaktır: üretimde beklenen yapılandırmayı ve geri dönülecek yapılandırmayı test edin, tüm kombinasyonları değil.

Birikmeyi engelleyen kurallar sıkıcı ama işe yarar. Bayrağı açan kişi bayrağın sahibidir. Her bayrak oluşturulurken bir kaldırma tarihi ve bir temizlik işi birlikte açılır. Sürüm bayrağı yüzde yüze ulaştıktan sonra aynı sprint içinde koddan silinir, "sonra bakarız" listesine girmez. İsimlendirme tek biçimdir ve silinen bayraklar arşivlenir, böylece hangi dönemde ne açıldığı kayıtta kalır. Bu disiplin yoksa bayraklar teknik borcun en sinsi kalemine dönüşür: kodu okuyan yeni bir geliştirici, aylardır kimsenin kapatmadığı bir bayrağın hâlâ anlamlı olup olmadığını anlamak için saatler harcar.

Kendi yazmak mı, hazır servis mi?

Başlangıç için hazır servis şart değil. Veritabanında bir tablo, yönetim ekranında bir anahtar ve uygulamanın bunu çalışırken yeniden okuması çoğu ekibin ilk altı ayını rahat götürür. Ölçütünüz şu olsun: yüzde bazlı dağıtım, kullanıcı segmenti hedefleme, değişiklik geçmişi ve çok servisli tutarlılık ihtiyacı doğduğunda hazır çözüme geçin.

Kilitlenme endişesi için standart tarafında OpenFeature var. CNCF'e Haziran 2022'de sandbox olarak kabul edildi, Aralık 2023'te incubating seviyesine geçti ve satıcıdan bağımsız bir API tanımlıyor. Sağlayıcı listesi geniş: flagd, Unleash, Flagsmith, GrowthBook, ConfigCat, LaunchDarkly, Split ve diğerleri. Uygulama kodunuz standart arayüzü çağırır, sağlayıcı değişince koda dokunmazsınız. Açık kaynak seçenekleri kendi sunucunuzda çalıştırılabilir, bu da veriyi kendi tarafınızda tutmak istediğinizde işi kolaylaştırır.

Nereden başlamalı

Üç adım yeterli. Bir sonraki orta ölçekli özelliği kapalı halde yayına alın ve önce sadece iç ekibe açın. O özellik için tek bir başarı metriği ve tek bir geri dönüş eşiği yazın, sözlü mutabakat değil, iki satır metin. Bayrağı açarken kaldırma işini de aynı anda oluşturun.

Bu üçünün karşılığı, bir hata çıktığında sürüm beklemeden dakikalar içinde geri dönebilmektir. Ölçme tarafını izlenebilirlik ve hata bütçesiyle, dağıtım tarafını küçük ekipler için CI/CD hattıyla birleştirdiğinizde yayına çıkmak korkulacak bir gün olmaktan çıkar. Wedevit bu incelemeyi uzaktan yapıyor: mevcut bayraklarınızı, kimin açabildiğini ve koddaki ölü yolları çıkarıp size sadeleştirilmiş bir yayın akışı öneriyoruz.