Feature Flag Nedir? Yazılımda Koşullu Kontroller Rehberi

Feature Flag Nedir? Yazılım Geliştirmede Koşullu Kontroller Rehberi

Feature flag (özellik bayrağı), yazılımda çalışma zamanında belirli bir özelliği açıp kapatmaya yarayan bir koşullu kapatıcıdır. Kodun temelini değiştirmeden ve yeni bir dağıtım yapmadan özelliği canlıya alabilir veya kapatabilirsiniz. Mühendislik ekibiniz kodu gönderse de, flag hangisinin gösterileceğine karar verir. Eğer bir sprintle değerlendirme toplantısında "bu özelliği bir flag arkasında başlatıyoruz" sözünü duydum iseniz, şimdi tam anlamını biliyorsunuz.

Şirketler ve teknoloji ekipleri bu kavramla her gün karşılaşırlar: ürün başlatımları, olay raporları, A/B test sonuçları ve sürüm notları hep flaglar hakkında konuşulur. Bir flagın ne olduğunu ve hangi durumda olduğunu hızlı anlamak, bu tarz konuşmalarda sizin değerinizi arttırır. İş hayatında bu konunun ne kadar merkezi olduğunu görmek sizi şaşırtabilir.

Feature flag aslında yazılım ekiplerinin ölçekte kullandığı bir IF komutu

Özündeki, feature flag bir IF ifadesidir. Excel'de =IF(A2="AÇIK","Özelliği Göster","Gizle") şeklinde yazarsınız. Yazılım kodunda flag aynı şeyi yapar: flag doğru ise bu kod yolu çalışsın, değilse atla ve yedek kodu çalıştır.

Fark ölçek ve bağlamda yatıyor. Üretim ortamındaki bir flag saniyede milyonlar kez hesaplanıyor, her aktif kullanıcı oturumu genelinde, belirli kullanıcıları, coğrafyaları, cihaz türlerini veya yüzde dilimlerini hedefleyebilen mantıkla. Temeldeki kavram spreadsheet'te kullandığınız şeyle tamamen aynıdır.

Örnek verecek olursak; çok büyük bir e-ticaret şirketinde yeni bir ödeme sistemi geliştiriliyor. Hiçbir flag olmaysa kodlar tamamen değiştirilir ve tüm kullanıcılara yayılır. Ancak flag ile yeni sistem sadece %5'i görecek şekilde başlar, sorun yok ise %25'e, sonra %100'e çıkılır. Sorun olursa flag kapanır ve eski sistem devreye girer. Bu yapı riski muazzam şekilde azaltır.

Bu tesadüfi değildir. Feature flaglar tam da bu yüzden resmiyet kazanmıştır: geliştiriciler aynı toggle mantığını defalarca, her bir kod tabanında yazıyorlardı. Bu desen özel kütüphanelere ve platformlara dönüştürüldü. IF ifadesi büyüdü.

Yazında karşılaşacağınız dört tür feature flag

Feature flag'lar dört kategoriye ayrılır. Birisi hangi türden bahsettiğini bilmek konuşmayı değiştirir ve çalışmada hatalı kararları engeller.

Yayın flagları (Release flags) yeni bir özelliğin kullanıcılara görünüp görünmediğini kontrol eder. Tasarım itibariyle geçicidir: özellik stabil ve tamamen yayıldıktan sonra flag silinir. "Yeni ödeme akışı flagın arkasında" demek kodlanmış ve test edilmiş ama henüz kamuya açık olmadığı anlamına gelir. Ekip yayın anını dağıtım anından bağımsız olarak kontrol edebilir. Pazartesi sabahı kodu gönderilebilir, ancak flag çarşamba açılabilir. Bu esneklik ürünü kontrol etmek için çok değerlidir.

