Feature Flag Yonetimi ve Progressive Delivery Rehberi [2026]

Feature Flag Nedir ve Neden Onemlidir?

Yazilim gelistirme sureclerinde en buyuk risklerden biri, yeni ozelliklerin production ortamina tasinmasi sirasinda yasanan beklenmedik sorunlardir. Feature flag (ozellik bayraklari), kod icerisinde belirli islevlerin calisma zamaninda acilip kapatilmasini saglayan yapilandirma mekanizmalaridir. Bu yaklasim, deployment ile release kavramlarini birbirinden ayirarak ekiplere benzersiz bir esneklik sunar.

Geleneksel yaklasimda yeni bir ozellik gelistirilir, test edilir ve ardından production ortamina deploy edilir. Feature flag kullanildiginda ise ozellik deploy edilmis olsa bile kullanicilara gosterilip gosterilmeyecegi tamamen flag durumuna baglidir. Bu ayrım, yazilim teslimat surecini koklü bir sekilde donusturur.

Feature flag kullaniminin temel avantajlari sunlardir: risksiz deployment, kademeli kullanici yayilimi, anlik geri alma (rollback) yetkinligi, A/B test altyapisi ve operasyonel kontrol mekanizmalari.

Feature Flag Turleri

Feature flag'ler kullanim amacina gore dort temel kategoriye ayrilir. Her kategorinin yasam dongusu, yonetim gereksinimleri ve teknik borç riski farklidir.

Release Flags

Release flag'ler en yaygin kullanilan tur olup yeni ozelliklerin kademeli olarak acilmasini saglar. Genellikle gecici yapidadirlar ve ozellik tamamen yayinlandiktan sonra koddan kaldirilmalari gerekir.

// Release flag ornegi
const showNewDashboard = featureFlags.isEnabled('new-dashboard-v2', {
  userId: currentUser.id,
  percentage: 25 // Kullanicilarin %25'ine ac
});

if (showNewDashboard) {
  renderNewDashboard();
} else {
  renderLegacyDashboard();
}

Experiment Flags

A/B testleri ve cok varyantli deneyleri yurutmek icin kullanilir. Kullanici segmentlerine farkli deneyimler sunarak veri odakli kararlar alinmasini saglar.

Ops Flags (Operational Flags)

Sistem davranisini operasyonel duzeyde kontrol eden bayraklardir. Performans sorunlarinda belirli ozellikleri devre disi birakma, kaynak tuketimini azaltma veya bakim moduna gecis gibi senaryolarda kullanilir.

Permission Flags

Belirli kullanici gruplarina ozel erisim yetkilendirmesi saglayan uzun omurlu bayraklardir. Premium ozellikler, beta programlari veya kurumsal lisanslama senaryolarinda tercih edilir.

Flag Turu	Yasam Suresi	Degisim Sikligi	Teknik Borc Riski
Release	Kisa (gunler-haftalar)	Dusuk	Yuksek (kaldirilmazsa)
Experiment	Orta (haftalar-aylar)	Orta	Orta
Ops	Uzun (surekli)	Nadir	Dusuk
Permission	Uzun (surekli)	Nadir	Dusuk

Progressive Delivery Stratejileri

Progressive delivery, yazilimi kademeli olarak artan kullanici gruplarina sunma yaklasimini ifade eder. Feature flag'ler bu stratejinin temel yapi tasidir.

Canary Deployment

Canary deployment, yeni surumu oncelikle kucuk bir kullanici grubuna sunarak risk minimizasyonu saglar. Metrikler izlenir ve sorun tespit edilmezse yayilim kademeli olarak arttirilir.

# Canary deployment konfigurasyonu
canary:
  steps:
    - percentage: 1
      duration: 10m
      metrics:
        - error_rate < 0.5%
        - p99_latency < 500ms
    - percentage: 5
      duration: 30m
      metrics:
        - error_rate < 0.5%
        - p99_latency < 500ms
    - percentage: 25
      duration: 1h
    - percentage: 50
      duration: 2h
    - percentage: 100

Blue-Green Deployment

Iki ozdes production ortami arasinda gecis yaparak sifir kesinti suresi ile deployment gerceklestirilir. Mevcut ortam (blue) calismaya devam ederken yeni surum karsi ortama (green) deploy edilir. Trafik hazir oldugunda green ortamina yonlendirilir.

Ring-Based Deployment

Microsoft'un populerlestirdigi bu yaklasimda kullanicilar konsantrik halkalara ayrilir. Ic halkadan (gelistiriciler) baslayarak giderek genisleyen kullanici gruplarina yayilim yapilir.

Halka	Kullanici Grubu	Yayilim Orani	Izleme Suresi
Ring 0	Gelistirici ekip	%0.1	1 gun
Ring 1	Ic kullanicilar	%1	2 gun
Ring 2	Erken benimseyenler	%10	3 gun
Ring 3	Genis kullanici kitlesi	%50	1 hafta
Ring 4	Tum kullanicilar	%100	-

