tolgacelik.net
Tüm yazılar
·3 dk

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-flagsdeploymentproductionrelease-management

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.

PaylaşLinkedInX
Bir sonraki yazı doğrudan kutuna düşsün

Distributed sistemler, üretim stabilitesi, AI destekli geliştirme üzerine uzun yazılar. Spam yok, çıkmak kolay.

Sadece e-posta. Bu sunucuda saklanır. Hiçbir yerde paylaşılmaz, satılmaz.

Yorumlar

Henüz yorum yok. İlk yorumu sen bırak.

Yorum bırak

Hiçbir yerde gösterilmez. Sadece gerekirse cevap vermek için.