Feature Flag Nedir: Yazılım Dağıtımında Kontrol ve Yönetim
Summary
Feature flag'ı dört türe ayırın: release, experiment, operations, permission. Her türün kendine özgü yaşam süresi ve yönetimi vardır. Teknik borç oluşmasını önlemek için flag'ları stok olarak görün, ayda on dakika review yapın ve yüzde 100'de iki haftadan fazla kalmış flag'ları silin.
Feature Flag Nedir: Kontrollü Yazılım Dağıtımı Rehberi
Feature flag nedir? Basit bir cevap: kodunuza yerleştirdiğiniz ve çalışma zamanında bir özelliğin açık mı yoksa kapalı mı olduğunu belirleyen koşullu bir ifade. Yeni bir dağıtım yapmadan. Esas olarak bu kadar. Uygulamada ise? Bir if ifadesi, ancak bu ifadenin cevabı, sabit kodlanmış değer yerine, konfigürasyondan, veritabanından veya özel bir flag hizmetinden geliyor.
Konsept son derece basit. Ancak bir depo içinde 200 feature flag ile yaşamak hiç basit değil. Bu rehber de tam olarak işte bununla ilgileniyor.
Kodda Feature Flag Neye Benziyor?
En pratik ve çalışır hali şöyle:
if (flags.isEnabled("new-checkout", { userId })) {
return renderNewCheckout();
}
return renderOldCheckout();Her iki kod yolu da aynı derleme içerisinde gönderilir. Ancak flag değeri, ki bunu yeniden dağıtım yapmadan değiştirebilirsiniz, ortam değişkeninde, bir JSON dosyasında, veritabanında veya uzakta barındırılan bir flag hizmetinde tutulur. Değeri değiştirin ve davranış sonraki kontrol sırasında anında değişir.
Bu ayrılış işin ana noktası: Dağıtım (kodun sunuculara konması) Sürüm (kullanıcıların onu görmesiyle) farklı olur. Feature flag ile main branch'e merge etmek artık "herkes bunu şimdi alıyor" demek değildir. Bu sayede takımlar tamamlanmamış özellikler ile güvenli şekilde main branch'te çalışabilir. Kod kalitesi artar, test süreçleri basitleşir.
Neden Takımlar Feature Flag Kullanır?
Beş ile 50 kişilik gerçek mühendislik takımlarında, aynı üç sebep tekrar tekrar ortaya çıkıyor.
Tamamlanmamış işi güvenle merge edin. Yarı bitmemiş yeni özelliği kapalı bir flag arkasına koyar, main branch'e merge edersiniz. Dalınız asla üç hafta boyu açık kalmaz. Bu sayede trunk-based development iş düzeyine yükseltilir. Kod review'lar daha küçük ve yönetilebilir olur.
Kademeli olarak kullanıcılara dağıtın. Bir değişikliği önce iç takım için açın, sonra trafiğin yüzde 5'ine, sonra yüzde 50'sine, en sonunda herkese. Hata oranı fırlarsa, bir buton ile saniye içinde geri kapatırsınız. Bu kontrollü dağıtım, riski minimalize eder ve sorunları erken yakalamaya yardımcı olur.
Kriz anında bir özelliği kesebilirsiniz. Sabah 2'de bir ödeme sağlayıcısı çalışmayı bıraktı mı? Flag ile tüm sürümü geri almak yerine, sadece o özelliği kapatabilirsiniz. On-call mühendisler saniye içinde düzeltebilir.
Bu üç avantajın hiçbiri ücretli bir platform gerektirmez. Flag, sadece bir config tablosundaki boolean olabilir. Gradual rollout, denetim günlükleri veya teknik olmayan kişilerin flag döndürmesine ihtiyaç duyana kadar, ki bunu büyüyünce alırsınız, platformu atlamakta sakınca yoktur.
Feature Flag'ın Dört Türü
Pete Hodgson'ın yaygın olarak kullanılan Martin Fowler'ın blog makalesindeki Feature Toggles yazısı flag türlerini iki özelliğe göre sınıflandırır: ne kadar süre yaşadıkları ve karar ne sıklıkta değişiyor?
Release Flag: Günler ile haftalar arası yaşam. Mühendisler tarafından çevrilir. Örnek: Henüz hazır olmayan checkout yeniden tasarımını kullanıcılardan gizlemek. Sürümle birlikte kaldırılır.
Experiment Flag: Haftalar arası yaşam. Ürün ve veri analizi takımı tarafından yönetilir. Örnek: İki farklı fiyatlandırma sayfasının A/B test'i. Sonuç netleşince kaldırılır.
Operations Flag: Saatler ile sonsuza kadar yaşam. Oncall tarafından çevrilir. Örnek: Yavaş tavsiye motoruna karşı koruma anahtarı. Kriz döneminde kullanılır.
Permission Flag: Aylar ile yıllar arası yaşam. Ürün ve destek tarafından yönetilir. Örnek: Beta erişimi veya sadece Premium kullananların göreceği özellikler. Uzun dönem korunur.
Yaşam süresi en kritik sözdir. Kendi sürüm döngüsünü aşan bir release flag bir hatadır. Temizleme sprint'inde silinmesi gereken permission flag ise gözlenmemiş kesintiye davet çıkarmaktır.
Flag oluştururken türünü ve etiketini net olarak belirleyin. Altı ay sonra "new-nav-v2"nin hangi kategoriye ait olduğunu kimse hatırlamayacak.
Flag Dağıtımını Kullanıcıları Etkilemeden Nasıl Yapar?
Proven yöntem sıkıcı ama işler:
Kodu flag kapalı şekilde gönderin. Hiçbir şey değişmedi mi doğrulayın.
Üretim ortamında sadece takımınız için açın. Bir gün kullanın. Gözlemler yapın.
Kullanıcıların yüzde 1 ile yüzde 5'i arasında aç. Stickiness önemli, aynı kullanıcı oturum içinde farklı varyantlar görmemelidir.
Hata oranını, gecikmeyi ve seçeceğiniz bir iş metriğini takip edin. Eşiği önceden belirleyin, panoyu izlerken değil. Metriklere dayanarak karar verin.
Yüzde 100'e çıkın, belirli bir süre bekleyin, sonra flağı kaldırın. Hızlı olmayın.
Adım 5, takımların atladığı kısım. Bunun maliyeti sanıldığından çok yüksektir.
Pratik bir not: Flag kontrollerini ucuz ve emniyetli yapın. Eğer flag hizmeti düşerse, kodunuz bir varsayılan değere dönebilmeli. Hangisinin varsayılan olacağını flag bazında seçin. Kill switch "emniyetli"ye, yeni özellik ise "kapalı"ya dönmeli.
Neden Feature Flag'lar Teknik Borç Haline Geliyor?
Her flag kodda bir dal yaratır. İki flag dört olası yolu, on flag 1.024 yolu demek, ve hepsi tabii ki tam olarak test edilmiyor. GrowthBook'un Flag Borcuna Dair Mühendislik Rehberi, araştırmalara göre toggle bileşenlerinin yüzde 75'inin devreye alındıktan 49 hafta sonra bile depolarda hala bulunduğunu gösteriyor. Oysa çoğu geliştirici kaldıracaklarını söylüyordu.
Hodgson bunu aynı makalede güzel ifade ediyor: Tecrübeli takımlar toggle'ları stok olarak görerek, taşıdığı maliyeti minimize etmeyi işin parçası yapar.
Korkunç bir örnek: Knight Capital, 2012'de. Emekli olan bir özelliğin flag'ı başka bir davranış için yeniden kullanıldı, ancak bir sunucuda eski kod hala duruyor. Bu uyumsuzluk bir saatten biraz daha az zaman içinde yaklaşık 460 milyon dolar kaybına sebep oldu. Sizin eski flag'ınız bu kadarını yapamayacak. Daha sessiz ama içerip dökülü hale getirecek şeyler yapacak: Kimsenin var olduğunu bilmediği bir kodu kıran refactor, veya yeni işe alınan junior'un hangi checkout versiyonunun gerçek olduğunu anlamaya bir öğleden sonra harcaması.
Var Olan Codebase'de Bütün Flag'ları Nasıl Bulursunuz?
Bu, satıcı dokümentasyonunun hiç konuşmadığı konu. Ve çoğu takımın sıkıştığı yer. Flag panosu sadece yapılandırılan şeyleri gösterir. Hangi flag'ın koddaki nerelerde okunduğunu veya "kapalı" flag arkasındaki kodun hala erişilebilir olup olmadığını söylemez.
Basit yaklaşımla başlayın:
# Sarmalayıcınız üzerinden okunan her flag anahtarı
rg -n 'isEnabled\("' src/ | sort
# Tanımlanmış ama hiç referans edilmeyen flag'lar
comm -23 <(jq -r 'keys[]' flags.json | sort) \
<(rg -o 'isEnabled\("([^"]+)"' -r '$1' src/ | sort -u)Ama bu çabuk çöker. Dize birleştirme ile oluşturulan flag anahtarları grep'te görünmez. Yardımcı fonksiyonlardan geçirilen flag'lar kendilerini gizler. Monorepo ve multi-repo düzenlemeler problemi çoğaltır, aynı flag anahtar üç ayrı hizmet tarafından okunabilir.
İşte bu noktada kodun araç ile okunması kritikleşir. Depo yapısını anlayan kod arama araçları "new-checkout flag'ı nerede değerlendiriliyor ve ne bağlıdır?" sorusuna bir öğleden sonra yerine bir sorguyla cevap verir. Cursor ve GitHub Copilot tek repo için bunu iyi halleder. Birden fazla repo'da? Tüm repo'ları kapsayan bir index gerekir, codebasechat'ın tam olarak bunun için yapıldığı durum.
Akılcı Flag Temizleme Süreci Nasıl Yürür?
Kaldırmayı işin bir parçası olarak görün, sonradan yapılacak görev olarak değil.
Flağ ile beraber removal ticket'i oluşturun. Flağ tanımında bağlayın. Ticket yoksa flag şimdiki şekliyle gönderilemez. Bu otomasyon, unutulmuş flag'ları engeller.
Her non-permanent flag'ın sahibini ve expiry tarihini belirleyin. 90 gün hiç değişiklik olmadan makul bir review tetikleyicidir. Sahibi kim? Ne zaman kontrol edilmeli?
İki pull request'te kaldırın. Önce flag kontrolünü silin kazanan yolu koruyun. Sonra ölü kodu ve testlerini silin. Küçük PR'lar review edilebilir PR'lardır. Daha az bug riski.
Time bomb test ekleyin. Bir release flag'ın expiry'sini geçtiğinde fail olan bir test, iyi niyeti kırmızı build'e dönüştürür. Build otomatik olarak protesto eder.
Toplam kontrol edin. 40 aktif flağınız varsa ve limit 40 ise, birini eklemek birini kaldırmak demektir. Sınırı tutun.
Statik analiz bu konuda çok yardımcıdır. CodeScene gibi araçlar hangisi dosyalarının en kötü karışık conditional logic içerdiğini gösterebilir, bu genellikle eski flag'ların kümelenmesidir. SonarQube, bir flag kontrolü kaldırdıktan sonra ulaşılamaz ve dead code'u işaretler.
Flag Arkasında Olan Kodu Nasıl Test Edersiniz?
Test, kimsenin bütçesine aldığı kısım değildir. Ancak gereklidir. Flag başına iki yol, test suite'iniz her ikisini de kapsamalı, en azından riskli davranışı koruyan flag'lar için.
Pratik tutun. Release flag'ların açık ve kapalı durumlarını unit testlerde test edin, flag değerini enjekte ederek, live service'ten okumayarak. Prod konfigürasyonuna karşı bir end-to-end test suite çalıştırın çünkü bu kullanıcıların şimdiye aldığı şey. Sonra yayınlamak üzere olduğunuz özellik için flag'ı açık şekilde ikinci bir geçiş yapın.
Bütün kombinasyonları test etmeye çalışmayın. On flag ile imkansızdır. Bunun yerine flag'ları bağımsız tutun: bir flag yalnızca başka flag da açık olduğunda davranış değişiyorsa design smell'dir, disentangle edin.
Yeni Mühendisler Flag'lar Hakkında Ne Yanlış Alıyorlar?
Gençler aynı üç hatayı yaparlar, her biri review'da ucuz önlenebilir:
Flag'ları yuvalamak. Bir flag başka flag içinde sadece her ikisi de açıkken var olan yol oluşturur. Net adlı tek flag isteyin. Basitlik kazanır.
Mantığı flag adına kodlamak. "show-new-nav-v2-to-premium-users-in-eu" gibi anahtarlar, flag hizmetinde yaşaması gereken targeting kuralını string'e kodlar. Yanlış yer.
Varsayılanı unutmak. Flag kontrolü başarısız olursa ne olur? Cevabı PR açıklamasında yazmasını isteyin. Silendiği tanımlanmış olmalı.
Yeni işe alınan ilk iki hafta tam olarak sahibi olmayan eski flag'larla karşılaşma zamanıdır. Türü, sahibi ve removal tarihi olan kısa bir flag registry birkaç saat sormayı kaydeder.
Feature Flag'ları Ne Zaman Atlamalısınız?
Flag'lar ücretsiz değildir. Atla:
Değişim küçük, geri döndürülebilir ve bir deploy uzağında rollback mümkün. Flag kod yolü ekler, kazanç yoksa. Karmaşıklık getirmez.
Değişim veritabanı şemasında bir flag'ın gizleyemediği bir şekilde etki ediyor. Expand-contract migration kullanın. Flag yardımcı olmaz.
Takımınız flag kaldırma süreci yok. Önce bunu düzeltin. Temel olmadan flag'lar tehlike.
Değişim riskli, user-facing, deploy ile geri döndürülemez mi? Kill switch, auth değişiklikleri, data migration arkasındaki bir şey, kullanın. Koruma sağlar.
On Kişilik Takımda Gerçekten Ne Yapardık
Config'de boolean ve tek bir sarmalayıcı fonksiyon ile başlayın. Böyle her flag oku bir noktadan geçer. Bu single choke point'i greppable, auditable ve sonra hosted service'e migrate etmesi kolay yapar.
Her flag'ı türe göre etiketleyin, sahip atayın, kaldırma ticket'ini ilk gün dosyalayın. Listeyi aylık on dakika review edin. Yüzde 100'de iki hafta kalmış flag'ları silin. Sistem temiz kalır.
Feature flag bir kredidir. Riskli release tasarrufu yaptığında kullanın. Faizin büyümeden kaldırın.
Özet: Feature Flag Stratejisi
Feature flag'lar güçlü bir araçtır, ancak sadece disiplin ile yönetilirseniz. Bir flag oluşturmadan önce sorun: Hangi tür? Kim sahibi? Ne zaman kaldırılacak? Bu üç soru cevaplandırılmadıkça, flag bir borça dönüşür. Başlangıçta basit tutun. Config'de boolean. Tek sarmalayıcı. Aylık review. Zamanla platform ekleyin eğer ihtiyaç varsa. Ancak core disiplin hep aynı kalır: Envanteri kontrol altında tutun, maliyetini minimize edin, teknik borcu önleyin. Başarılı takımlar bunu yapar. Pratik olarak uygulandığında, feature flag'lar takımın verimliliğini dramatik şekilde artırabilir. Kesinlikle.