Feature Flag Nedir? Deployment ve Release'i Ayıran Karar
Summary
Feature flag'ler, yeni bir build göndermeden uygulamanızdaki kod yollarını kullanıcı ve ortam bazında kontrol etmenizi sağlar. Deployment ile release'i iki ayrı olaya dönüştürürler: kod prod'da hareketsiz bekler, SLO bütçesi yeşil kaldıkça yüzdesel olarak açılır. Bir şeyler yanlış giderse flag kapatılır ve incident önlenir. %1 trafikten başlayan aşamalı rollout, blast radius'u dakikalar içinde kurtarılabilir boyuta indirger. Kill switch tasarımı ve flag borcu yönetimi bu mimarinin iki kritik bileşenidir.
Feature flag nedir? Yeni bir build göndermeden, uygulamanızdaki belirli kod yollarını kullanıcı, oturum ya da ortam bazında kontrol etmenizi sağlayan koşullu denetimlerdir. new_checkout_flow adlı bir flag, kullanıcı tabanınızın %99'unda false olarak ayarlanmışsa o kodu iki hafta önce deploy ettiniz demektir; henüz açmadınız. Bu mekanizmanın kurduğu sözleşme nettir: deployment ve release iki ayrı olay haline gelir. Sürekli deployment yapan, 50 ila 500 mühendislik ekibinin çalıştığı her organizasyon için bu sözleşme, mimari açıdan yük taşıyan bir karardır. Feature flag piyasası 2024'te 1,45 milyar dolar değerindeydi; 2033'e kadar 5,19 milyar dolara büyümesi öngörülüyor (Zylos Research, 2026). Progressive deployment tekniklerini benimseyen kurumların %78'i deployment güveninde artış bildiriyor. Araç, büyümüştür. Mimari disiplin henüz aynı hızda değil.
Deployment ile Release Aynı Olay Değildir
Çoğu ekip bu farkı kötü bir rollout'tan sonra öğrenir. Bir özellik Salı öğleden sonra prod'a çıkar, Çarşamba sabahı request trace'inde bir şeyler farklı davranmaya başlar; birisi soruşturma açtığında diff dört commit'i ve iki servis sınırını kapsamaktadır. Bu senaryoda nedensellik kurmak gerçekten zordur.
Feature flag'ler bu soruna zorunlu bir hassasiyet getirir. Bir flag'in arkasındaki kod merge edilip deploy edildiğinde prod'da hareketsiz kalır. Deploy'un başarılı olduğunu doğrularsınız, birkaç saat ya da gün boyunca baseline metrikleri izlersiniz ve hiçbir şeyin bozulmadığını kontrol edersiniz. Ardından flag'i trafiğin %1'i için açarsınız. Artık tek bir atfedilebilir değişkeniniz vardır. Flag'li yolda hata oranı yükseliyorsa bir kod diff'ini debug etmiyorsunuzdur. Bir config değerini toggle ediyorsunuzdur.
Bu ayrım öncelikle bir hız argümanı değildir. Bir blast radius argümanıdır. Oturumların %1'ini etkileyen ve yanlış giden bir release dakikalar içinde kurtarılabilir. %100'ünü etkileyen ve yanlış giden bir release büyük bir incident'tır.
TypeScript'te flag değerlendirmesi kabaca şöyle görünür:
const showNewCheckoutFlow = flagClient.variation(
'new_checkout_flow',
{ userKey: session.userId, custom: { plan: user.plan } },
false // flag servisi ulaşılamaz durumdaysa varsayılan
);
if (showNewCheckoutFlow) {
return renderNewFlow(cart);
}
return renderLegacyFlow(cart);false varsayılanı bir formalite değildir. Flag değerlendirme servisi network bölünmesi yaşarsa kullanıcılarınızın alacağı davranış budur. Kasıtsız değil, kasıtlı olarak tanımlayın.
Prod'da Gerçekten Önemli Olan Dört Flag Tipi
Tüm feature flag'ler aynı operasyonel amaca hizmet etmez. Bunları kod tabanınızda ve yönetim araçlarınızda özdeş biçimde ele almak; incident sürecinde karışıklığa ve flag borcu birikimine güvenilir bir yol açar.
Release flag'leri, geliştirme ve rollout sırasında yeni özellikleri kilitler. Geçici olmaları beklenir: bir özellik dalında çalışma başladığında oluşturulur, özellik kullanıcıların %100'üne ulaşıp ekip kararlılığı doğruladığında kaldırılır. Kaldırma tarihi ve sorumlu sahibi olmayan release flag'leri kod tabanınızda kalıcı eşyaya dönüşür.
Deney flag'leri, A/B testlerini ve çok değişkenli deneyleri yönetir. Analitik kohort tanımlayıcılarına bağlıdır; yaşam döngüleri deney sınırıyla çizilir. Deney bittiğinde flag onunla birlikte gider. Yaygın hata: kazanan varyantı flag'in arkasında tutmak, çünkü kaldırma "acil değil" görünür. İki yıl sonra deney flag'i kritik yolun bir parçasıdır ve hangi varyantın aktif olduğunu kimse hatırlamaz.
Ops flag'leri kill switch ve devre kesicilerdir. Release flag'lerinin aksine kalıcı altyapı olarak tasarlanır. SLO'su bozulduğunda yavaş bir ML inference katmanını bypass etmenizi sağlayan disable_ml_recommendations flag'i, sabah 3'te dokümantasyon okumadan kullanmak istediğiniz bir şeydir. Bu flag'ler yerel olarak değerlendirilmeli, iyi belgelenmiş bir fallback'i olmalı ve baskı altında keşfedilmek yerine normal operasyonlarda düzenli test edilmelidir.
İzin flag'leri kullanıcı katmanına, hesap planına ya da beta kohortuna göre erişimi denetler. Tasarım gereği uzun ömürlüdür. Karışıklık riski: tarihçeyi bilmeyen bir okuyucuya izin flag'leri release flag'leri gibi görünebilir. Net bir adlandırma kuralı başka hiçbir yerde bu kadar önemli değildir.
SLO Kapısı Olmayan Yüzde Rollout Sadece Yavaş Deployment'tır
Çoğu feature flag uygulamasının durduğu yer burasıdır. Platform ekibi bir rollout takvimi kurar: Pazartesi %1, Salı %5, Çarşamba %25, Cuma %100. Belgelendirir, paydaşlarla paylaşılır ve buna progressive delivery denir.
Fakat her adımda bir doğrulama koşulu olmadan "aşamalı" kelimesi ertelenmiş risktir; azaltılmış risk değil. Yüzde kadranı maruziyeti kontrol eder. Güvenliği doğrulamaz.
Aşamalı rollout'u operasyonel açıdan anlamlı kılan şey her aşama arasındaki SLO kapısıdır. %5'ten %25'e geçmeden önce bir şey şunu yanıtlamalıdır: flag'li kod yolundaki hata oranı SLO bütçesi dahilinde mi? p99 gecikme, kontrol grubuyla aynı bantta mı seyrediyor? Hata bütçesi baseline'dan daha hızlı tükeniyor mu?
Bu soruların hiçbiri araçsallaştırılmamışsa rollout takvimi bir zaman çizelgesidir, doğrulama döngüsü değil.
Prod'da geçerli bir kurulum: iki SLO değerlendirme penceresi tanımlayın. Kısa pencere (15 dakika) hızlı arızaları yakalar; hatalı bir veritabanı sorgusu, şema uyuşmazlığı, kritik yoldaki bir regresyon. Uzun pencere (24 saat ya da bir tam trafik döngüsü) kademeli bozulmayı yakalar; bellek sızıntıları, önbellek baskısı, düşük frekanslı trafik segmentlerindeki uç durumlar. Herhangi bir ilerleme öncesinde her iki pencerenin yeşil göstermesini zorunlu kılın. Herhangi bir pencere ihlal edilirse rollout'u durdurun ve nöbetçiyi sayfalayın.
Yüzde bir kadrandır. SLO penceresi kapıdır. İkisi birlikte gereklidir.
Bu yapıyı kurmak için büyük bir bütçeye gerek yok. Flag platformunun observabilite servisine bağlı otomatik doğrulama adımı ve nöbetçiyi sayfalayan basit bir alerting kuralı yeterlidir. Karmaşıklık ölçekle birlikte artar; ama bu çekirdeği beş kişilik bir platform ekibi bile bugün uygulayabilir.
Kill Switch Mühendisliği: İhtiyaç Duymadan Tasarlayın
Kill switch bir yedek değildir. Özellik kodunun ilk satırı yazılmadan önce var olması gereken birinci sınıf bir tasarım kararıdır.
Baskı altında tasarlanan kill switch, incelenmemiş varsayımları olan bir kill switch'tir. Aktif bir incident sırasında, bir PagerDuty bildirimi üzerinden açılan terminal oturumunda, Slack thread'ini izleyen beş kişiyle birlikte ilk kez test ediyorsunuzdur. Ops flag'inizin kullanıcıları oturum kimliğine göre hedeflediğini ve oturum servisinizin şu anda bozulmuş olduğunu keşfetmek için bu en kötü andır.
Prod kullanımı için tasarlanmış her kill switch için pazarlık edilemez üç özellik:
50ms altı yerel değerlendirme: flag kontrolü uzak bir değerlendirme servisine yapılan ağ çağrısı olamaz. Değerlendirme, kendisi bozulmuş olabilecek bir servise bağımlıysa incident yanıt yolunuzda döngüsel bir bağımlılığınız vardır.
Açık fallback değeri: flag servisi erişilemez durumdayken flag ne döndürür? Bu durum belgelenmeli, kodda tanımlanmalı ve test edilmelidir. "SDK varsayılanı ne ise o" bir yanıt değildir.
Bağımlılık arızası altında test edilmiş: kill switch'ler kaos mühendisliği rotasyonunuzun parçası olmalıdır. Auth'un bozulduğu, flag servisinin kendisinin down olduğu ve değerlendirme uç noktasına ağ gecikmesinin 2 saniyeyi aştığı senaryolarda doğrulayın.
Incident yanıtını temiz yürüten ekipler prova yapanlardır. Kill switch runbook'un parçasıdır. Sıkıcı hale getirin. Kill switch'i düzenli olarak prova etmek, tıpkı bir yangın tatbikatı gibi, gerçek bir acil durumda mekaniğin değil kararın ön planda olmasını sağlar. Sabah 3'te bilişsel yükü azaltan her şey iyidir.
Flag Borcu: Roadmap'e Konmayan Teknik Borç
Feature flag'leri agresif biçimde benimseyen ekipler çoğunlukla flag borcu biriktirir: amacını tamamlamış ama hiç kaldırılmamış flag'ler. Özellik yayınlandı, deney tamamlandı, beta sona erdi. Flag kaldı.
50 flag'de bu küçük bir sıkıntıdır. Dağıtık bir sistemdeki 500 flag'de ise aktif bir operasyonel risktir. Her flag, incident soruşturması sırasında bakım, test ve kavrama gerektiren bir kod dalıdır. Sabah 2'de bir arızayı anlamaya çalışan bir geliştirici, ilgili olanı bulmak için 40 koşullu daldan geçmek istemez.
Birden fazla platform ekibinde gözlemlenen bir örüntü: p99 gecikme için en üst beş stack frame arasında flag değerlendirme middleware'i. Çoğu durumda neden, istek başına düzinelerce koşulu değerlendiren eski flag'lerdir; iki yıl önce verilen ve kimsenin silmeye cesaret edemediği kararların ağırlığını taşırlar.
Karşı önlem teknikten çok organizasyoneldir. Oluşturulan her flag üç özelliğe sahip olmalıdır: bir sahip, bir tip (release, deney, ops, izin) ve beklenen kaldırma tarihi. Release flag'leri tam rollout'tan sonra iki sprint içinde kaldırılmalıdır. Deney flag'leri deney tamamlandığında kaldırılmalıdır, "birisi fırsat bulunca" değil. Flag envanteri talep üzerine denetlenebilir olmalı ve mühendislik sağlık dashboard'larında görünür olmalıdır.
Hedefleme Granülaritesi: Enterprise Ölçeğinde Çatlayan Boyut
Çoğu feature flag platformu yüzde tabanlı rollout'ları ve temel kullanıcı özelliği hedeflemeyi destekler. Enterprise ölçeğinde ortaya çıkan boşluk hedefleme granülaritesidir: rollout kurallarını hem yeterince spesifik hem de sürdürülebilir biçimde ifade etme yeteneği.
Platform ekibi düzeyinde prod rollout'lar için kullanışlı bir hedefleme hiyerarşisi:
Ortam düzeyi: prod, staging, preview. İlk kapı, tek kapı değil.
Altyapı segmenti: veri merkezi, availability zone ya da Kubernetes cluster'ı. Coğrafi blast radius'u izole etmek için kullanışlıdır.
Hesap ya da kiracı: B2B SaaS platformları için hesap bazında rollout, çoğunlukla kullanıcı yüzdesi bazında rollout'tan daha güvenlidir çünkü istatistiksel bir örneklem yerine tam bir hesabın trafik örüntüsünü gözlemleyebilirsiniz.
Kullanıcı kohortu: beta kullanıcıları, dahili kullanıcılar, aktivite katmanına göre güçlü kullanıcılar.
Oturum özelliği: deney flag'leri için kullanışlı, ops flag'leri için tehlikeli.
Bunu iyi uygulayan platformlar (ölçekte bunu yapan SRE ekiplerinin en çok atıfta bulunduğu LaunchDarkly ve Statsig), aktif rollout sırasında hedefleme mantığını değiştirmek için mühendislik zamanı gerektirmeden karmaşık kural bileşimlerine izin verir. Bu self-servis yetenek, 30 saniyelik rollout duraklaması ile platform ekibine açılan ticket arasındaki farktır.
Bunu kötü uygulayan platformlar hedefleme granülaritesi ile operasyonel basitlik arasında seçim yapmanızı zorunlu kılar. Bu ödünleşim sabah 3'te gün yüzüne çıkar.
Post-Mortem Her Seferinde Aynı Soruları Sorar
Özellikle ilgili her prod incident'ı için post-mortem aynı soru kümesini sorar. Özellik bir flag'in arkasında mıydı? Rollout aşamalı mıydı? Aşamalar arasında doğrulama koşulu var mıydı? Kill switch incident'tan önce test edilmiş miydi?
Dört yanıtın tamamı evet ise incident bir kalibrasyon sorunudur: çok gevşek ayarlanmış eşikler, uç durum içeren hedefleme kuralları, hesaba katılmamış network bölünmesi altında SDK değerlendirme davranışı. Bunlar yapılandırma değişiklikleri ve runbook güncellemeleriyle çözülebilir. AI destekli flag platformları, statik yüzde rollout'larına kıyasla rollout kaynaklı incident'larda %73 azalma gösteriyor. Bu rakam tek başına bir karar vermez; ancak SLO-gated yaklaşımın ölçülebilir etkisini görmek isteyenler için somut bir başlangıç noktasıdır.
Herhangi bir yanıt hayır ise incident bir mimari sorundur. Feature flag'ler bir hata ayıklama kolaylığı değildir. Bir deployment mimarisi kararıdır. Bu karar özellik prod'a çıkmadan önce ya vardır ya da hiç yoktur.
Bir sonraki release öncesinde yanıtlamaya değer soru: bu gece bir şeyler ters giderse post-mortem bu rollout hakkında ne söyler?