Deney flagları (Experiment flags) A/B testleri güçlendirir. Kullanıcıların bir yüzdesi A versiyonunu, geri kalanları B versiyonunu görür ve analitik araçları davranışsal farkı ölçer. Bu flaglar ürün kararı kesinleşmeden veri üretir ve "hangi versiyon daha iyi" tahmini kaçınır. Böylece hatalı kararlardan uzak durulur ve sonuç veri tarafından yönlendirilir.

İşletme flagları (Ops flags) acil durum kesme anahtarlarıdır. Varsayılan olarak AÇIK durumda kalırlar ve üretimde bir şey yanlış giderse, bir mühendis flagı KAPAT konumuna çekerek özelliği anında devre dışı bırakır, yeni bir dağıtım beklenmeden. Olay yanıt süresi 45 dakikadan 2 dakika altına düşer. LaunchDarkly dokümantasyonuna göre, bu tip flaglar incident yanıt süresini önemli ölçüde kısaltmıştır. Ciddi bir üretim sistemi bunlardan en az birkaçına sahip olmalıdır.

İzin flagları (Permission flags) özellikleri kullanıcı seviyesi, hesap türü, bölge veya başka herhangi bir öznitelik temelinde engeller. Premium kullanıcılar gelişmiş raporlama panosunu görürler; ücretsiz kullanıcılar görmezler. Müşteri planını yükseltirse, bir sonraki oturum açışında flag farklı değerlendirilir. Kod değişikliği gerekli değildir. Bu tarz flaglar müşteri yaşam döngüsü yönetiminde merkezi bir rol oynar.

Neden operasyon, analitik ve ürün ekipleri feature flaglara önem veriyor

Bu flaglar sadece yazılımcılar için değildir. Operasyon ekipleri, analitik uzmanları ve ürün müdürleri her gün onlarla beraber düşünürler. Hepsi farklı perspektiften bu yapıyı kütür ve gereksinim duyarlar.

Operasyon perspektifi: Olay (incident) yaşandığında, bir flag acı kurtarabilir. Eğer yeni özellik veya kod değişikliği sorun yaratıyorsa, mühendis flagı kapatır. Sistem söyle-yolla dağıtım sürecini atlar. 45 dakikalık olay tepkisi şimdi 2 dakika olabilir. Trafiği kademeli olarak yayabilir, yeni özelliğin yalnızca %5'ini göreceği şekilde başlayıp %100'e çıkabilir. Böylece riskler kontrol altında tutulur.

Analitik perspektifi: Bir metrik düşüp yükselirse, analitikçi flag durumunu kontrol eder. Belirli bir flag açıldığında sayılar değişti mi? O zaman sebep bulunmuş. Flaglar anomali teşhisinde çok değerlidir. Operasyon ekibine de yardımcı olur; bir sorunda "hangi flag bu soruna yol açabilir" sorusu hızlı cevap bulur.

Ürün perspektifi: Bir ürün müdürü başlatmak istediği yeni özelliği, flag arkasında göndertebilir. Müşteri geribildirim alabilir, ölçer, ayarlar. Herhangi bir koda dokunmadan veya yeni dağıtım yapmadan, piyasada hızla iyileştirebilir. Bu çapraz işlevli çalışmayı daha etkin hale getirir.

Raporlarınızda feature flag durumu nasıl görünür

Çoğu analitik platform flag durumunu event data'sında taşır. Bunu bir spreadsheet'te izleyebilir ve olay seçtiklerini kayıt altına alabilirsiniz. Bu önemli bir disiplin; aksi takdirde flag tarihleri karışabilir.

Google Analytics, Mixpanel veya Amplitude kullanıyorsanız, flagların bu event data'ya eklenmesi önemlidir. Örneğin:

Event: "Yeni_Checkout_Tamamlandı"
Flag: "yeni_ödeme_akışı" = AÇIK
Değer: 45€

Bu sayede raporlarınız açık olan flagları gösterir. Karşılaştırmalar yapabilir, "bu flagı kapattığımızda sayılar değişti mi?" diye sorabilisiniz. Bir ay sonra geri dönüp "aslında bu flag neydi" diye sorabilirsiniz ve veri o soruyu cevaplandırır.

