Feature Flag'ler: Üretimde Gerçek Pratik
Feature flag'ler kulağa basit gelir — "on/off switch". Pratikte yanlış kullanılırsa kod tabanını yıllık zombi kodla doldurur. 6 yıllık üretim deneyiminden ne işe yararlar, ne yaramazlar.
Feature flag, bir kod parçasını runtime'da açıp kapatmanı sağlar. Deploy etmeden özellik aktive et / deaktive et / belirli kullanıcılara göster — kulağa harika geliyor. Genelde de harika, ama sadece doğru disiplinle kullandığında.
Yanlış kullanımı, bir kod tabanını 6 ayda kullanılamaz hâle getirebilir. Aşağıda öğrendiklerim.
Feature flag ne zaman gerçekten faydalı
Üç senaryo:
1. Riskli değişikliği aşamalı açmak. Yeni ödeme algoritması yazdın. Deploy ettin, ama henüz hiçbir kullanıcıya açık değil. Önce %5 kullanıcıya aç. İncele, metric'lere bak. İyi gidiyorsa %25, sonra %50, sonra %100. Kötü gidiyorsa flag'i kapat — kod hâlâ deploy'da, sadece off. Rollback'tan çok daha hızlı.
2. Ürün tarafının deneyi. İki farklı UX akışı denemek istiyorlar. A/B test. Yarısına flow A, yarısına flow B. Hangisinin conversion'ı daha iyi, ölç. Karar ver.
3. Acil kapatma. Production'da bir özellik sorun çıkardı, hemen kapatmak gerek. Deploy yapmaya zaman yok. Flag'i kapat, dur. Sonradan rahatça düzelt.
Bu üçü için flag çok değerli. Bunlar dışında dikkatli olmak lazım.
Feature flag ne zaman tuzak
Flag eklemek kolay. Çıkarmak zor. Bir flag eklediğinde, kod tabanına iki branch eklemiş oluyorsun: flag-on ve flag-off. Her birinin testi, her birinin bakımı, her birinin gelecekteki etkileşimi.
Üç flag → 8 kombinasyon. Beş flag → 32 kombinasyon. Test surface alanı patlar.
Tuzaklar:
- "Geçici" flag bir sene kalır. "Bir hafta canary çalışsın, sonra çıkarırız" — sonra ekip başka şeylere geçer, flag unutulur. 6 ay sonra hiç kimse o flag'in ne işe yaradığını bilmez.
- Flag'lerin birbirine bağımlılığı. Flag A açık değilse, Flag B'nin davranışı bambaşka. Bu tip implicit bağımlılıklar code review'da görünmez, üretimde patlar.
- Flag kombinasyonlarına test yazılmaz. Flag-on için test, flag-off için test. Birbirleriyle etkileşim için yok.
Üretim disiplini
Bizde 6 yıl içinde olgunlaşan kurallar:
Her flag'in son kullanma tarihi vardır
Flag oluştururken JIRA'da bir ticket aç: "Bu flag'i kaldır, son tarih: 2026-06-01". Sahibi sen. Tarih geldiğinde fla'i kaldırmak senin işin.
Flag kalkmadıysa: ya kalıcı kararı verilir (artık özellik var, herkes açık), ya kapatılır (özellik istenmedi). İkinci durumda kod ile birlikte gider. "Yarın lazım olur" diye kod tutmak — bu zombi kod yaratır.
Per-environment değil, per-user
Flag dev'de açık, staging'de kapalı, production'da yarı yarıya — bu yapıyı build etme. Flag bir runtime karar olmalı, environment değil. Aksi halde "staging'de çalışıyor, prod'da çalışmıyor" pattern'ine girersin.
Per-user (veya per-tenant) targeting: flag açık ise hangi kriterleyle açık (yeni kullanıcılar mı, beta grubu mu, %5 random mı). Bu net olmalı.
Flag isimlendirmesi
İyi: new_payment_algorithm_v2, enable_voice_chat, experimental_matchmaking_v3
Kötü: flag1, temp_thing, feature_x
Flag isminden ne yaptığı anlaşılmalı. 6 ay sonra başka biri o flag'i görüp anında ne olduğunu bilmeli.
Code path'leri minimum tut
Flag'i fonksiyon başında bir kez kontrol et, sonra branch'la. Flag'i 10 farklı yerde kontrol etme — kombinasyonlar patlar.
# İyi
def process_payment(payment):
if not feature_flag('new_algorithm'):
return process_payment_legacy(payment)
return process_payment_new(payment)
# Kötü
def process_payment(payment):
validate(payment)
if feature_flag('new_algorithm'):
do_thing_a()
do_common()
if feature_flag('new_algorithm'):
do_thing_b()
finalize()
İkincisinde "yarısı yeni, yarısı eski" davranışları olur.
Hangi araç
İki seçim var:
Üçüncü taraf (LaunchDarkly, Flagsmith, Unleash): hızlı kurulum, güçlü UI, evaluation logging. Pahalı (LaunchDarkly özellikle, kullanıcı başına aylık ücret). Avantajı: yatırılmış, kanıtlanmış.
Kendi yapımızı: bizde basit bir Redis-backed sistem. Flag'ler key-value pair olarak Redis'te, panel admin tarafından güncellenir. Targeting kuralları kod içinde. Maliyetsiz ama kendi tooling'i tutmak gerek.
Küçük ekipte kendi yapım. Büyük ekipte LaunchDarkly. Sınır net değil, ama ekibinin kapasitesine göre.
Sonuç
Feature flag'ler güçlü ama karmaşıklık biriktirir. Disiplinli kullanılırsa hızlandırır; disiplinsiz kullanılırsa felaket.
Eklediğin her flag'in son kullanma tarihi olsun. Tarih geçtiğinde flag'i kaldır. Bu tek kural seni 6 ay sonra "flag kabusumuz var" şikayetinden korur.
Flag'ler özellikleri release etmek için araç, kod tabanını saklama yeri değil.
Distributed sistemler, üretim stabilitesi, AI destekli geliştirme üzerine uzun yazılar. Spam yok, çıkmak kolay.
Yorumlar
Henüz yorum yok. İlk yorumu sen bırak.