Bir özelliği üretime almak çoğu ekipte tek bir an gibi görülür: kod merge edilir, build yayınlanır ve herkes yeni davranışı görür. Bu model, küçük ve düşük riskli değişikliklerde yeterli olabilir. Ödeme akışı, yeni yetkilendirme kuralı, yapay zekâ destekli öneri veya veri dönüşümü gibi işlerde ise yayın, ikili bir karar olmaktan çıkar. Kodun canlıya çıkmasıyla kullanıcıya açılması farklı anlar olmalıdır.
Özellik bayrağı bu ayrımı sağlar. Uygulama yeni kodu içerir, fakat davranış belirli bir kurala göre etkinleşir. Böylece ekip önce küçük bir kullanıcı grubunda gözlem yapabilir, sorun görülürse yeni build beklemeden bayrağı kapatabilir ve sonuç olumluysa kapsamı kontrollü biçimde genişletebilir. Bayraklar tek başına güvenlik mekanizması değildir; doğru hedefleme, ölçüm ve yaşam döngüsüyle kullanıldığında yayın riskini azaltan bir araçtır.
Bayrağın hangi problemi çözdüğünü yazın
Her boolean benzeri ayar özellik bayrağı değildir. Bazıları kalıcı ürün yapılandırmasıdır: bir kurumun lisans limiti, dil tercihi veya çalışan saatleri gibi değerler yayından bağımsızdır. Özellik bayrağı ise çoğunlukla geçici bir karar mekanizmasıdır; yeni bir davranışın kimlerde, ne zaman ve hangi koşulda açılacağını kontrol eder.
Bayrak eklemeden önce kısa bir karar kaydı tutmak faydalıdır:
- Hangi kullanıcı değerini veya riski yönetiyor?
- Açık ve kapalı durumda uygulama nasıl davranıyor?
- Kim bayrağı değiştirebilir?
- Hangi metrik başarılı sayılacak?
- Kapatma veya kaldırma için hedef tarih nedir?
Bu sorular, newFeatureEnabled gibi belirsiz isimlerin yerine ai_summary_v2_rollout ya da new_checkout_validation gibi amacı ve bağlamı anlatan adlar seçmeyi de kolaylaştırır.
Hedefleme kuralını açık ve kararlı tutun
İlk aşamada özellik yalnızca ekip üyelerine, test tenant'larına veya açıkça seçilmiş bir beta grubuna açılabilir. Daha sonra yüzdelik rollout uygulanabilir. Burada kritik nokta, aynı kullanıcının her istekte rastgele farklı gruba düşmemesidir. Kararlı bir kullanıcı veya tenant kimliğinden türetilen hash, kullanıcının deneyimini tutarlı tutar.
Hedefleme kuralı özellikle çok kiracılı ürünlerde dikkat ister. Bayrağı kullanıcı bazında açmak yerine bir tenant'ın tamamına açmak, ekiplerin yeni özelliği birlikte denemesini kolaylaştırabilir. Tersine, hassas bir değişiklikte belirli rol, plan veya ülke koşulu gerekli olabilir. Her durumda yetkilendirme ile rollout hedeflemesini ayırmak gerekir: Bayrak bir kullanıcının özelliği görmesine karar verir; kullanıcının işlem yapmaya yetkili olup olmadığına değil.
Sunucu ve istemci aynı kararı vermiyorsa arayüz ile API farklı davranabilir. Mümkün olduğunda değerlendirmeyi tek güvenilir noktada yapmak veya açık bir bayrak bağlamını iki tarafa da tutarlı iletmek gerekir.
Kapatılmış yol da ürün davranışıdır
Bir bayrağın kapalı hâli yalnızca if bloğunun çalışmaması değildir. Kullanıcı kapalı durumda ne görür? Önceden var olan davranış korunuyor mu? Yeni veriyi okumayan eski istemci hata alıyor mu? Bu sorular özellikle veri şeması değişirken önem kazanır.
Güvenli geçiş için yaygın sıra şudur: önce yeni şemayı ve hem eski hem yeni kodun okuyabildiği biçimi yayınlayın; sonra yeni yazma davranışını sınırlı kitlede açın; geçiş tamamlanınca eski okuma veya yazma yolunu kaldırın. “Bayrağı kapatınca her şey eskisine döner” varsayımı, geri döndürülemez veri dönüşümü yapıldıysa doğru değildir.
Bayrak kontrolleri kritik erişim kararlarında tek koruma olmamalıdır. İstemcide gizlenen bir düğme, sunucudaki yetkilendirme kontrolünün yerine geçmez. Kullanıcı bayrağı geçse bile API, izin ve veri sınırını bağımsız olarak uygulamalıdır.
Ölçüm olmadan rollout, yalnızca gecikmiş yayındır
Yeni özelliği yüzde 5 kullanıcıya açmak ancak etkisini izleyebiliyorsanız anlamlıdır. Yayın öncesinde birkaç temel gösterge seçin: hata oranı, gecikme, iş tamamlama oranı, destek talebi, dönüşüm veya kullanıcı tarafından vazgeçilen akış sayısı. Yapay zekâ özelliklerinde maliyet, ret oranı ve güvenlik ihlali sinyalleri de eklenebilir.
Metriklerde bayrak adı veya sürümü sınırlı bir etiket olarak yer alabilir. Böylece yeni yolun eski davranıştan farkı karşılaştırılabilir. Ancak kullanıcı kimliği gibi yüksek kardinaliteli değerleri metric etiketi yapmamak gerekir; ayrıntılı teşhis için trace ve yapılandırılmış log kullanılmalıdır.
Rollout adımları için önceden karar kuralı belirlemek de faydalıdır. Örneğin hata oranı belirli eşiği aşarsa bayrak kapatılır, olumlu sinyal birkaç gün korunursa kapsam genişletilir. Bu kurallar kusursuz otomasyon olmak zorunda değildir; ama sorun anında “ne yapmalıyız?” tartışmasını kısaltır.
Geri alma düğmesi hızlı ve güvenilir olmalı
Bir kill switch, hızlı geri alma imkânı için kullanılır. Bunun değerli olabilmesi için bayrak güncellemesinin uygulamaya ne kadar sürede ulaştığını bilmek gerekir. Konfigürasyon önbelleği çok uzunsa bayrağı kapatmak dakikalarca etkisiz kalabilir. Kritik akışlarda kısa TTL, bildirimli önbellek temizleme veya sunucu tarafında anlık değerlendirme gerekebilir.
Geri alma ayrıca bağımlılıkları hesaba katmalıdır. Frontend yeni bir API alanı bekliyorsa yalnızca sunucudaki bayrağı kapatmak sayfayı bozabilir. Rollback planı, hangi sürümlerin birlikte çalıştığını ve hangi davranışın güvenli varsayılan olduğunu tanımlamalıdır.
Bayrak değişiklikleri de denetlenmelidir. Kim, ne zaman, hangi hedefleme kuralını ve hangi gerekçeyle değiştirdi? Özellikle fiyat, yetki, kişisel veri veya kullanıcı deneyimini etkileyen bayraklarda audit kaydı önemli bir korumadır.
Bayrak borcunu düzenli temizleyin
Bayraklar uzun süre kaldığında kodu anlamayı zorlaştırır. Bir özelliğin eski ve yeni yolu, test senaryolarını ve olası durumları katlar. Geçici rollout bayrağı kalıcı yapılandırmaya dönüşmedikçe, başarılı yayın sonrasında kaldırılmalıdır.
Her bayrak için sahip, oluşturulma tarihi ve son gözden geçirme zamanı tutmak bu temizliği kolaylaştırır. Süresi geçen bayraklar için uyarı üretmek, kullanılmayan dalları ve artık geçerli olmayan hedefleme kurallarını görünür kılar. Testlerde bayrağın açık ve kapalı yolu en azından kritik akışlarda kapsanmalıdır; yalnızca açık yol test edilirse geri alma anında sürpriz yaşanır.
Özellik bayrakları daha sık yayın yapmanın bahanesi değildir. Kod kalitesi, test, güvenlik incelemesi ve veri migration disiplini hâlâ gereklidir. Ancak bunlar yerindeyken bayraklar, büyük bir “herkese aç” anını ölçülebilir, geri alınabilir ve kullanıcı etkisine duyarlı küçük adımlara böler.