Basit Excel veya Google Sheets'te bir feature flag izleyici nasıl yapılır

Bir spreadsheet'te flagları izlemek oldukça pratiktir. Temel yapı böyle bir şey olabilir:

Daha karmaşık takip için şunları ekleyebilirsiniz:

• =IF(C2="AÇIK","🟢","🔴"): görsel durum göstergesi

• =FILTER(): sadece belirli tarihten sonraki flagları göster

• Özet tablo: haftada kaç flag açık/kapalı olduğunu özetler

• Koşullu biçimlendirme: AÇIK flagları yeşil, KAPAL olanları kırmızı gösterir

Bu basit görünüp operasyon ekibinize zaman kazandırır. Yeni bir platform kullanmadan flag değişikliklerini takip edebilirsiniz. Hatta Sheets'te paylaşım yapabilir, ekip reel-zamanda güncelleme yapabilir.

Flag mantığının merkezindeki IF formül deseni

IF formülü feature flag'ların temelini oluşturur. Excel örneğinde:

=IF(A2="AÇIK", "Özelliği Göster", "Gizle")

Bunu yazılım dilinde şöyle görünür:

if (flag.isEnabled("yeni_ödeme_akışı")) {
  // Yeni özelliği çalıştır
  processNewCheckout();
} else {
  // Eski kodu çalıştır
  processOldCheckout();
}

Her ikisi de aynı düşünme şeklidir. Condition, true yolu, false yolu. Spreadsheet'te "A sütunu AÇIK ise X göster, değilse Y göster" yazarken yazılımcılar "flag açık ise bu kod çalışsın, kapalı ise şu kod çalışsın" yazarlar.

Spreadsheet'teki formülün ünü değiştirebilir, kaydetmek kadar kolaydır. Yazılım flagında ise değişiklik yapılması biraz daha planlanmış bir işlemdir:flag yönetim platformu kullanılır, test edilir, sonra değiştirilir. Ama mantık aynıdır. Üretimde aynı anda 30 ile 60 arasında aktif flag çalışabilir; bu düzeni sağlamak yazılım ekiplerinin standart uygulaması olmuştur.

Spreadsheet ne zaman yeterli ve ne zaman platform gerekir

Küçük operasyon ekipleri için spreadsheet başlangıçta gayet iyi çalışabilir. İçi özel kütüphaneler ve bağımlılıklar olmayan, sadece izlem amaçlı flagları takip etmek için birkaç Excel satırı yeterlidir. Taraflar rahatlıkla müdür ve kapatabilir.

Fakat yazılım ekibiniz çağa girebilir:

• Şirketin 10+ özelliği seğerek yayabilir

• A/B testler düzenli olarak koşar

• Acil durumlarda flagları hızlı kapatmak gerekir

• Yüzde dilimlerine göre hedeflemesi (rollout %) önemlidir

• Coğrafyaya göre hedefleme lazım (Türkiye bölgesinde test etmek)

Bu durumda LaunchDarkly, Unleash, Split.io veya CloudBees Feature Management gibi adanmış platformlar devreye girer. Bunlar:

• Gerçek zamanlı flag yönetimi

• Kullanıcıya göre hedefleme (cohort)

• Analytics entegrasyonu

• Rollout işlemleri otomatik olarak (canary, blue-green)

• Denetim ve güvenlik

• Çoklu dil desteği

Yazılımcılar feature flaglara yanında hangi araçları kullanıyor

Feature flag yalnız başına değildir. Ürün ekipleri çoğu zaman bunları diğer araçlarla birleştirirler. Bu kombinasyon ekiplerin daha hızlı ve daha verimli çalışmasını sağlar.

A/B test platformları (Optimizely, VWO): Flagları kontrol eder, varyasyon gösterir, istatistiksel önem hesaplar. Sonuçlar otomatik raporlanır.

