Feature Flag Nedir? Güvenli Yayına Alma Rehberi

Feature flag, bir yazılım özelliğini kodu yeniden dağıtmadan belirli kullanıcılar için açıp kapatmaya yarar. Güvenli yayın sürecinde yeni kod önce kapalı tutulur, ardından küçük bir gruba açılır ve hata metrikleri izlenerek genişletilir. Sorun görülürse özellik kapatılır; veri migrasyonları ve yetkilendirme gibi konular ise ayrıca yönetilir.

Feature flag nedir ve ne işe yarar?

Feature flag, bir uygulama özelliğinin kod yeniden dağıtılmadan açılıp kapatılmasını sağlayan yapılandırma mekanizmasıdır. Yeni bir özelliği önce yalnızca ekip üyelerine, belirli kullanıcı gruplarına veya trafiğin yüzde 1’ine gösterebilirsiniz. Sorun çıkarsa geri dönüş çoğu zaman yeni bir deploy değil, kontrollü bir ayar değişikliğidir.

Bu yaklaşım, kodun production’a çıkması ile özelliğin kullanıcıya açılmasını birbirinden ayırır. İkisi aynı şey değildir. Kod sunucuda bulunabilir, fakat ilgili davranış bir flag arkasında kapalı tutulabilir.

Feature flag ile deployment arasındaki fark

Deployment, yeni kodun sunucuya yüklenmesidir. Feature flag ise bu kodun hangi koşullarda çalışacağını belirler. Yayın riski böylece tek bir büyük ana bırakılmaz; daha küçük ve gözlemlenebilir adımlara bölünür.

Feature flag, rollback’in yerine geçmez. Veritabanı şeması değiştiyse, veri migrasyonu geri alınamıyorsa veya yeni kod tüm trafiği etkiliyorsa yalnızca flag kapatmak yeterli olmayabilir.

Ne yapılmalı – Her flag için hangi özelliği kontrol ettiğini, varsayılan değerini ve kaldırılacağı tarihi kayıt altına alın.

Feature flag türleri nelerdir?

Her flag aynı ömre veya aynı risk profiline sahip değildir. Kısa süreli bir yayın kontrolü ile yıllarca yaşayacak bir abonelik yetkilendirmesini aynı yöntemle yönetmek, zamanla anlaşılması zor koşullar üretir.

Release flag

Henüz tamamlanmamış bir özelliği production kodunda saklamak için kullanılır. Geliştirme sürerken kapalı kalır, testler tamamlandığında hedef kullanıcı grubuna açılır. Bu flag türünün ömrü kısa olmalıdır; özellik yayına çıktıktan sonra koddan ve flag kaydından temizlenir.

Experiment flag

Aynı kullanıcı grubuna farklı davranışlar göstermek ve ölçüm yapmak için kullanılır. A/B testi buna örnektir. Kullanıcıyı her istekte farklı gruba düşürmemek için kararlı bir değerlendirme anahtarı kullanılmalıdır. Kullanıcı kimliği veya anonim ziyaretçi için kalıcı bir kimlik yoksa deney sonuçları anlamını kaybedebilir.

Operational flag

Yoğun trafik, üçüncü taraf servis arızası veya kaynak tüketimi sırasında pahalı bir özelliği geçici olarak kapatır. Rapor dışa aktarma, öneri motoru veya görsel işleme gibi işlemler bu gruba girebilir. Operasyon ekibinin erişebildiği, denetim kaydı tutan ve hızlı değiştirilebilen bir arayüz gerekir.

Permission flag

Bir özelliği müşteri planına, role veya tenant yapılandırmasına göre açar. Bu tür flag’ler çoğu zaman uzun ömürlüdür ve aslında yetkilendirme sistemine yaklaşır. Güvenlik kararı yalnızca istemci tarafındaki bir flag’e bırakılmamalıdır; sunucu tarafında kullanıcı ve kaynak izinleri ayrıca doğrulanmalıdır.

Güvenli yayın için flag nasıl tasarlanır?

İyi bir flag, yalnızca true veya false değeri değildir. En azından anahtar adı, sahibi, amacı, oluşturulma tarihi, hedefleme kuralları ve kaldırılma koşulu bulunmalıdır.

