Feature flag, kodu canlıya alıp özelliği kontrollü açmanızı sağlayan bir yayın kararıdır. Bu rehberde kademeli yayını, hedef kitle seçimini ve KOBİ ekiplerinin büyük sürüm günü riskini nasıl düşüreceğini adım adım ele alıyoruz.
Yazılım ekiplerinin en stresli anlarından biri büyük sürüm günüdür: her şey aynı anda açılır, hata çıkarsa geri almak zorlaşır. Feature flag nedir sorusu tam burada pratik bir cevaba dönüşür. Feature flag, kodu canlı ortama alıp özelliği henüz herkese göstermeden, kontrollü ve kademeli biçimde açma kararıdır.
Bu rehberde feature flag’i yalnızca aç-kapa düğmesi gibi değil; risk azaltma, kademeli yayın ve ekip disiplini aracı olarak ele alacağız. Amaç, küçük ve orta ölçekli ekiplerin “hepsini birden yayınla” baskısından çıkıp daha sakin bir yayın ritmi kurmasına yardımcı olmaktır.
Feature Flag Nedir?
Feature flag (özellik bayrağı), bir özelliğin davranışını kodu yeniden derleyip yeniden dağıtmadan yönetmenizi sağlayan bir kontrol noktasıdır. Kod canlıda olabilir; bayrak kapalıysa kullanıcı o özelliği görmez veya eski akış devam eder.
Basit bir örnek düşünün: sepete “hemen öde” butonu eklediniz. Butonun arkasındaki kod canlıya çıkmış olsa bile bayrak kapalıyken kimse o butonu görmez. Bayrağı önce iç ekibe, sonra yüzde 5 müşteriye, ardından daha geniş kitleye açarsınız. Sorun çıkarsa kodu geri çekmek yerine bayrağı kapatırsınız.
Bu yaklaşım özellikle şu senaryolarda değerlidir:
- Yeni ödeme veya sepet adımı gibi iş kritikliğinde yüksek değişiklikler
- Tasarım veya metin denemeleri
- Belirli müşteri segmentlerine özel özellikler
- Altyapı geçişleri (eski ve yeni servisin yan yana çalışması)
KepezWeb gibi ekiplerde özel yazılım projelerinde feature flag, “yayın = herkese açık” varsayımını bozar. Yayın, kodun canlıya girmesidir; özellik açılışı ise ayrı bir iş kararıdır.
Büyük Sürüm Günü Riski Neden Büyür?
KOBİ ekiplerinde risk çoğu zaman teknik yetersizlikten değil, aynı anda çok fazla değişkeni bir arada denemekten büyür. Tek seferde arayüz, iş kuralı, entegrasyon ve veri migrasyonu birleşince hata kaynağını bulmak zorlaşır.
Tipik risk zinciri şöyledir:
- Geliştirme uzun sürer, özellik “biriktirilir”.
- Test ortamı gerçek trafik ve gerçek veriyi yeterince yansıtmaz.
- Canlıya çıkışta her şey birden açılır.
- Sorun çıkınca geri alma (rollback) hem yavaş hem maliyetli olur.
Feature flag bu zinciri kırmaz ama boğum noktasını değiştirir: kod canlıya girebilir, özellik ise dar kapsamda doğrulanır. Böylece “sürüm günü” yerine “kontrollü açılış” disiplini gelir.
Feature Flag ile Kademeli Yayın Mantığı
Kademeli yayın, özelliği önce küçük ve güvenli bir gruba, sonra adım adım daha geniş kitleye açmaktır. Amaç, hata etkisini sınırlamak ve erken sinyal toplamaktır.
Yaygın açılış basamakları
- İç ekip / personel: Yalnızca çalışan hesapları görür.
- Beta müşteriler: Gönüllü veya seçilmiş küçük bir grup.
- Yüzdelik canary: Trafiğin küçük bir yüzdesi yeni davranışı alır.
- Segment açılışı: Belirli şehir, plan, kanal veya hesap tipi.
- Tam açılış: Bayrak kalıcı hale gelir veya kod sadeleştirilir.
Her basamakta bakılacak şeyler sabittir: hata oranı, dönüşüm veya kritik iş metrikleri, destek talepleri ve operasyon yükü. Metrik bozulursa bayrak kapanır; sorun büyütülmez.
Bu model, “büyük bang” yayınından daha yavaş görünür. Pratikte ise geri alma süresi kısaldığı için toplam risk ve panik maliyeti düşer.
Feature Flag Türleri ve Ne Zaman Kullanılır?
Tüm bayraklar aynı değildir. Yanlış tür seçmek teknik borç üretir. Aşağıdaki sınıflandırma KOBİ ekipleri için yeterince sadedir.
| Tür | Amaç | Ömür | Örnek |
|---|---|---|---|
| Yayın bayrağı | Kodu canlıya alıp özelliği sonradan açmak | Kısa | Yeni checkout adımı |
| Deney bayrağı | A/B veya varyant karşılaştırması | Kısa-orta | İki farklı CTA metni |
| Operasyon bayrağı | Acil kapatma / kill switch | Orta | Üçüncü parti servisi devre dışı bırakma |
| İzin / paket bayrağı | Plan veya rol bazlı erişim | Uzun | Premium rapor ekranı |
Yayın ve deney bayrakları işi bitince temizlenmelidir. İzin bayrakları ise ürün modelinin parçası olabilir; yine de isimlendirme ve sahiplik net olmalıdır.
Rol ve yetki ile entegre bayrak kullanıyorsanız kimlik katmanının da tutarlı olması gerekir. Oturum, rol ve erişim kontrolü için yazılım kimlik doğrulama ve yetkilendirme rehberine bakabilirsiniz.
KOBİ Ekipleri İçin Uygulama Adımları
Kurumsal araç setine ihtiyaç duymadan da disiplin kurulabilir. Önemli olan bayrak altyapısından önce karar ve sahiplik modelidir.
1. Hangi özelliğin bayrak alacağını seçin
Her satıra bayrak koymayın. Riski, geri alınamazlığı veya iş etkisi yüksek olan değişikliklere odaklanın. Basit metin düzeltmesi veya düşük etkili arayüz iyileştirmesi için bayrak çoğu zaman gereksizdir.
2. Açılış kriterlerini yazın
Bayrak açılmadan önce netleştirin:
- Kimler görecek? (iç ekip, yüzde, segment)
- Hangi metrik “sorun” sayılacak?
- Kim kapatma yetkisine sahip?
- Ne zaman tam açılış veya temizlik yapılacak?
3. Varsayılanı güvenli tutun
Bayrak kapalıyken sistem eski, bilinen davranışta kalmalıdır. “Kapalıyken de yeni kodun yan etkileri çalışıyor” durumu en tehlikeli senaryolardan biridir.
4. Gözlem penceresi tanımlayın
Her basamakta en az bir gözlem süresi bırakın. Süre işin doğasına göre değişir; önemli olan “açtık, hemen genişlettik” alışkanlığını kırmaktır. Log, hata takibi ve destek kanalı bu pencerede aktif izlenir.
5. Temizlik planı koyun
Kalıcı hale gelen bayraklar kodu karmaşıklaştırır. Tam açılış sonrası bayrağı kaldırmak, koşullu dalları sadeleştirmek ve testleri güncellemek işin parçasıdır. Bayrak listesi “mezarlık” haline gelmemelidir.
Özel yazılım geliştiren ekipler bu adımları sprint ritmine bağlayabilir. KepezWeb’in yazılım geliştirme yaklaşımında da yayın ve özellik açılışının ayrı düşünülmesi, kabul ve devreye alma riskini azaltır.
Teknik Uygulamada Dikkat Edilecekler
Feature flag’in değeri, kodun her yerinde dağınık if yığınından gelmez. Temiz bir kontrol noktası, okunabilir isimlendirme ve test edilebilirlik gerekir.
İsimlendirme ve sahiplik
Bayrak adları niyeti anlatmalıdır. new_thing_v2_final yerine checkout_express_pay_enabled gibi anlaşılır isimler tercih edin. Her bayrağın bir sahibi (ürün veya teknik) ve beklenen bitiş tarihi olsun.
Sunucu tarafı mı, istemci tarafı mı?
Kritik iş kuralları istemciye güvenilerek yönetilmemelidir. Fiyat, yetki, stok rezervasyonu gibi kararlar sunucu tarafında doğrulanmalıdır. Arayüzde gizlenen bir buton, API’nin de aynı kuralı uyguladığı anlamına gelmez.
Veri ve geriye uyumluluk
Yeni özellik yeni veri alanları üretiyorsa eski kodun bu veriyle bozulmaması gerekir. Bayrak açıkken yazılan kayıtlar, bayrak kapandığında da okunabilir ve güvenli kalmalıdır. Aksi halde “kapatınca düzelir” varsayımı çalışmaz.
Test stratejisi
Bayraklı kod en az iki yolu test eder: bayrak açık ve kapalı. Ayrıca geçiş anı (açılış/kapanış) senaryoları da kontrol edilmelidir. Kabul testlerinde iş biriminin hangi bayrak durumunda ne göreceği açık yazılmalıdır.
Özel PHP/MySQL tabanlı uygulamalarda bayrak değerlerini yapılandırma tablosu veya güvenli bir config katmanında tutmak yaygındır. Bu tür sistemlerde özel PHP/MySQL yazılım mimarisinde bayrak okuma maliyetinin her istekte gereksiz yük yaratmamasına dikkat edilmelidir.
Yaygın Hatalar ve Nasıl Kaçınılır?
Feature flag risk azaltır; disiplinsiz kullanılırsa yeni risk üretir. Sık görülen hatalar şunlardır:
- Bayrak enflasyonu: Her küçük değişiklik için bayrak açmak kodu okunmaz hale getirir.
- Temizlik erteleme: Aylar önce açılmış bayraklar hâlâ kodda durur.
- Gizli bağımlılık: Bir bayrak başka bir bayrağa bağlıdır; kimse haritayı bilmez.
- Yetkisiz açılış: Canlıda kimlerin bayrak değiştirebildiği net değildir.
- Ölçümsüz genişletme: İlk basamak izlenmeden yüzde artar.
Basit bir yönetim listesi bile işe yarar: bayrak adı, amaç, sahip, açılış durumu, hedef kitle, temizlik tarihi. Bu liste ürün ve geliştirme arasında ortak dil oluşturur.
Feature Flag, Feature Toggle ve Remote Config
Terimler bazen birbirinin yerine kullanılır. Pratik ayrım şöyledir:
- Feature flag / toggle: Genelde aynı aileyi ifade eder; özelliğin açık/kapalı veya varyantlı kontrolü.
- Remote config: Daha çok parametre ve yapılandırma değerlerini uzaktan yönetmeye odaklanır (metin, eşik, oran).
KOBİ ekibi için isim tartışmasından çok şu soru önemlidir: “Bu kontrol, yayın riskini azaltmak için mi var, yoksa kalıcı ürün kuralı mı?” Cevap netse araç seçimi de netleşir.
Ne Zaman Feature Flag Kullanmayın?
Her probleme bayrak eklemek doğru değildir. Aşağıdaki durumlarda doğrudan, sade bir yayın daha sağlıklıdır:
- Değişiklik düşük etkili ve kolay geri alınabilir
- Bayrak yolu test ve bakım maliyetini gereksiz şişiriyor
- Veri modeli geri dönüşsüz biçimde değişiyor ve bayrak tek başına koruyamıyor
- Ekip bayrak temizliğini düzenli yapamıyor
Ayrıca güvenlik yaması gibi herkese hemen gitmesi gereken düzeltmelerde kademeli açılış çoğu zaman uygun değildir. Öncelik, risk türüne göre seçilir.
Sıkça Sorulan Sorular
Feature flag nedir, kısaca nasıl tanımlanır?
Feature flag, canlıdaki bir özelliğin görünürlüğünü veya davranışını kodu yeniden dağıtmadan yönetmenizi sağlayan kontrol mekanizmasıdır. Kod canlıya girebilir; özellik açılışı ayrı ve kontrollü yapılır.
Küçük ekipler için feature flag abartılı mı?
Hayır, doğru yerde kullanıldığında abartılı değildir. Her özelliğe değil; iş etkisi yüksek, geri alması pahalı veya kademeli doğrulama isteyen değişikliklere uygulanmalıdır. Küçük ekipte sade isimlendirme ve temizlik disiplini yeterlidir.
Feature flag ile A/B test aynı şey midir?
Değildir. Feature flag altyapısı A/B testini mümkün kılabilir; ancak A/B test, hipotez, örneklem ve ölçüm gerektiren ayrı bir deney sürecidir. Her bayrak bir deney değildir; her deney de mutlaka uzun ömürlü bir bayrak gerektirmez.
Bayrak kapatmak her zaman güvenli midir?
Ancak varsayılan yol eski, bilinen ve tutarlı davranışı koruyorsa güvenlidir. Yeni veri yazımı, yan etkiler veya geriye uyumsuz şema değişiklikleri varsa bayrağı kapatmak sorunu çözmeyebilir. Bu yüzden tasarım aşamasında kapanış senaryosu da düşünülmelidir.
Feature flag teknik borcu artırır mı?
Kontrolsüz çoğalır ve temizlenmezse artırır. Sahiplik, bitiş tarihi ve düzenli temizlik varsa borç kontrol altında kalır. Bayrak, geçici bir yayın aracıysa kalıcı mimari parçası gibi muamele görmemelidir.
Feature flag’i doğru kurmak; daha sakin yayınlar, daha hızlı geri çekilme ve daha net ekip kararları demektir. Yeni bir özellik için kademeli yayın planı, bayrak modeli veya özel yazılım mimarisi üzerine konuşmak isterseniz KepezWeb teklif al sayfasından projenizi kısaca paylaşabilirsiniz. Birlikte hangi değişikliklerin bayrak gerektirdiğini ve hangilerinin sade yayınla yönetileceğini netleştirebiliriz.
