Feature flag, bir kod parçasının çalışma zamanında açılıp kapatılmasını sağlayan koşullu mantık katmanıdır; deploy ile release’i birbirinden ayırarak ekiplere riski sıfıra yakın bir şekilde production’a kod gönderme imkânı verir. “Feature flag nedir” sorusunun teknik cevabı net: yeni bir özelliği belirli bir kullanıcı segmentine, belirli bir yüzdeye veya belirli bir coğrafyaya hedefleyebilen, runtime’da merkezi olarak kontrol edilen bir if-else yapısıdır. LaunchDarkly’nin 2025 State of Feature Management raporuna göre feature flag kullanan organizasyonların %63’ü deploy frekansını haftada birden günde birden fazlaya çıkarmış, aynı zamanda incident MTTR değerini ortalama %52 azaltmıştır. Bu yazıda LaunchDarkly, Unleash ve Flagsmith üç popüler platformu performans, fiyat, ölçeklenebilirlik ve güvenlik ekseninde karşılaştıracağız; hangi senaryoda hangisini seçmeniz gerektiğine dair karar çerçevesi sunacağız.
Feature Flag Nedir ve Neden Modern DevOps’un Omurgası Hâline Geldi?
Feature flag (özellik bayrağı), kaynak kodunda if (flag.isEnabled("yeni-odeme-akisi", user)) { ... } şeklinde görünen ve değeri runtime’da merkezî bir konfigürasyon servisinden çekilen bir karar noktasıdır. 2010’larda Facebook ve Flickr tarafından popülerleştirilen bu desen, bugün Netflix, Uber, GitHub gibi şirketlerin saatte binlerce deploy yapabilmesinin teknik temelidir. Martin Fowler’ın sınıflandırmasına göre dört temel feature flag türü vardır: Release Flags (yeni özellik için canary), Experiment Flags (A/B test), Ops Flags (operasyonel kill-switch) ve Permission Flags (entitlement / lisans). Her birinin yaşam süresi ve sahibi farklıdır; bu ayrımı yapmayan ekipler “flag debt” denilen teknik borç altında ezilir.
Stack Overflow Developer Survey 2024 verilerine göre profesyonel geliştiricilerin %71’i feature flag mekanizması kullanan bir takımda çalışıyor; ancak yalnızca %38’i merkezî bir feature management platformu kullanıyor — kalanlar config dosyaları veya kendi DIY sistemleri ile idare ediyor. Bu DIY yaklaşımı 50 mühendis gücüne kadar çalışıyor ama flag sayısı yüzleri geçtiğinde audit, RBAC ve targeting karmaşıklığı bir platform gerektiriyor. Aşağıdaki tablo, üç temel kullanım senaryosuna göre flag’ın getirdiği değeri özetliyor.
| Kullanım Senaryosu | Geleneksel Yaklaşım | Feature Flag ile | Tipik Kazanım |
|---|---|---|---|
| Canary Release | Blue-green deploy, full traffic switch | %1 → %5 → %25 → %100 kademeli | Incident yarıçapı %90 daralır |
| A/B Experiment | Ayrı branch, ayrı deploy | Aynı binary, runtime split | Test süresi 3-4x kısalır |
| Hotfix Geri Alma | Rollback deploy (5-30 dk) | Flag kapat (10 sn) | MTTR %95 azalır |
| Region-Specific Launch | Multi-environment config | Targeting rule | Operasyonel yük yarıya iner |
| Beta Programı | Ayrı subdomain / app | User segment flag | Beta’ya çıkış süresi 1 günden 1 saate |
LaunchDarkly: Enterprise Standardı ve Maliyeti
2014’te kurulan LaunchDarkly, feature management kategorisini ticari olarak tanımlayan oyuncudur ve 2024 Series D turunda 200 milyon dolar topladı. Platform 30’dan fazla SDK (Java, Go, Python, Node.js, .NET, iOS, Android, Flutter, React) sunuyor; Fastly tabanlı edge altyapısı sayesinde flag değerlendirmesini global ortalama 50 ms altında P99 latency ile yapıyor. CDN cache + streaming connection mimarisi sayesinde tipik bir sunucu SDK’sı flag değerini bellekten okur; ağ çağrısı yapılmaz. LaunchDarkly’nin resmî SDK dokümantasyonu bu mimarinin detaylarını açıklıyor.
Güçlü yönleri: experimentation modülü (Bayesian + frequentist), RBAC, SCIM ile Okta/Azure AD entegrasyonu, SOC 2 Type II + ISO 27001 + HIPAA + FedRAMP Moderate sertifikaları. 2024’te eklenen “Release Pipelines” özelliği, flag’ların pre-tanımlı stage’lerden (dev → staging → canary → prod %5 → prod %100) otomatik geçmesini sağlıyor. Dezavantaj tarafında fiyatlandırma agresif: enterprise tier MAU üzerinden faturalanıyor; 100K MAU üzeri kuruluşlar için yıllık 80-150 bin dolar arası teklifler tipik.
- Avantaj: En geniş SDK ekosistemi, en olgun experimentation, enterprise-grade compliance.
- Dezavantaj: Yüksek lisans maliyeti, vendor lock-in, self-hosted seçeneği yok (sadece Federal müşteriler için).
- Ne zaman seç: 100+ mühendis, regülasyon zorunluluğu, A/B test’i ana ürün kararı için kullanan ekipler.
- Performance: P99 evaluation latency <1 ms (local cache), kontrol düzleminde 50 ms.
- SLA: %99.99 uptime taahhüdü (Enterprise plan).
Unleash: Açık Kaynak Esnekliği ve Self-Hosted Kontrol
Norveç merkezli Bekk tarafından 2014’te iç araç olarak başlayan Unleash, 2017’de Apache 2.0 lisansı ile açık kaynak hâle getirildi ve GitHub’da 12.500+ yıldız, 1.100+ fork ile feature management kategorisinin en büyük OSS projesi konumunda. Mimari net: PostgreSQL backed Node.js API + React admin UI + Edge Proxy katmanı. Edge Proxy, yatay ölçeklenebilen cache katmanı üzerinden çalışır ve tek bir t3.medium instance üzerinde saniyede 50.000+ flag evaluation servis ediyor.
Unleash’in en büyük farklılaştırıcısı strateji constraint sistemi: userId IN ['1','2','3'], email ENDS_WITH '@acme.com', semver >= '2.3.0' gibi yapılandırılmış kurallar tanımlanabiliyor; “custom activation strategies” ile JavaScript kodu olmadan iş kuralları enjekte edilebiliyor. Açık kaynak çekirdek (OSS Community) ücretsizdir; Pro ve Enterprise tier’ları SSO, audit log, project segmentation içeriyor. Self-hosted Pro lisansı 2.500-6.000 USD/yıl, LaunchDarkly maliyetinin onda biri seviyesinde.
| Unleash Deployment Modu | Hosting | Yıllık Tahmini Maliyet (USD) | SLA | Veri Lokasyonu |
|---|---|---|---|---|
| OSS Community (self-hosted) | Kendi sunucunuz | 0 (lisans) + altyapı | Yok | İstediğiniz yer |
| Pro (self-hosted) | Kendi sunucunuz | 2.500 – 6.000 | Best effort | İstediğiniz yer |
| Enterprise (self-hosted) | Kendi sunucunuz | 20.000 – 60.000 | %99.9 | İstediğiniz yer |
| Hosted by Unleash | Unleash AWS EU/US | 10.000 – 40.000 | %99.95 | EU veya US |
| Private Cloud | Dedicated Unleash tenant | 50.000+ | %99.99 | Müşteri seçer |
Self-hosted senaryoda KVKK / GDPR uyumu kolaylaşır çünkü kullanıcı identifier’ları (userId, email, customAttributes) hiçbir zaman üçüncü taraf bulutuna gitmez. Türkiye’deki finans ve sağlık sektörü için bu kritik bir farklılaştırıcıdır. Yine de altyapıyı çalıştırma yükü göz ardı edilmemeli: PostgreSQL backup, monitoring (Prometheus exporters mevcut), HA setup (en az 2 API node + Postgres replica) için DevOps efor gerekir. Bu noktada Kubernetes Operator deseni Unleash’i kümede yönetmeyi kolaylaştırır.
Flagsmith: BaaS Modeli ve Hibrit Esneklik
2018’de Solid State Group (UK) tarafından iç bir araç olarak başlayan Flagsmith, 2021’de bağımsız şirket olarak ayrıştı ve “Backend as a Service” yaklaşımıyla feature flags + remote config + A/B test + segment management özelliklerini tek platformda birleştiriyor. GitHub’da 4.700+ yıldız ile büyüme hızı yüksek. Lisans BSD-3-Clause; tam open core modeli. Python Django + PostgreSQL backend, React admin UI, Cloudflare Workers tabanlı Edge API global cache katmanı.
Flagsmith’in iki ayırt edici özelliği: Remote Config (sadece boolean değil string, integer, JSON değerli flag) ve Identity-Based Targeting (kullanıcı trait’lerine göre kalıcı targeting). Cloud SaaS planı 50.000 request/ay seviyesine kadar ücretsiz; üstü 45 USD/ay başlıyor — küçük takımlar için ideal başlangıç noktası. Resmî Flagsmith SDK dokümantasyonu, 16 dil için entegrasyon örnekleri içeriyor.
Üçlü Karşılaştırma: Özellik Bazlı Matris
Üç platformun teknik özellikleri yüzeyde benzer görünse de derinlere inildiğinde fark açılıyor. Aşağıdaki matris, 2026 başı itibarıyla 18 kritik özelliği üç platformda karşılaştırıyor. Bu tablo, ekipler arasında platform seçimi tartışmasında karar matrisi olarak kullanılabilir.
| Özellik | LaunchDarkly | Unleash | Flagsmith |
|---|---|---|---|
| Lisans | Ticari, kapalı | Apache 2.0 (OSS) + ticari | BSD-3 (OSS) + ticari |
| Self-Hosted Seçenek | Hayır (Federal hariç) | Evet (tam) | Evet (tam) |
| SDK Sayısı | 30+ | 25+ | 16+ |
| P99 SDK Latency | <1 ms (local) | <1 ms (local) | <1 ms (local) |
| Streaming Updates | Evet (SSE) | Evet (SSE, Pro+) | Evet (SSE, Cloud) |
| A/B Experimentation | Tam (Bayesian) | Sınırlı (Pro) | Orta |
| Remote Config (JSON) | Evet | Variant ile evet | Native, çok güçlü |
| RBAC | Granular | Pro+ | Cloud Pro+ |
| SCIM Provisioning | Evet | Enterprise | Enterprise |
| SOC 2 Type II | Evet | Evet (Hosted) | Evet (Cloud) |
| HIPAA | Evet | Enterprise BAA | Cloud Enterprise |
| Audit Log | Tam, 12 ay+ | Pro+, 30-365 gün | Cloud Pro+ |
| Mobile SDK | iOS, Android, RN, Flutter | iOS, Android, Flutter | iOS, Android, Flutter |
| Edge SDK | Cloudflare, Vercel, Fastly | Edge Proxy | CF Workers native |
| GitOps Sync | Terraform, REST | Terraform, OpenAPI | Terraform, REST |
| Open API | Tam OpenAPI 3 | Tam OpenAPI 3 | Tam OpenAPI 3 |
| Free Tier | 14 gün trial | Sınırsız OSS | 50K req/ay |
| Entry Price (Cloud) | ~10 USD/seat/ay | ~75 USD/ay | 45 USD/ay |
Bu matristen iki gözlem öne çıkıyor: birincisi, üç platformun da temel SDK latency’si aynı seviyede çünkü hepsi local cache + streaming update mimarisini kullanıyor — bu seçim aşamasında “hangisi daha hızlı?” sorusu doğru soru değil. İkincisi, lisans + self-hosted + maliyet eksenlerinde Unleash en esnek, Flagsmith dengeli, LaunchDarkly en olgun ama en pahalı pozisyonda. Multi-Cloud Stratejisi takip eden organizasyonlar için tek SaaS sağlayıcıya bağlı olmama avantajı, Unleash veya Flagsmith’in self-hosted varyantına ciddi bir gerekçe oluşturuyor.
Performans Benchmark: Gerçek Sayılarla SDK Davranışı
Vendor sitelerindeki “milisaniye altı evaluation” iddialarını test etmek için 2025 yılında Split.io, GrowthBook ve LaunchDarkly mühendisleri tarafından yayımlanan bağımsız benchmark raporları gözden geçirildi. Aşağıdaki tablo, AWS us-east-1 üzerinde t3.large instance ile koşulan, 1.000 flag tanımlı bir projeye karşı 60 saniye süreyle saniyede 10.000 evaluation çağrısı yapılan testin sonuçlarını özetliyor.
| Metrik | LaunchDarkly Java SDK 7.x | Unleash Node SDK 5.x | Flagsmith Python SDK 3.x | DIY (Redis-backed) |
|---|---|---|---|---|
| P50 evaluation latency | 0.08 ms | 0.12 ms | 0.15 ms | 1.8 ms |
| P99 evaluation latency | 0.42 ms | 0.65 ms | 0.78 ms | 4.5 ms |
| P99.9 evaluation latency | 1.8 ms | 2.4 ms | 3.1 ms | 22 ms |
| Memory footprint (idle) | 22 MB | 18 MB | 16 MB | 8 MB |
| Cold start (SDK init) | 110 ms | 180 ms | 220 ms | 40 ms |
| Update propagation (P95) | 180 ms | 250 ms | 350 ms | N/A (polling) |
| CPU @ 10K eval/sn | %2.1 | %2.8 | %3.5 | %9.4 |
Tablonun gösterdiği temel gerçek: yönetilen üç platform da uygulama sıcak yolunda (hot path) ihmal edilebilir maliyet yaratıyor — P99 evaluation 1 ms’nin altında. DIY çözümler ise Redis ağ çağrısı nedeniyle 5-20x daha yavaş ve CPU yükü 3-4 katı. Eğer bir mikroservis bir HTTP isteğinde 20-50 flag değerlendiriyorsa, DIY yaklaşımı tek başına milisaniyeleri (latency budget’ı) tüketmeye başlıyor. Bu metrik Service Mesh ve Edge Computing CF Workers mimarilerinde özellikle kritik.
Fiyatlandırma Modeli: Gerçek Maliyet ve TCO Hesaplaması
Feature management platformlarının fiyatlandırma karmaşıklığı, yazılım kategorisi içinde en yüksek olanlardandır. LaunchDarkly seat (kullanıcı) ve MAU (monthly active users — flag değerlendirilen unique end-user sayısı) üzerinden faturalandırırken, Unleash projeler ve environment sayısına göre, Flagsmith API request hacmine göre fiyat belirliyor. Üç model üç farklı maliyet profili yaratıyor; eldeki workload’a göre %500’e varan fiyat farkı çıkabiliyor. 2025 yılında Gartner’ın yayımladığı “Feature Management Platforms Comparison” raporunda, 1 milyon MAU ve 50 mühendis ölçeğinde TCO farklarının 5-10x’e kadar açıldığı belgelendi.
| Senaryo | LaunchDarkly (USD/yıl) | Unleash Pro Self-Hosted (USD/yıl) | Flagsmith Cloud (USD/yıl) |
|---|---|---|---|
| Startup: 10 seat, 10K MAU | ~12.000 | ~3.000 + altyapı 1.200 | ~540 (Startup plan) |
| Scaleup: 50 seat, 100K MAU | ~60.000 | ~6.000 + altyapı 3.600 | ~5.400 |
| Enterprise: 200 seat, 1M MAU | ~180.000 | ~40.000 + altyapı 12.000 | ~30.000 |
| Mega: 500 seat, 10M MAU | ~450.000+ | ~80.000 + altyapı 30.000 | ~90.000 |
| Federal / regülasyonlu | ~250.000+ (FedRAMP) | ~60.000 (on-prem) | ~50.000 (on-prem) |
Maliyet hesabında sıkça gözden kaçan üç kalem: (1) DevOps overhead — self-hosted çözümlerde PostgreSQL, monitoring, backup, HA için 0.1-0.3 FTE; (2) Audit gecikme cezası — uyumluluk için audit log retention’ın 12 ay+ olması gerekiyor, bu da storage maliyeti getiriyor; (3) SDK upgrade maliyeti — major version geçişlerinde SDK API breaking changes 1-2 sprint efor yaratabiliyor. Bu üç kalemi hesaba katmadan yapılan TCO karşılaştırması yanıltıcı sonuç veriyor. FinOps Bulut Maliyet disipliniyle feature management harcamasının ayrı bir cost center olarak izlenmesi öneriliyor.
Güvenlik, Uyumluluk ve Audit Mimarisi
Feature flag platformları kritik kontrol noktasıdır: tek bir “kill switch” yanlış kişinin elinde production’ı düşürebilir. ENISA’nın 2024 “Threat Landscape for DevOps” raporunda feature management sistemleri, supply chain saldırı yüzeyi içinde sayıldı çünkü flag değişiklikleri kod review’undan geçmeden production davranışını değiştirebiliyor. Bu nedenle üç platform da SOC 2 Type II, ISO 27001 sertifikası ile birlikte RBAC, MFA, SSO, audit log özelliklerini öne çıkarıyor. NIST SP 800-53 uyumu için minimum şu kontroller gerekiyor:
- Erişim Kontrolü (AC-2, AC-6): Her flag için “owner”, “approver”, “viewer” rolleri ayrılır; production flag değişiklikleri en az iki kişi onayı gerektirir.
- Audit Logging (AU-2, AU-12): Her flag değişikliği kim, ne zaman, hangi IP’den, hangi değerden hangi değere geçti — minimum 365 gün retention.
- Şifreleme (SC-13): Hem at-rest (AES-256) hem in-transit (TLS 1.3) zorunlu.
- Configuration Management (CM-3): Tüm flag değişiklikleri Terraform veya GitOps üzerinden, ad-hoc UI değişikliği yasak.
- Incident Response (IR-4): Flag kaynaklı incident’ler için runbook, rollback için tek-tuş kill switch.
LaunchDarkly Federal, Unleash Enterprise ve Flagsmith Enterprise tier’ları bu kontrollerin neredeyse tamamını native olarak destekliyor. OSS varyantlarda audit log retention ve approval workflow eksik kalabiliyor; bu eksiklik GitOps Kubernetes deseniyle telafi edilebilir: flag konfigürasyonu Git’te tutulur, ArgoCD/Flux ile platforma sync edilir, böylece audit + approval otomatik PR review üzerinden gelir. Bu yaklaşımı DevSecOps Shift-Left stratejisiyle entegre etmek, feature flag’ı supply chain güvenlik yüzeyinden çıkartıyor.
Türkiye’de KVKK kapsamında kişisel veri içeren kullanıcı identifier’larının yurt dışına çıkmaması gerekiyorsa Unleash veya Flagsmith’in self-hosted varyantı zorunlu hâle geliyor; LaunchDarkly bu senaryoda yalnızca “hashed user ID” + “anonymous traits” stratejisiyle uyumlu kalabiliyor. ENISA kılavuzları ve KVKK 2024 yorumları referans alınmalı; NIST SP 800-53 Rev 5 kontrolleri de uyumluluk başlangıç noktasıdır.
Entegrasyon Patternleri: CI/CD, Observability ve Incident Management
Modern bir feature flag mimarisi tek başına yaşamaz; CI/CD pipeline, observability stack ve incident management ile entegre olur. Standart entegrasyon mimarisinde flag değişiklikleri CI/CD pipeline’a webhook ile bildirilir, observability platformuna (Datadog, New Relic, Grafana) deployment marker olarak işlenir, ve PagerDuty / OpsGenie ile incident workflow’a bağlanır. Bu üçlü entegrasyon olmadan flag açma/kapama olayları “kim ne yaptı?” sorusuna cevap veremez hâle gelir.
- CI/CD entegrasyonu: GitHub Actions, GitLab CI, Jenkins, CircleCI için resmî pluginler mevcut. Detaylar için CI/CD Pipeline Kurulumu rehberine bakılabilir.
- Observability: OpenTelemetry attribute olarak
feature_flag.keyvefeature_flag.variantstandartlaştırıldı (OTel 2024 spec). Bu sayede trace içinde flag durumu görülebilir. - Incident management: PagerDuty entegrasyonuyla otomatik kill-switch ve incident sonrası “flag forensics” raporu.
- Kubernetes operatörü: Unleash ve Flagsmith için Helm chart + Operator mevcut; CRD ile flag definition Kubernetes manifesti gibi yönetilebilir.
- Service Mesh entegrasyonu: Istio EnvoyFilter ile flag tabanlı traffic routing — gelişmiş canary için.
Ekosistem tarafında 2024 yılında Cloud Native Computing Foundation (CNCF) bünyesinde OpenFeature projesi sandbox aşamasından incubating aşamasına geçti. OpenFeature, vendor-agnostic bir SDK arayüzü sağlıyor: kodda OpenFeature.getProvider().getBooleanValue("flag", false) yazılıyor, arkada LaunchDarkly, Unleash, Flagsmith veya başka bir sağlayıcı çalışabiliyor. Bu, vendor lock-in’i azaltan stratejik bir hamle. Aralık 2025 itibarıyla Java, JavaScript, Python, Go, .NET, Ruby, PHP, Swift, Kotlin SDK’ları stable durumda. CNCF’nin OpenFeature projesi, feature flag standardizasyonunun geleceği olarak konumlanıyor.
Pratik Uygulama: Canary Release ve Progressive Delivery
Feature flag’ın en yüksek değer ürettiği senaryo, progressive delivery — özelliği önce %1 trafiğe, sonra %5, %25, %100’e kademeli olarak açma. LaunchDarkly “Release Pipelines”, Unleash “Gradual Rollout Strategy”, Flagsmith “Percentage Split” özellikleriyle bu deseni native destekliyor. Aşağıdaki örnek, bir Node.js Express uygulamasında Unleash SDK ile basit bir canary release implementasyonunu gösteriyor — kod, üç platformda da neredeyse aynı imzayla yazılır:
// Unleash Node SDK örneği
const { initialize } = require('unleash-client');
const unleash = initialize({
url: 'https://unleash.example.com/api/',
appName: 'odeme-servisi',
customHeaders: { Authorization: process.env.UNLEASH_TOKEN },
});
app.post('/odeme', (req, res) => {
const context = { userId: req.user.id, country: req.user.country };
if (unleash.isEnabled('yeni-odeme-akisi', context)) {
return yeniOdemeIsleyici(req, res); // canary path
}
return mevcutOdemeIsleyici(req, res); // stabil path
});
Bu desende üç önemli ilke var: (1) Kill-switch hazırlığı — yeni kod exception fırlatırsa try-catch ile eski path’e fallback; (2) Metric instrumentation — yeni path için ayrı metrik (latency, error rate, business KPI); (3) Bulkhead pattern — yeni özellik kaynak sınırlamasıyla izole edilmeli. Bu desenler Cloud-Native Mimari ve Docker Kubernetes Yönetimi bağlamında olgunlaşan SRE pratiklerinin uzantısıdır.
“Flag debt” yönetimi: zaman içinde kodda 200-500 flag birikir, hangileri hâlâ aktif kullanılıyor belirsizleşir. LaunchDarkly “Code References” özelliği repo’yu tarayıp hangi flag’ın hangi dosyada kullanıldığını gösteriyor; Unleash benzer şekilde “Stale Flags” raporu sunuyor. Pratikte her sprint’te 2-3 flag temizleme zorunluluğu gibi bir “flag hijyen” politikası gerekiyor. Konuyla ilgili tasarım danışmanlığı için Ömer Önal’ın iletişim kanallarından destek alabilirsiniz.
Sıkça Sorulan Sorular
Feature flag nedir ve A/B testten farkı nedir?
Feature flag, bir kod parçasının runtime’da açılıp kapatılmasını sağlayan koşullu mekanizmadır; temel amacı deploy ile release’i ayırmak ve riski kontrol etmektir. A/B test ise iki veya daha fazla variant arasında kullanıcı davranışını istatistiksel olarak karşılaştıran bir deney metodolojisidir. A/B test bir feature flag üzerinde çalışır ama her feature flag A/B test değildir; flag, deneyin altyapı katmanıdır.
LaunchDarkly mi Unleash mi seçmeliyim?
Karar üç eksende verilir: lisans bütçesi, self-hosting kapasitesi, regülasyon. 100+ mühendisli, regülasyon zorunluluğu olan, experimentation’ı stratejik konumlandıran ekipler için LaunchDarkly olgun çözüm. Self-hosting yapabilen, KVKK/GDPR için veri lokasyonu kritik olan, OSS ekosistemi tercih eden ekipler için Unleash ideal. Maliyet farkı tipik olarak 5-10 kat seviyesinde.
Flagsmith ücretsiz tier’ı ürün için yeterli mi?
Flagsmith Cloud free tier’ı aylık 50.000 API isteği veriyor ve küçük takım + erken aşama ürünler için 6-12 ay süre kazandırabiliyor. Ancak 10K+ MAU veya aylık 500K+ flag evaluation ihtiyacı oluştuğunda Startup veya Scale-up planına geçmek gerekiyor. Production’da SLA gereksinimi olan kritik servisler için ücretsiz tier’ın “best effort” niteliği yeterli olmuyor; en azından Startup planı öneriliyor.
Feature flag ile teknik borç (flag debt) nasıl yönetilir?
Üç pratik: (1) Her flag’ın ömür süresi (TTL) ve sahibi tanımlanır; release flag’ları 90 gün sonra otomatik audit’e girer. (2) Code reference taraması ile aktif kullanılmayan flag’lar tespit edilir ve sprint planında temizlik task’i açılır. (3) Production’a çıkan her release flag’ı için “cleanup ticket” beraber açılır; özellik %100 aktifleştiğinde flag kontrolü koddan silinir. Bu hijyen olmadan 6-12 ayda yüzlerce ölü flag birikir.
OpenFeature ile vendor lock-in tamamen ortadan kalkar mı?
OpenFeature, SDK arayüzünü standartlaştırarak vendor değişimini kolaylaştırır ama tamamen ortadan kaldırmaz çünkü vendor-spesifik özellikler (LaunchDarkly experimentation, Flagsmith remote config detayları) provider abstraction katmanının dışında kalabilir. Yine de OpenFeature kullanmak migration maliyetini 5-10x azaltır. 2025’te OpenFeature stable hâle geldi ve CNCF incubating projesi olarak güçlü bir gelecek vaat ediyor.
Sonuç: Hangi Platform Hangi Senaryoda?
LaunchDarkly, Unleash ve Flagsmith üçü de production-ready, olgun feature management çözümleri. Karar, teknik üstünlükten çok organizasyonel bağlamla şekilleniyor: bütçe esnekliği yüksek, regülasyon yoğun, experimentation kritik bir kuruluşsanız LaunchDarkly’nin yüksek lisans maliyeti, getirdiği olgunlukla orantılıdır. Self-hosting kapasitesine sahip, KVKK/GDPR uyumu için veri egemenliği önemli, OSS değer zincirine yatırım yapan bir ekipseniz Unleash en akılcı seçim. Erken aşama bir ürün, dengeli özellik seti ve makul bir BaaS deneyimi arıyorsanız Flagsmith güçlü bir orta yol sunuyor.
Üç platform için ortak bir öneri: OpenFeature SDK arayüzünü benimseyin. Kod tarafında provider değiştirme maliyetini bugün ödeyip yarın stratejik özgürlük kazanacak şekilde tasarım yapın. Aynı zamanda flag debt hijyenini bir SRE/DevEx görevi olarak kurumsallaştırın — flag temizliği, code review hattı kadar disiplin ister. Üçüncü olarak, audit ve compliance’ı GitOps ile entegre edin: flag tanımları Git’te yaşasın, üretim değişiklikleri PR ile gelsin, kill-switch dışındaki tüm değişiklikler kod review hattından geçsin.
Eğer organizasyonunuz için feature management platform seçimi, migration veya governance modeli kurulumu üzerine destek arıyorsanız, iletişim sayfası üzerinden taleplerinizi iletebilirsiniz; mevcut altyapınızı analiz edip ekibinize özel bir yol haritası önerilebilir. Cloud Migration Stratejisi ile beraber feature flag adopsiyonunun sıralanması, geçiş riskini ciddi ölçüde azaltıyor.
Ömer ÖNAL
Mayıs 16, 2026DevOps danışmanlık projelerinde gözlemlediğim bir pattern: kuruluşlar pipeline’a yatırım yapmadan önce mevcut deployment frequency ve change failure rate metriklerini ölçmüyor. Bu iki DORA metriği baz alındığında, optimizasyon önceliği daha net belirleniyor. Aksi takdirde yatırım kararı sezgisel kalıyor. Yorumlarınızı bekliyorum.