Analitik araçları (Segment, mParticle): Flag durumunu event data'ya bağlar, soru sormayı kolaylaştırır ("yeni flag açık olduğunda ne değişti?"). Veri akışı merkezileştirilir.

Incident management (PagerDuty, Opsgenie): Acil durumda flag kapatma işlemini tetikler. Escalation otomatik. Takım anında haberdar olur.

Bu araçlar önceden plan yapmaları sağlar. Operasyon ve ürün bir arada çalışabilir. Bağlantılar sağlamlaştırılırsa sistem güçlü olur.

Flag hataları raporlama sorunlarına nasıl yol açar

En yaygın hata: flagın durumunu analitik data'ya kaydetmeyi unutmaktır. Bu da çoğu zaman en sonra ortaya çıkar, en zararlı olur.

Örnek senaryo:

1. "yeni_ödeme_akışı" flagı açılıyor

2. Ödeme tamamlama oranı düşüyor

3. Ekip "neden?" diye soruyor

4. Analitik data'da flag durumu yok çünkü kayıt yapılmamış

5. "Flag mı sebep? Başka bir kod değişikliği mi? Bilemiyoruz."

Sonuç: 3 saat sorun giderme, kapanması 2 dakika sürüyor. Zaman ve kaynaklar boşa harcanmış olur.

Başka bir hata: flagın neyi kontrol ettiğini belgelenemez bırakmak. "flag_456" neyin özelliğini açıyor? Kimse bilmiyor. Bu bir ay sonra başka bir ekibe zor olur. Ya da olay çıkınca flag kapatılır ama neyin kırıldığı bilinmez.

Bunu önlemek basittir:

• Tüm flagları bir belge ve spreadsheet'te listeleyin

• Her flagın amacını yazın (başlatım, deney, acil durum, izin)

• Flag kapatıldığında temizleyin (silin, yorum yapın)

• Event data'ya flag durumunu her zaman ekleyin

• Flag sorumlusunu belirleyin (kimin kapatabileceğini bilin)

Özet

Feature flag'lar yazılım geliştirmenin temel bir parçasıdır. Teknoloji ekibi ve operasyon ekibi arasında köprü gibidir. Bir olay çıktığında flagı kapatıp kodu başlangıç noktasına çekebilir, yeni bir sürüm beklemeye gerek kalmaz. A/B testte hangi versiyonun daha iyi olduğunu bilirim. Yeni özelliği gradual olarak yayabilirim.

Sizin operasyon veya analitik tarafında çalışıyor olsanız da, bu yapıyı anlamak önemlidir. Mühendislerle konuşurken, olay çözüm sürelerinde, metrikleri yorumlarken bu bilgi yer tutar. Feature flag geliştiricilerin günlük dilinin bir parçası; onu anlamakla işleriniz kolaylaşır.

Sık Sorulan Sorular

S: Feature flag kod tabanında kalıcı bir şey midir? C: Hayır. Release flagları geçicidir:özellik tamamen yayıldıktan sonra kod tabanından kaldırılır. Experiment flagları testler bitse kaldırılır. Ops ve izin flagları daha uzun kalabilir ama yine de temizlenirler. İyi yapılan bir kod tabanında eski flaglar hiç bulunmaz.

S: Feature flag platformu kurmak zor mu? C: Küçük operasyon ekipleri için spreadsheet ile başlamak gayet iyi. Şirket büyüdükçe LaunchDarkly veya Unleash gibi bir platform kurmak 1–2 hafta surur. Entegrasyon kütüphaneleri standartlaşmış. API dokümantasyonu açık ve örneklidir.

S: Feature flaglar AWS, Azure ya da Google Cloud'da işler mi? C: Evet. Tüm bulut sağlayıcıları feature flag desteği sunmuştur. AWS CodeDeploy, Azure DevOps, Google Cloud Deploy'un tümü bunu yapar. Bağımsız platformlar (LaunchDarkly, Unleash) tüm bulutlarda çalışır. Yazılım ekibiniz hangi buluta bağlı olsa feature flag kurabilir.