Feature Flag Araclari ve Karsilastirmasi

Piyasada pek cok feature flag yonetim araci bulunmaktadir. Dogru arac secimi, ekip buyuklugu, butce, ozellik gereksinimleri ve entegrasyon ihtiyaclarina baglidir.

LaunchDarkly

Kurumsal duzeyde feature flag yonetimi sunan LaunchDarkly, genis SDK destegi, gercek zamanli flag degerlendirmesi ve kapsamli hedefleme kurallari ile one cikar. Yuksek olcekli sistemler icin idealdir ancak maliyet avantaji dusuk butceli projeler icin sinirli kalabilir.

Unleash

Acik kaynakli bir alternatif olan Unleash, self-hosted veya bulut tabanli kullanim secenekleri sunar. Aktivasyon stratejileri (gradual rollout, user ID, IP, hostname) zengindir ve topluluk destegi gucludur.

Flagsmith

Hem acik kaynakli hem de yonetilen hizmet olarak sunulan Flagsmith, feature flag ve remote configuration yeteneklerini bir arada barindiri. Segmentasyon ve A/B testing modulleri dahilidir.

OpenFeature

OpenFeature, feature flag degerlendirmesi icin saglayici bagimsiz bir standart API tanimlar. Belirli bir araca bagimli kalmadan flag yonetim sistemleri arasinda gecis yapmayı kolaylastirir.

Ozellik	LaunchDarkly	Unleash	Flagsmith	OpenFeature
Lisans	Ticari	Acik Kaynak	Acik Kaynak	Acik Standart
Self-Hosted	Hayir	Evet	Evet	N/A
SDK Sayisi	25+	15+	15+	10+
A/B Testing	Evet	Sinirli	Evet	Provider bagimli
Fiyat	Yuksek	Ucretsiz/Kurumsal	Ucretsiz/Kurumsal	Ucretsiz

Feature Flag Mimarisi ve SDK Entegrasyonu

Saglam bir feature flag mimarisi, performansi olumsuz etkilemeden gercek zamanli flag degerlendirmesi yapabilmelidir. Temel mimari bilesenleri sunlardir: flag yonetim sunucusu, istemci SDK'lari, yerel onbellek katmani ve olay akisi (event streaming).

Server-Side SDK Entegrasyonu

# Python - Unleash SDK ornegi
from UnleashClient import UnleashClient

client = UnleashClient(
    url="https://unleash.example.com/api",
    app_name="my-application",
    custom_headers={"Authorization": "API_TOKEN"}
)
client.initialize_client()

# Flag degerlendirmesi
def get_product_list(user):
    context = {
        "userId": user.id,
        "properties": {
            "plan": user.subscription_plan,
            "region": user.region
        }
    }

    if client.is_enabled("new-search-algorithm", context):
        return advanced_search(user.query)
    else:
        return legacy_search(user.query)

Client-Side SDK Entegrasyonu

Client-side SDK'larinda guvenlik onemli bir husustur. Hassas flag konfigurasyonlarinin istemciye sizdirilmamasi icin sunucu tarafinda filtreleme uygulanmalidir. Yerel onbellekleme ile ag gecikmeleri minimize edilir ve flag degerlendirmesi milisaniye duzeyinde gerceklestirilir.

// React - Feature flag hook ornegi
import { useFeatureFlag } from '@company/feature-flags';

function CheckoutPage() {
  const showExpressCheckout = useFeatureFlag('express-checkout', {
    defaultValue: false,
    context: { userId: currentUser.id }
  });

  return (
    <div>
      <CartSummary />
      {showExpressCheckout ? (
        <ExpressCheckoutFlow />
      ) : (
        <StandardCheckoutFlow />
      )}
    </div>
  );
}

A/B Testing ile Feature Flags

Feature flag altyapisi, A/B testleri icin dogal bir zemin olusturur. Kullanicilari farkli varyantlara yonlendirme, tutarli gruplama (sticky bucketing) ve istatistiksel analiz bir arada calisir.

Basarili bir A/B test kurulumu icin dikkat edilmesi gereken noktalar:

• Tutarli atama: Ayni kullanici her zaman ayni varyanti gormeli. Hash-based bucketing bu tutarliligi saglar.
• Yeterli orneklem: Istatistiksel anlamlilik icin yeterli kullanici sayisina ulasilmali.
• Tek degisken ilkesi: Her deney mumkun oldugunda tek bir degiskeni test etmeli.
• Metrik tanimlamasi: Basari kriterleri deney baslamadan once belirlenmeli.