İsimlendirme davranışı anlatmalıdır. new_ui kısa görünür, fakat aylar sonra hangi ekranı ve hangi sürümü ifade ettiği belirsizleşir. billing_invoice_pdf_v2 gibi bir ad, kapsamı daha açık biçimde taşır. Flag adı değiştirilmeyecek bir API gibi düşünülmelidir; aynı anahtarın farklı servislerde farklı anlamlara gelmesi hata üretir.

Değerlendirme sonucunu uygulama içinde merkezi bir katmandan geçirin. Her controller veya frontend bileşeni kendi flag okuma mantığını yazarsa varsayılan değerler, önbellek süreleri ve hata davranışları birbirinden ayrılır.

if (flags.isEnabled("billing_invoice_pdf_v2", userContext)) {
    return renderNewInvoicePdf();
}

return renderLegacyInvoicePdf();

Bu örnekte karar, PDF üretim kodunun içine dağılmıyor. flags.isEnabled katmanı hedefleme, varsayılan değer ve sağlayıcı iletişimini tek yerde topluyor.

Flag servisine erişilemediğinde ne olacağı önceden belirlenmelidir. Kritik olmayan yeni bir arama özelliği için false güvenli varsayılan olabilir. Kimlik doğrulama veya ödeme akışında ise otomatik olarak kapatma kararı iş mantığına göre ayrıca değerlendirilmelidir.

Ne yapılmalı – Her flag için erişim hatasında uygulanacak varsayılan davranışı kod incelemesi sırasında açıkça belirtin.

Flag değerleri kullanıcıya nasıl kademeli açılır?

En güvenli yayın tek hamlede yüzde 100’e çıkmak değildir. Önce uygulama ekibi, ardından küçük bir iç kullanıcı grubu, sonra düşük riskli bir müşteri segmenti ve son olarak tüm trafik seçilebilir.

1. Kapalı başlatın: Yeni kod production’a çıksa bile flag varsayılan olarak devre dışı olsun.
2. İç kullanıcılarla deneyin: Ekip hesapları ve test tenant’ları ilk gözlem noktası olsun.
3. Küçük bir yüzdede açın: Trafiğin veya kullanıcıların yüzde 1’iyle başlayın; yüzde burada rastgele ama kararlı bir dağıtım gerektirir.
4. Metrikleri izleyin: Hata oranı, gecikme, kaynak kullanımı ve iş metriğini birlikte kontrol edin.
5. Aralıklarla büyütün: Yüzde 1, 5, 25, 50 ve 100 gibi kademeler arasında gözlem süresi bırakın.
6. Geri dönüş koşulunu uygulayın: Önceden belirlenen eşik aşılırsa flag’i kapatın veya son güvenli kademeye dönün.

Yüzde bazlı dağıtımda her istekte yeni bir rastgele sayı üretmek yerine kullanıcı veya tenant kimliğinden kararlı bir hash oluşturmak daha tutarlı sonuç verir. Aksi durumda aynı kullanıcı bir istekte yeni arayüzü, sonraki istekte eski arayüzü görebilir.

bucket = stableHash(user.id + ":billing_invoice_pdf_v2") % 100

if bucket < rolloutPercentage:
    enableFeature()

Bu yalın örnek production için tek başına yeterli bir güvenlik katmanı değildir; hash algoritması, kimlik gizliliği, tenant sınırları ve flag değişikliklerinin denetim kaydı ayrıca ele alınmalıdır.

Flag değerlendirmesi sunucu tarafında yapılıyorsa istemciye yalnızca gerekli sonuç gönderilmelidir. Tüm flag deposunu tarayıcıya vermek, gelecekteki özellik isimlerini ve iş kurallarını açığa çıkarabilir.

Ne yapılmalı – Kademeli yayına başlamadan önce her yüzde aralığı için izlenecek metrikleri ve durdurma eşiğini yazılı hale getirin.

Feature flag yönetimi için hangi mimari seçilmeli?

Flag değerleri sabit bir yapılandırma dosyasında, veritabanında, özel bir servis üzerinde veya üçüncü taraf bir platformda tutulabilir. Seçim; değişiklik hızına, ekip sayısına, erişim denetimine ve servis kesintisine toleransa göre yapılmalıdır.

OpenFeature dokümantasyonu, flag değerlendirmesini uygulama kodundan ayırmak için sağlayıcı tabanlı, vendor-neutral bir yaklaşım tanımlar. Bu modelde uygulama aynı değerlendirme arayüzünü kullanırken flag verisinin kaynağı değişebilir.

