Özellik Bayrakları: Kodu Yayınlayıp Özelliği Sonra Açmak

Yeni özellik hazır ama pazarlama ekibi salı günü duyuru yapacak. Kodu bekletmek, o süre boyunca başka hiçbir değişikliği yayınlayamamak demek. Ya da özelliği kapalı yayınlayıp salı günü açabilirsiniz.

Bu yazı, özellik bayraklarını ve sunucu tarafındaki karşılığını ele alıyor.

Yayınlamak ile Açmak

Temel fikir bu iki eylemi ayırmaktır:

• Kod sunucuya çıkar. Ama çalışmaz.
• Bir ayar özelliği açar.
• Açma işlemi yayın gerektirmez.
• Sorun çıkarsa anında kapatılır.

Dördüncü madde en büyük kazançtır: sorunlu bir özelliği kapatmak, kodu geri almaktan kat kat hızlıdır — geri alma dakikalar sürer, bayrak kapatmak saniyeler.

Üstelik geri alma o yayındaki diğer tüm değişiklikleri de iptal eder; bayrak yalnızca sorunlu özelliği durdurur.

Üçüncü madde ise teknik olmayan ekiplere yetki verir. Pazarlama, bir yayın süreci beklemeden özelliği devreye alabilir.

Bayrak Türleri

Üçüncü satır sunucu yönetimi açısından en değerli olanıdır: yoğun anlarda ağır bir özelliği geçici olarak kapatabilmek — arama önerileri, öneri motoru veya detaylı raporlar gibi — siteyi tamamen çökmekten kurtarabilir.

Bu, kasıtlı olarak işlev azaltıp hizmeti ayakta tutma stratejisidir.

Birinci satır ise geçici olmalıdır ve bu, sonraki bölümde ele alınan temel disiplini gerektirir.

Bayrak Borcu

En büyük risk temizlenmemesidir:

1. Özellik açılır ve kararlı çalışır.
2. Bayrak kodda kalır.
3. Yıllar içinde onlarca bayrak birikir.
4. Kod okunamaz hâle gelir.

Dördüncü madde gerçek bir bakım sorunudur: iç içe geçmiş beş bayrak, otuz iki farklı davranış kombinasyonu üretir ve hiçbiri test edilmemiştir.

Bu karmaşıklık, hata ayıklamayı neredeyse imkânsız kılar.

Çözüm basittir ama disiplin ister: her yayın bayrağı oluşturulduğunda bir kaldırma tarihi belirlenmeli ve o tarih geldiğinde bayrak koddan silinmelidir.

Bayrak listesini düzenli gözden geçirmek de aynı işi görür.

Bayrakları Nerede Tutmalı?

Üçüncü ve dördüncü satırlar asıl faydayı sağlar: bayrak veritabanında veya önbellekte tutulursa değişiklik tüm sunuculara anında yansır — yeniden başlatma veya yayın gerekmez.

Ancak bir performans tuzağı vardır: bayrak kontrolü her istekte veritabanına gitmemelidir.

Doğru yaklaşım, bayrakları kısa süreliğine bellekte önbelleklemektir. Birkaç saniyelik gecikme kabul edilebilirdir.

Birinci satır ise küçük ekipler için fazlasıyla yeterlidir ve ek altyapı gerektirmez.

Kademeli Açma

Bayraklar açık-kapalı olmak zorunda değildir:

• Yalnızca iç kullanıcılara açık.
• Belirli bir orana açık.
• Belirli müşterilere açık.
• Belirli bölgelere açık.

Birinci madde en güvenli başlangıçtır: özelliği önce yalnızca kendi ekibinize açmak, gerçek üretim ortamında test etme imkânı verir ve hiçbir müşteriyi riske atmaz.

Bu, test ortamının sağlayamadığı bir gerçeklik sunar.

İkinci madde ise kademeli yayının temelidir. Yüzde birden başlayıp kademeli artırmak, sorunun etkisini sınırlar.