// A/B test varyant atamasi
const experiment = featureFlags.getVariant('checkout-flow-experiment', {
  userId: user.id,
  variants: [
    { name: 'control', weight: 50 },
    { name: 'single-page', weight: 25 },
    { name: 'wizard', weight: 25 }
  ]
});

// Metrik kaydi
analytics.track('checkout_started', {
  variant: experiment.name,
  userId: user.id
});

Flag Lifecycle Management ve Teknik Borc Onleme

Feature flag'lerin en buyuk riski teknik borca donusmeleridir. Kaldirilmayan flag'ler zamanla kod karmasikligini arttirir, test matrisini genisletir ve bakım maliyetini yukselterek sistemi kirilgan hale getirir. Smart Maple olarak musterilerimize bu konuda ozellikle dikkatli olmalarini oneriyoruz.

Flag Yasam Dongusu

Bir feature flag'in saglikli yasam dongusu su adimlari icerir:

1. Olusturma: Flag tanimlanir, sorumluluk atanir ve son kullanim tarihi belirlenir.
2. Gelistirme: Kod icerisinde flag kontrol noktalari eklenir.
3. Test: Tum flag kombinasyonlari test edilir.
4. Kademeli yayilim: Progressive delivery stratejisi uygulanir.
5. Tam yayilim: Flag %100 kullaniciya acilir.
6. Temizlik: Flag kodu kaldirilir, yalnizca kazanan varyant kalir.

Teknik Borc Onleme Stratejileri

// Flag olusturulurken son kullanim tarihi belirlenmeli
const flagConfig = {
  key: 'new-payment-flow',
  type: 'release',
  owner: 'payments-team',
  createdAt: '2026-03-06',
  expiresAt: '2026-04-15', // Maksimum 6 hafta
  description: 'Yeni odeme akisi - Phase 2',
  jiraTicket: 'PAY-1234'
};

Otomatik uyari mekanizmalari kurularak suresi dolan flag'ler icin bildirim gonderilebilir. CI/CD pipeline'ina suresi gecmis flag kontrolu eklenerek build surecinde uyari veya hata olusturulabilir.

Kill Switches ve Operational Flags

Kill switch'ler, kritik sistem bilesenleri uzerinde anlik kontrol saglayan ozel operasyonel flag'lerdir. Bir servis yogun yuk altindayken veya hata orani yukseldiginde ilgili ozelligi saniyeler icerisinde devre disi birakma imkani sunar.

# Kill switch ornegi
class PaymentService:
    def process_payment(self, order):
        # Kill switch kontrolu
        if feature_flags.is_enabled('kill-switch-external-payments'):
            raise ServiceUnavailableError(
                "Odeme servisi gecici olarak devre disi. "
                "Lutfen daha sonra tekrar deneyin."
            )

        # Rate limiting flag
        if feature_flags.is_enabled('payment-rate-limit'):
            self.apply_rate_limiting(order.user_id)

        # Graceful degradation
        if not feature_flags.is_enabled('payment-fraud-check'):
            # Fraud servisi devre disi, basit kontrol uygula
            self.basic_validation(order)
        else:
            self.full_fraud_check(order)

        return self.execute_payment(order)

Kill switch'lerin etkin kullanimi icin operasyonel runbook'lar hazirlanmali, hangi durumda hangi switch'in aktive edilecegi dokumante edilmelidir. Olay mudahale (incident response) sureclerine kill switch adimlari entegre edilmelidir.

Feature Flags ve CI/CD Entegrasyonu

Feature flag'ler CI/CD pipeline'lari ile entegre edildiklerinde gercek gucleri ortaya cikar. Deployment otomasyonu, otomatik yayilim kontrolleri ve metrik bazli karar mekanizmalari bir bütun halinde calisir.

Pipeline Entegrasyonu

# GitHub Actions - Feature flag ile deployment
name: Progressive Deployment

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh

      - name: Enable canary flag
        run: |
          curl -X PATCH \
            "$FLAG_SERVICE_URL/api/flags/new-feature" \
            -H "Authorization: Bearer $FLAG_API_KEY" \
            -d '{"percentage": 5}'

      - name: Monitor metrics (10 min)
        run: ./check-metrics.sh --duration=600

      - name: Increase rollout
        if: success()
        run: |
          curl -X PATCH \
            "$FLAG_SERVICE_URL/api/flags/new-feature" \
            -d '{"percentage": 50}'

      - name: Automatic rollback
        if: failure()
        run: |
          curl -X PATCH \
            "$FLAG_SERVICE_URL/api/flags/new-feature" \
            -d '{"percentage": 0}'

Metrik Bazli Otomatik Yayilim

Canary deployment sirasinda hata orani, gecikme suresi, CPU kullanimi gibi metrikler surekli izlenir. Esik degerler asildiginda yayilim otomatik olarak durdurulur veya geri alinir. Bu yaklasim insan mudahalesine olan bagimliligi azaltarak gece saatlerinde bile guvenli deployment yapilmasini mumkun kilar.