Basit bir VPS üzerinde çalışan tek uygulama için önce sürümlenen bir YAML veya JSON dosyası yeterli olabilir. Ancak değişikliği deploy etmeden yapmak gerekiyorsa dosyanın yeniden yüklenmesi, atomik yazılması ve geçersiz içerikte son geçerli yapılandırmaya dönülmesi gerekir.

features:
  billing_invoice_pdf_v2:
    enabled: false
    rollout_percentage: 0
    owner: billing-team
    expires_at: 2026-12-31

Yapılandırma dosyasını uygulama sürecinin üzerinde doğrudan düzenlemek yerine geçici dosyaya yazıp atomik biçimde yerine koymak daha güvenlidir. Birden fazla uygulama örneği varsa her örneğin aynı flag değerini ne kadar sürede gördüğü ayrıca ölçülmelidir.

Bir flag servisi kullanıldığında ağ gecikmesi ve servis erişilemezliği hesaba katılır. Değerlendirme sonucunu kısa süreli önbelleğe almak yükü azaltabilir; fakat kapatma kararının tüm örneklere ulaşması gecikebilir.

Flag güvenliği ve gözlemlenebilirlik nasıl sağlanır?

Bir flag’in açılması, kod değişikliğinden farklı olarak çoğu zaman doğrudan kullanıcı davranışını değiştirir. Bu yüzden flag değişiklikleri de production değişikliği gibi denetlenmelidir.

• Değişikliği yapan kullanıcıyı kaydedin.
• Eski ve yeni değeri audit log içinde saklayın.
• Değişikliğin zamanını UTC olarak tutun.
• Flag anahtarını ve hedef kuralını loglayın.
• Değerlendirme hatalarını ayrı bir metrikte izleyin.
• Hassas kullanıcı verilerini log satırına koymayın.

Her istekte tüm flag değerlerini loglamak gürültü ve maliyet üretir. Kararın uygulama metriğine etkisini ölçmek daha kullanışlıdır. Örneğin invoice_pdf_generation_total{variant="v2"} ve invoice_pdf_errors_total{variant="v2"} gibi düşük kardinaliteli etiketler kullanılabilir; e-posta adresi veya ham kullanıcı kimliği etiket yapılmamalıdır.

Flag değişiminden sonra 5xx oranı, p95 veya p99 gecikme, CPU, bellek, veritabanı bağlantı havuzu ve kuyruk uzunluğu takip edilmelidir. Yalnızca uygulama loglarının temiz görünmesi yeni davranışın sağlıklı olduğu anlamına gelmez.

Özellik flag’i bir güvenlik kontrolü olarak kullanılıyorsa, kapalı durumun gerçekten yetkisiz erişimi engellediği test edilmelidir. Frontend’de butonun gizlenmesi erişim kontrolü değildir; API endpoint’i her istekte sunucu tarafında yetki doğrulamalıdır.

Ne yapılmalı – Flag değişimini, uygulama hatalarını ve iş metriğini aynı zaman çizelgesinde inceleyebileceğiniz bir dashboard oluşturun.

Eski flag’ler neden teknik borca dönüşür?

Bir flag açıldıktan sonra unutulursa kod iki ayrı davranışı uzun süre taşımaya başlar. Test sayısı artar, hangi dalın hâlâ gerekli olduğu belirsizleşir ve yeni geliştirici eski koşulu kaldırmaya çekinir.

GitLab’ın geliştirme dokümantasyonunda da flag yaşam döngüsü, tanımlı flag türü, sahibi ve kaldırma planı ile birlikte ele alınır. Pratik ders basittir: flag oluştururken kaldırma işini de planlayın.

Flag temizleme takvimi

1. Flag’i oluştururken son gözden geçirme tarihini belirleyin.
2. Yayından sonra eski kod yolunun hâlâ kullanılıp kullanılmadığını ölçün.
3. Flag yüzde 100 açık ve geri dönüş gerekmiyorsa eski dalı kaldırın.
4. Testleri, dokümantasyonu ve yapılandırma kaydını güncelleyin.
5. Flag deposunda silme işlemini denetim kaydıyla tamamlayın.