Önemli bir teknik ayrıntı: oran hesabı kullanıcı kimliğine göre tutarlı yapılmalıdır. Aksi hâlde aynı kullanıcı her istekte farklı sürümü görür.

Test Etme Zorluğu

Bayraklar test yükünü artırır:

1. Her bayrak iki yol üretir.
2. İkisi de test edilmelidir.
3. Kombinasyonlar hızla büyür.

Üçüncü madde pratik bir sınır getirir: tüm bayrak kombinasyonlarını test etmek matematiksel olarak imkânsızdır, bu yüzden yalnızca gerçekte kullanılan kombinasyonlar test edilir.

Bu da bayrakların bağımsız tutulmasını zorunlu kılar. Birbirine bağımlı bayraklar, test edilemeyen durumlar üretir.

Kural şudur: bir bayrağın davranışı başka bir bayrağın durumuna bağlı olmamalıdır.

Bayrakları İzlemek

Birinci satır arıza müdahalesini hızlandırır: bir sorun başladığında ilk sorulacak soru "son yayın neydi" değil, "son bayrak değişikliği neydi" olmalıdır — çünkü bayraklar yayından çok daha sık değişir.

Kayıt tutulmuyorsa bu bağlantı kurulamaz.

Üçüncü satır ise temizliği kolaylaştırır. Aylardır hiç kontrol edilmeyen bir bayrak, koddan kaldırılabilir demektir.

Dördüncü satır ise kademeli yayında karar destek sağlar. Yeni sürümün hata oranı yüksekse oran artırılmaz.

Bayrak yönetimi için hızlı bir önbellek katmanı işinizi kolaylaştırır; sanal özel sunucu üzerinde bu tür bir servisi kendi kaynaklarınızla çalıştırabilirsiniz.

Sonuç

Özellik bayraklarının en somut kazancı hızdır: sorunlu bir özelliği kapatmak saniyeler sürer, kodu geri almak dakikalar — üstelik geri alma o yayındaki diğer tüm değişiklikleri de iptal eder. Ama disiplin ister: her yayın bayrağına bir kaldırma tarihi verin, yoksa iç içe geçmiş beş bayrak otuz iki farklı davranış kombinasyonu üretir ve hiçbiri test edilmemiştir. Bayrakları birbirinden bağımsız tutun ve kim ne zaman değiştirdi kaydını mutlaka saklayın.

Sıkça Sorulan Sorular (SSS)

Kodu geri almak yerine neden bayrak?

Çünkü çok daha hızlı ve daha hedeflidir. Bayrak kapatmak saniyeler sürer, geri alma dakikalar. Ayrıca geri alma o yayındaki diğer tüm değişiklikleri de iptal ederken, bayrak yalnızca sorunlu özelliği durdurur.

Bayrakları nerede saklamalıyım?

Anlık değişim istiyorsanız veritabanında veya önbellek sunucusunda — değişiklik tüm sunuculara yeniden başlatma olmadan yansır. Ancak bayrak kontrolü her istekte veritabanına gitmemeli; birkaç saniyelik bellek önbelleği kullanın. Küçük ekiplerde ortam değişkeni de yeterlidir.

Bayrakları ne zaman kaldırmalıyım?

Yayın bayraklarını özellik kararlı çalışmaya başlar başlamaz. Her bayrak oluşturulduğunda bir kaldırma tarihi belirleyin; aksi hâlde yıllar içinde onlarca bayrak birikir ve iç içe geçmiş beş bayrak bile otuz iki test edilmemiş kombinasyon üretir.

Kademeli açmada neye dikkat etmeliyim?

Oran hesabını kullanıcı kimliğine göre tutarlı yapın — aksi hâlde aynı kullanıcı her istekte farklı sürümü görür. Ayrıca önce yalnızca kendi ekibinize açın; bu, test ortamının sağlayamadığı gerçek üretim koşullarında deneme imkânı verir.