Trunk-Based Development ile Feature Flags

Trunk-based development, tum gelistiricilerin tek bir ana dal (trunk/main) uzerinde calistigi bir branching modelidir. Uzun omurlu feature branch'ler yerine, tamamlanmamis ozellikler feature flag'ler arkasina gizlenir.

Bu yaklasimin avantajlari sunlardir:

• Merge conflict azalmasi: Kisacik omurlu dallar veya dogrudan trunk uzerinde calisma, catismalari minimize eder.
• Surekli entegrasyon: Kod surekli olarak ana dala entegre edildigi icin entegrasyon sorunlari erken tespit edilir.
• Deployment hizi: Ana dal her zaman deploy edilebilir durumdadir.
• Kod inceleme kolayligi: Kucuk, odakli commit'ler incelemeyi kolaylastirir.

# Trunk-based development is akisi
git checkout main
git pull origin main

# Kucuk degisiklik yap, flag arkasina gizle
# ... kod degisiklikleri ...

git add .
git commit -m "feat: yeni arama algoritmasini flag arkasina ekle"
git push origin main

# Flag yonetim panelinden kademeli acilim yap

Best Practices ve Anti-Patterns

Best Practices

• Flag isimlendirme standartlari: Tutarli ve aciklayici isimlendirme kullanin. Ornegin release-new-dashboard, experiment-checkout-flow, ops-kill-payment-service.
• Sahiplik atamasi: Her flag'in bir sorumlu ekibi veya kisi olmali.
• Son kullanim tarihi: Release flag'ler icin maksimum yasam suresi belirleyin.
• Flag bagimlilik yonetimi: Flag'ler arasi bagimliliklari dokumante edin ve dairesel bagimliliklardan kacinin.
• Test stratejisi: Flag acik ve kapali durumlarinin her ikisini de test edin.
• Audit log: Tum flag degisikliklerini kayit altina alin.
• Varsayilan degerler: SDK erisim kaybinda guvenli varsayilan degerler tanimlayin.

Anti-Patterns

• Flag birikimi: Temizlenmeyen flag'lerin birikmesi, kodun okunabilirligini ve bakim kolayligini ciddi olcude azaltir. Duzenli temizlik dongusu sart.
• Ic ice flag'ler: Bir flag'in davranisinin baska bir flag'e bagimli olmasi, test ve hata ayiklama sureclerini katlanarak zorlastirir.
• Veritabaninda flag yonetimi: Ozel flag yonetim araclari yerine dogrudan veritabaninda flag yonetimi, izlenebilirlik ve kontrol kaybi yaratir.
• Istemci tarafinda hassas mantik: Sunucu tarafinda degerlendirilmesi gereken flag'lerin istemciye tasınmasi guvenlik riskleri olusturur.
• Flag'siz rollback plani: Flag kullanirken bile geri alma senaryolari planlanmalidir.

Olcum ve Basari Metrikleri

Feature flag ve progressive delivery yaklasiminin basarisini olcmek icin asagidaki metrikler izlenmelidir:

Metrik	Aciklama	Hedef Deger
Deployment Sikligi	Haftada kac deployment yapiliyor	Gunluk veya daha sik
Lead Time	Kodun commit'ten production'a ulasma suresi	1 saatten az
MTTR	Ortalama kurtarma suresi	15 dakikadan az
Degisiklik Hata Orani	Deployment sonrasi hata orani	%5'ten az
Flag Temizlik Suresi	Release flag'in kaldirilma suresi	2 haftadan az
Aktif Flag Sayisi	Sistemdeki toplam aktif flag	Ekip basina 15'ten az

Sonuc

Feature flag yonetimi ve progressive delivery, modern yazilim gelistirme sureclerinin vazgecilmez bilesenleri haline gelmistir. Dogru uygulandiginda deployment riskini minimize eder, kullanici deneyimini olcumlenebilir kilar ve operasyonel esneklik saglar.

Basarili bir feature flag stratejisi icin arac secimi kadar flag yasam dongusu yonetimi, teknik borc onleme ve ekip kulturu de kritik oneme sahiptir. Smart Maple olarak, ekiplerin bu yaklasimi benimsemesinde dogru mimari kararlarin ve surec tasariminin belirleyici oldugunu deneyimlerimizle gozlemliyoruz.

Progressive delivery ile birlikte kullanildiginda feature flag'ler, yazilim teslimatini bir "buyuk patlama" etkinliginden surekli ve kontrollü bir akisa donusturur. Canary deployment, ring-based rollout ve metrik bazli otomatik yayilim mekanizmalarini CI/CD pipeline'lariniza entegre ederek guvenli, hizli ve olculebilir bir teslimat sureci olusturabilirsiniz.