Uzun ömürlü permission veya operational flag’ler için otomatik silme doğru olmayabilir. Bu flag’lerde periyodik sahiplik kontrolü ve erişim gözden geçirmesi yapılmalıdır. Kısa ömürlü release flag’leri ise statik analiz, pull request kontrolü veya son kullanma tarihi alarmıyla izlenebilir.

Ne yapılmalı – Süresi geçen flag’leri listeleyen haftalık bir rapor üretin ve sahibi olmayan hiçbir flag’i açık uçlu bırakmayın.

CI/CD ve testlerde feature flag kullanımı

Flag arkasındaki yeni kod yalnızca flag açıkken test ediliyorsa kapalı dal zamanla bozulabilir. Her iki davranış için de birim ve entegrasyon testleri yazılmalıdır.

FEATURE_BILLING_INVOICE_PDF_V2=false pytest tests/billing
FEATURE_BILLING_INVOICE_PDF_V2=true pytest tests/billing

Ortam değişkeniyle yapılan bu örnek, küçük servislerde hızlı bir başlangıç sağlar. Production yapılandırması için gizli bilgilerle flag değerlerini karıştırmayın; bir özelliği açmak için kullanılan ayar, API anahtarı veya veritabanı parolası değildir.

CI/CD hattında flag değişikliğini uygulama deploy’undan ayrı bir değişiklik olarak görünür kılın. Production açılışında onay, iki kişili kontrol veya otomatik health check kullanılabilir. Flag açıldıktan sonra kısa bir gözlem penceresi bırakmak, sonraki pipeline adımının hatayı büyütmesini önler.

Veritabanı migrasyonları özel dikkat ister. Yeni kod eski şemayla da çalışabiliyorsa önce geriye uyumlu şema eklenir, ardından kod deploy edilir, flag açılır ve eski kolon veya tablo en son kaldırılır. Flag’i açıp migrasyonu sonra çalıştırmak, özellikle birden fazla uygulama örneğinde kesintiye yol açabilir.

Bir flag production’a alınmadan önce ne kontrol edilmeli?

Flag mekanizması yayın riskini azaltır; riski sıfırlamaz. Uygulamanın yeni ve eski yolları aynı anda çalışırken veri tutarlılığı, önbellek davranışı, kuyruklar ve üçüncü taraf API limitleri kontrol edilmelidir.

Örneğin yeni arayüz bir CDN üzerinde önbelleğe alınıyorsa, kullanıcı segmentine göre değişen içeriğin cache anahtarlarına doğru yansıdığından emin olun. [CDN Nedir? Web Sitesini Nasıl Hızlandırır?] başlığındaki önbellek davranışı bilgileri bu noktada doğrudan işe yarar. Sunucu tarafında ise [Ubuntu’da Nginx Kurulumu ve İlk Yapılandırma] rehberindeki yapılandırma doğrulama alışkanlığı, flag’den bağımsız olarak güvenli bir kontrol katmanıdır.

Yayın sırasında bir VPS snapshot’ı almak hızlı bir geri dönüş seçeneği sunabilir; fakat snapshot uygulama veritabanı tutarlılığını ve flag değişikliğinin kendisini tek başına garanti etmez. [VPS Snapshot Nedir? Anlık Yedekleme Rehberi] içindeki sınırlar dikkate alınmalıdır. Kod sürümünü yönetmek için de [Git Nedir? Sürüm Kontrolü Nasıl Çalışır?] ile flag tanımlarını ve kaldırma değişikliklerini birlikte izlemek daha sağlıklıdır.

Ne yapılmalı – Flag’i açmadan önce eski kod yolu, yeni kod yolu, veri migrasyonu ve geri dönüş planını aynı test ortamında deneyin.

Flag'i Production'a Almadan Önce Şunları Kontrol Edin

• Flag'in amacını, sahibini ve kaldırılma tarihini yazın.
• Kapalı ve açık davranış için ayrı testler oluşturun.
• Ağ veya flag servisi hatasında kullanılacak varsayılanı belirleyin.
• Kademeli yayın yüzdelerini ve durdurma eşiklerini tanımlayın.
• Flag değişiklikleri için audit log ve erişim yetkisi kurun.
• İstemci tarafı kontrollerini sunucu tarafı yetkilendirmeyle destekleyin.
• Yüzde 100 açılan kısa ömürlü flag'leri koddan ve yapılandırmadan kaldırın.

Sık Sorulan Sorular