Feature Flag ile Risksiz Yayın: Kodunuzu Değil, Davranışını Deploy Edin

Neden “deploy” etmek yetmiyor?

Prod’a kod göndermek çoğu ekipte otomatik olarak “herkes kullanmaya başladı” anlamına geliyor. Oysa gerçek ihtiyaç şu: değişikliği kontrollü açmak, sorun çıkarsa anında kapatmak, ölçüm yaparak doğru kararı vermek.

Bu noktada feature flag (özellik bayrağı) devreye girer: Aynı kod, farklı kullanıcılara farklı davranır.

Feature flag ne kazandırır?

• Kademeli açılış (progressive rollout): %1 → %10 → %100
• Kill switch: Prod’da sorun varsa tek hamlede kapat
• Deney / A-B testi: İki akışı ölçerek seç
• Müşteriye özel özellik: “Enterprise plan” kullanıcılarına aç
• Operasyonel esneklik: Deploy penceresi ≠ özellik açma zamanı

Flag türleri (pratik sınıflandırma)

1. Release flags: Yeni özelliği güvenle açıp kapatmak için (kısa ömürlü olmalı).
2. Ops flags: Operasyonel anahtarlar (ör. “ödeme sağlayıcısını devre dışı bırak”).
3. Experiment flags: A/B veya çok kollu testler (ölçüm odaklı).
4. Permission flags: Plan/rol bazlı erişim (uzun ömürlü olabilir).

Basit bir örnek: “Yeni ödeme akışı”

Diyelim ki yeni bir checkout ekranı geliştirdiniz. Herkese bir anda açmak yerine:

// pseudo-code
const enabled = flag("new_checkout", { userId: user.id });

if (enabled) {
  renderNewCheckout();
} else {
  renderLegacyCheckout();
}

Bu kadar basit görünen şey, doğru tasarlanmazsa zamanla teknik borca dönüşür. Aşağıdaki prensipler bu yüzden önemli.

Üretimde güvenli kullanım için 6 kural

1) “Default kapalı” tasarla

Flag sistemi çökse bile en güvenli davranışa dön.

2) Flag’leri kod incelemesinin parçası yap

Her flag için şu sorular zorunlu olsun:

• Ne zaman kaldırılacak?
• Metrik ne?
• Kapatınca ne olur?

3) Flag yaşam döngüsü belirle (ve takvime bağla)

Release flag’ler sonsuz yaşamamalı. Jira/issue açıp “cleanup date” koy.

4) Ölçüm eklemeden deney yapma

A/B testte “tıklanma” yetmez. Örnek: checkout için conversion rate, fail rate, ortalama süre.

5) Segmentasyonu deterministik yap

Aynı kullanıcı her girişte farklı varyanta düşmemeli. Basit yaklaşım: hash(userId) % 100 < rolloutPercentage.

6) Kill switch gerçek kill switch olmalı

Yani:

• Yönetim panelinden 5 saniyede kapat
• Cache/TTL stratejisiyle hızlı yay
• Log ve alarm ile takip et

Sık yapılan hatalar

• Flag çöplüğü: Yıllarca kaldırılmayan koşullar
• Flag ile gizli migration: Veri modeli değiştiyse sadece UI’ı flag’lemek yetmez
• Yerel flag dosyası + prod paneli karmaşası: Tek “source of truth” olmalı
• Her şeyi flag’lemek: Her koşul flag değildir; kritik akışlara odaklan

Minimal bir mimari öneri

Küçük ekipler için bile ölçeklenen yaklaşım:

• Flag değerlendirme: Uygulama içinde küçük bir “FlagService”
• Konfigürasyon: Merkezi bir store (DB / config service)
• Dağıtım: CDN veya cache ile hızlı güncelleme (TTL 30–60 sn)
• İzleme: Flag bazlı metrik ve hata oranı dashboard’u

Son söz

Feature flag, “hızlı deploy”dan çok kontrollü değişim yönetimi aracıdır. Doğru kullanıldığında hem ürün ekibini hem operasyonu rahatlatır; yanlış kullanıldığında kod tabanına görünmez bir ağ gibi yayılır.

Bir sonraki özelliğinizde hedefiniz şu olsun: Kod prod’da dursun; açma-kapama kararı veriye ve riske göre yönetilsin.