Feature Flag Nedir? Özellikleri Kodu Yeniden Yayınlamadan Açıp Kapatma

Feature flag nedir?

Feature flag (özellik bayrağı), bir yazılım özelliğini kodu yeniden dağıtmadan açıp kapatmanızı sağlayan koşullu anahtardır. Uygulama, özelliği çalıştırıp çalıştırmayacağına yapılandırmadaki bir değere bakarak karar verir. Böylece özellik canlı kodun içinde kapalı bekler, hazır olduğunuzda tek bir ayar değişikliğiyle açarsınız.

Bir evin elektrik tesisatını düşünün. Kablolar duvarın içine önceden döşenmiştir ve lambalar bağlıdır. Ancak anahtara basmadan ışık yanmaz. Feature flag tam olarak bu anahtardır: kod çoktan yerindedir, ışığı ne zaman yakacağınıza sonradan karar verirsiniz.

Sektörde aynı kavram için feature toggle ve feature switch adlarını da duyarsınız. Üçü de aynı fikri anlatır. Bu yazıda feature flag nedir sorusunu kavram düzeyinde ele alıyoruz; türlerini, risklerini ve temizleme alışkanlığını birlikte inceliyoruz.

Feature flag nedir ve dağıtım ile yayın neden ayrı şeylerdir?

Geleneksel yazılım akışında iki olay aynı anda gerçekleşir. Kodu sunucuya taşırsınız, aynı saniyede kullanıcılar yeni özelliği görür. Feature flag bu iki olayı birbirinden ayırır.

Dağıtım (deploy), kodu canlı ortama taşımaktır. Yayın (release), özelliği gerçek kullanıcılara açmaktır. Flag varken önce dağıtım yaparsınız; özellik kapalı olduğu için kullanıcı hiçbir şey fark etmez. Yayın kararını daha sonra, hazır olduğunuzda verirsiniz.

Bu ayrımın üç somut sonucu vardır:

• Dağıtım sıradanlaşır, çünkü kullanıcıya görünen bir değişiklik içermez.
• Ürün ekibi yayın zamanını mühendislik takviminden bağımsız seçer.
• Sorun çıkarsa kodu geri almak yerine bayrağı kapatırsınız.

Dolayısıyla "Cuma akşamı yayın yapmayalım" refleksi zayıflar. Çünkü riskli olan an, kodun sunucuya inmesi değil, özelliğin açılmasıdır ve açma kararı artık sizin elinizdedir. Konteyner ve altyapı tarafına aşinaysanız Docker ve konteyner mantığını anlattığımız yazıya de göz atabilirsiniz.

Feature flag nedir ve kodda nasıl çalışır?

Mantık basittir: kod bir bayrağa soru sorar, bayrak bir değer döndürür, kod da bu değere göre iki yoldan birini izler. Yeni yol kapalıyken eski davranış aynen çalışmaya devam eder.

Bu akışta birkaç temel parça vardır. Bayrak anahtarı (flag key), bayrağın adıdır. Varsayılan değer, değer okunamadığında devreye giren güvenli seçimdir. Değerlendirme bağlamı (evaluation context), kullanıcı kimliği, ülke ya da paket türü gibi karar için gereken bilgilerdir. Kurallar, hangi bağlamın hangi değeri alacağını belirler.

Çalışma akışını beş adımda özetleyebiliriz:

1. Kod, bayrak anahtarını ve varsayılan değeri vererek soru sorar.
2. Değerlendirici, kullanıcı ya da istek bağlamını alır.
3. Değerlendirici, tanımlı kurallara bakar.
4. Bir değer döner: açık, kapalı, bir metin ya da bir sayı.
5. Kod, dönen değere göre yeni ya da eski yolu çalıştırır.

Kurallar bir yapılandırma dosyasında, bir veritabanında ya da özel bir yönetim panelinde durabilir. Önemli olan, değerin kod yeniden dağıtılmadan değişebilmesidir. Örneğin yönetim panelinde bir kutuyu işaretlediğinizde birkaç saniye içinde tüm sunucular yeni değeri görür.

Kodda bir tasarım ilkesi de işinize yarar: bayrak kararını kodun dağınık yerlerinde değil, tek bir noktada verin. Yani "bayrak açık mı?" sorusunu bir kez sorun, cevabı ilgili bileşene bir davranış olarak iletin. Böylece aynı bayrağı yirmi farklı dosyada aramak zorunda kalmazsınız. Ayrıca bayrağı kaldırma günü geldiğinde değişiklik küçük ve öngörülebilir olur.

Feature flag türleri nelerdir?

Her bayrak aynı işi yapmaz. Martin Fowler'ın feature toggle makalesindeki sınıflandırma, bayrakları amacına ve ömrüne göre dört gruba ayırır. Ekiplerin çoğu bu dörtlüyü ortak dil olarak kullanır.

• Yayın bayrağı (release toggle): Yarım kalmış özelliği canlı kodda gizli tutar. Genellikle kısa ömürlüdür.
• Deney bayrağı (experiment toggle): Kullanıcıları gruplara ayırıp A/B testi yürütür. Sonuç netleşince bayrağı silersiniz.
• Operasyonel bayrak (ops toggle): Sistem davranışını işletme sırasında değiştirir. Bir kısmı kill switch olarak kalıcı olur.
• İzin bayrağı (permissioning toggle): Özelliği belirli kullanıcı grubuna açar, örneğin beta kullanıcılarına ya da üst pakete. Uzun yıllar yaşayabilir.

Aşağıdaki tablo dört türü yan yana koyar. Sütunlardaki ömür ve karar sıklığı, bayrağı ne zaman temizleyeceğinizi planlamanıza yardım eder.

Bu ayrım pratikte çok işe yarar. Çünkü her tür farklı bir sahip, farklı bir temizleme takvimi ve farklı bir test yaklaşımı ister.

Bayrak yalnızca açık ya da kapalı mıdır, başka değer tipleri var mıdır?

Hayır, bayraklar her zaman ikili değildir. En yaygın biçim mantıksal değerdir: açık ya da kapalı. Ancak birçok sistem metin, sayı ve nesne değerlerini de destekler.

Bu esneklik farklı ihtiyaçlara cevap verir. Örneğin bir metin değeri, bir ekranın hangi düzen varyantını göstereceğini söyler. Bir sayı değeri, sayfa başına ürün adedi gibi ayarlanabilir bir eşiği taşır. Bir nesne değeri ise birkaç ayarı tek pakette getirir.

Çok değerli bayrak, deneylerde özellikle işe yarar. Çünkü üç ya da dört farklı varyantı aynı bayrakla yönetirsiniz. Böylece her varyant için ayrı bayrak açmak zorunda kalmazsınız.

Bununla birlikte basit tutmak değerlidir. Açık ya da kapalı bir bayrak anlamak, test etmek ve silmek açısından en kolay olandır. Çok değerli bayrağı yalnızca gerçekten varyant gerektiğinde seçin; böylece kodunuz okunaklı kalır. OpenFeature belgeleri de dört tipli değerlendirme tanımlar ve her çağrıda varsayılan değer vermenizi bekler.

Yayın bayrağı ve izin bayrağı ne zaman işe yarar?

Yayın bayrağı, ekibin ana koda sık sık birleştirme yapmasına izin verir. Büyük bir özelliği haftalarca ayrı dalda tutmak yerine küçük parçalar halinde ana koda eklersiniz. Parçalar bayrak arkasında gizli kaldığı için yarım iş kullanıcıya sızmaz.

Ekipler buna "trunk tabanlı geliştirme" der. Yani herkes tek bir ana hatta çalışır. Birleştirme çatışmaları azalır, çünkü dallar uzun süre birbirinden uzaklaşmaz.

İzin bayrağı ise bambaşka bir sorunu çözer: kimin neyi göreceği. Örneğin yeni bir raporlama ekranını önce yalnızca iç ekibe, sonra beta listesine, en sonunda üst pakete açabilirsiniz. Üstelik bunun için her grup başına ayrı kod sürümü tutmazsınız.

Şuna dikkat edin: izin bayrağı uzun süre kalır, yani başlı başına bir ürün kuralı olur. Böyle bayrakları geçici bayraklardan ayrı etiketleyin ve belgeleyin.

Deney bayrağı ve kill switch nasıl farklı çalışır?

Deney bayrağı, aynı kullanıcıyı her seferinde aynı gruba atar. Örneğin kullanıcıların yarısı yeni sepet düzenini görür, diğer yarısı eskisini. Sonra iki grubun davranışını karşılaştırırsınız. Sonuç istatistiksel olarak anlamlı olmadan karar vermemek gerekir; bunun için A/B testi hesaplama aracımızı kullanabilirsiniz.

Kill switch ise bir acil durum şalteridir. Örneğin bir dış hizmet yavaşladığında, o hizmete bağlı ikincil özelliği kapatırsınız. Ana akış çalışmaya devam eder, yalnızca ek özellik geçici olarak devre dışı kalır. Buna zarif bozulma (graceful degradation) denir.

İki tür arasındaki fark hızda yatar. Deney bayrağını önceden planlar, sonucu sabırla izlersiniz. Kill switch ise kriz anında, saniyeler içinde çevrilmelidir. Bu yüzden kill switch bayrağının yönetim ekranına erişim yetkisi net olmalı ve sistem yük altındayken de çalışmalıdır.

Aşamalı yayın ve kanarya yayını nedir?

Aşamalı yayın (gradual rollout), özelliği tüm kullanıcılara tek seferde açmak yerine küçük bir yüzdeyle başlatıp adım adım büyütmektir. Önce iç ekip, ardından küçük bir kullanıcı dilimi, sonra herkes. Her adımda metrikleri izler, sorun görmezseniz bir sonrakine geçersiniz.

Kanarya adı, madencilerin eskiden kafeslerdeki kanaryalarla havayı denemesinden gelir. Kanarya sorun işaretini herkesten önce verir. Küçük kullanıcı dilimi de yeni özelliğin kanaryasıdır: bir sorun varsa az sayıda kişi zarar görür.

Burada sık yapılan bir karışıklığı düzeltelim. Kanarya dağıtımı (canary deployment) altyapı seviyesinde, trafiğin bir kısmını yeni sürüme yönlendirir. Feature flag ise uygulama içinde, özelliği kullanıcıya göre açar. İkisi birlikte de kullanılabilir.

Aşamalı yayın için izleme şarttır. Hata oranı, yanıt süresi ve iş metrikleri görünmüyorsa yüzdeyi artırmak kördövüşüdür. İzleme tarafını observability ve OpenTelemetry yazımızda ayrıca ele alıyoruz.

Bir ayrıntı daha var: yüzdeyi kullanıcı kimliğine göre sabit bölün. Aksi halde aynı kişi bir sayfayı yenilediğinde bir görünüp bir kaybolan özellikle karşılaşır. Tutarlı bölme hem kullanıcı deneyimini korur hem de ölçümlerinizi temiz tutar. Üstelik her adımda ne kadar beklemeniz gerektiğini önceden yazın; yetersiz örneklemle yapılan bir "her şey yolunda" kararı yanıltıcı olabilir.

Feature flag kullanmanın faydaları nelerdir?

Feature flag'in değeri, riski küçük parçalara bölmesinden gelir. Büyük bir yayın yerine, her biri tek başına geri alınabilen küçük kararlar alırsınız.

• Küçük risk: Sorun çıkarsa bayrağı kapatırsınız, yeni dağıtım beklemezsiniz.
• Erken geri bildirim: Özelliği az sayıda gerçek kullanıcıyla erken denersiniz.
• Kolay birleştirme: Yarım iş ana kodda gizli durur, dallar uzamaz.
• Takvim esnekliği: Pazarlama kampanyası ya da etkinlik günü gibi bir anı mühendislikten bağımsız seçersiniz.
• Kontrollü deney: Karar tahmine değil veriye dayanır.

Ayrıca bayrak, ekipler arasında ortak bir dil sağlar. Ürün yöneticisi "yüzde on açalım" der, mühendis tek ayarla uygular. Agile ve Scrum yazımızda anlattığımız kısa döngüler, bayrakla daha da güvenli hale gelir.

Yine de bu faydalar otomatik gelmez. Bayrağı düzenli yönetmezseniz fayda yerine yük birikir. Dolayısıyla bayrağı bir ürün özelliği gibi değil, bakımı gereken bir araç gibi düşünün.

Feature flag hangi riskleri getirir?

Her bayrak kodda yeni bir dal demektir. Bu yüzden kolay açılan bayrak, zamanla pahalı bir yük haline gelebilir. En sık gördüğümüz riskleri sıralayalım:

• Bayrak borcu: Görevini bitirmiş ama kodda kalmış bayraklar kodu karmaşıklaştırır.
• Test karmaşıklığı: Bayrak sayısı arttıkça denemeniz gereken kombinasyon sayısı hızla artar.
• Yetki ve güvenlik: Herkes bayrağı çevirebiliyorsa yanlışlıkla canlı özelliği kapatabilir.
• Gecikme: Her istekte uzak bir servise sormak yanıt süresini uzatabilir.
• Yanlış bağlam: Kullanıcı kimliğini eksik gönderirseniz deney gruplarınız karışır.

Bu risklerin hiçbiri bayrak fikrini geçersiz kılmaz. Ancak her biri için bir önlem planlamak gerekir. Kullanıcı verisiyle çalışıyorsanız ayrıca KVKK ve GDPR uyumlu web sitesi yazımıza bakın; çünkü değerlendirme bağlamına kişisel veri koymak ayrı bir sorumluluk doğurur.

Bayrak yetkilerini ve güvenliği nasıl yönetirsiniz?

Bayrak paneli aslında canlı sistemin uzaktan kumandasıdır. Bu yüzden panele erişimi, üretim veritabanına erişim kadar ciddiye almak gerekir. Yanlış bir tıklama, çalışan bir özelliği herkes için kapatabilir.

Basit ama etkili bir yetki yaklaşımı şunları içerir:

• Üretim ortamındaki bayrakları değiştirme yetkisini az sayıda kişiyle sınırlayın.
• Her değişikliği kim, ne zaman, hangi değerle yaptı diye kayıt altına alın.
• Geliştirme, test ve üretim ortamlarını ayrı bayrak kümeleriyle yönetin.
• Kritik bayraklar için ikinci bir kişinin onayını isteyin.

Ayrıca değerlendirme bağlamında yalnızca gerekli bilgiyi taşıyın. Çoğu karar için kullanıcı kimliği ya da paket türü yeter; ad, e-posta ya da telefon gibi kişisel verilere ihtiyaç duymazsınız. Dolayısıyla bayrak sistemi gereksiz yere kişisel veri havuzuna dönüşmez.

Son olarak kill switch gibi acil bayraklar için, ana bayrak servisi çökse bile çalışacak bir yedek yol düşünün. Çünkü kriz anında kapatmak istediğiniz şey bayrak servisinin kendisi olabilir.

Bayrağa kim karar verir ve rolleri nasıl paylaştırırsınız?

Teknik olarak bayrağı mühendis ekler, ama açma kararı çoğu zaman mühendisin değildir. Bu yüzden rolleri baştan netleştirmek gerekir. Aksi halde bayrak, kimsenin sahiplenmediği bir ayar yığınına döner.

Pratikte şöyle bir dağılım işe yarar:

• Mühendis: Bayrağı koda ekler, test eder, varsayılan değeri belirler ve silme görevinin sorumluluğunu alır.
• Ürün yöneticisi: Hangi kullanıcı diliminin ne zaman göreceğine ve başarı ölçütüne karar verir.
• Kalite sorumlusu: Açık ve kapalı durumun testini onaylar.
• İşletme ya da destek ekibi: Kill switch gibi acil bayraklar için çalışma kitabını bilir.

Bu dağılım küçük ekiplerde tek kişide toplanabilir. Yine de rolleri yazıya dökmek önemlidir; çünkü "kim kapatabilir?" sorusu kriz anında tartışılmamalıdır.

Ayrıca sprint planlamasında bayrak işlerini ayrı kalemler olarak yazın. Bayrağı eklemek de, silmek de bir iştir ve zaman ister. Agile yöntemlerindeki iş listesi mantığı bu işlerin unutulmamasına yardım eder.

Bayrak borcunu nasıl önlersiniz ve eski bayrakları nasıl temizlersiniz?

Fowler'ın makalesi bayrakları bir envanter gibi görmeyi önerir: her bayrağın taşıma maliyeti vardır. Bu yüzden temizlik, işin sonunda akla gelen bir lüks değil, bayrağı açarken yapılan bir taahhüttür.

Basit bir temizleme politikası şöyle işler. Önce kimin sorumlu olduğunu, sonra ne zaman biteceğini yazarsınız:

1. Bayrağı oluştururken bir sahip ve bir hedef bitiş tarihi yazın.
2. Bayrağın türünü etiketleyin; böylece beklenen ömrü belli olur.
3. Bayrakla birlikte, kaldırma görevini de iş listesine ekleyin.
4. Özellik tamamen yayına çıkınca eski yolu ve bayrağı birlikte silin.
5. Düzenli aralıklarla bayrak envanterini gözden geçirin.
6. Süresi dolan bayraklar için otomatik uyarı ya da başarısız test ("zaman bombası") ekleyin.

Bazı ekipler aktif bayrak sayısına üst sınır koyar. Yeni bayrak eklemek için eskisini silmek gerekir. Kural sert görünse de bayrak borcunu gerçekten durdurur.

Kalıcı bayrakları (izin bayrakları, kill switch) bu silme döngüsünün dışında tutun. Onları "uzun ömürlü" diye etiketleyip ayrı bir listede izleyin.

Feature flag, dal stratejisi ve mavi-yeşil dağıtım arasındaki fark nedir?

Üç yaklaşım da riski yönetmeye çalışır, fakat farklı katmanlarda çalışır. Bu yüzden rakip değil, tamamlayıcıdır. Aşağıdaki tablo farkı gösterir.

Dal stratejisi, kodun nerede yaşadığını belirler. Mavi-yeşil dağıtım iki özdeş ortam kurar ve trafiği birinden diğerine çevirir. Feature flag ise tek bir ortamda, tek bir özelliği hedef alır. Git tarafındaki dal mantığını hatırlamak isterseniz Git ve GitHub rehberimizi okuyabilirsiniz.

Pratikte olgun ekipler üçünü bir arada kullanır. Örneğin sürümü mavi-yeşil ile değiştirir, içindeki riskli özelliği ise bayrakla kapalı tutar.

Feature flag ne zaman işinize yaramaz?

Her değişiklik için bayrak eklemek de bir hatadır. Küçük bir metin düzeltmesi ya da stil değişikliği için bayrak koymak, kazandırdığından fazla karmaşıklık getirir.

Şu durumlarda dikkatli olun:

• Veritabanı şeması değişiklikleri: Bayrak yalnızca kodu kapatır, veriyi geri çevirmez. Geriye uyumlu, adım adım geçiş planlayın.
• Güvenlik düzeltmeleri: Açığı kapatan değişikliği "isteğe bağlı" yapmayın.
• Basit sabit ayarlar: Hiç değişmeyecek değerler için ortam yapılandırması yeterlidir.
• Çok kısa ömürlü işler: Aynı gün çıkıp biten değişiklikte bayrak gereksiz yük olur.

Genel kural şudur: bayrağın cevap vereceği net bir soru yoksa eklemeyin. Soru "bunu kademeli açmak, test etmek ya da hızlı kapatmak istiyor muyuz?" ise bayrak mantıklıdır.

OpenFeature nedir ve feature flag için neden önemlidir?

OpenFeature, bayrak yönetim araçlarından bağımsız çalışan, açık bir standart API'dir. Resmi belgelerine göre CNCF (Cloud Native Computing Foundation) çatısı altında bir projedir; olgunluk seviyesini CNCF proje sayfasından kontrol edebilirsiniz.

Amacı basit: bayrak aracını değiştirseniz bile uygulama kodunuzu yeniden yazmak zorunda kalmamanız. Standart şu kavramlardan oluşur:

• Değerlendirme API'si (evaluation API): Uygulamanın bayrağa soru sorduğu arayüzdür.
• Değerlendirme bağlamı (evaluation context): Karar için gereken verilerin taşıyıcısıdır.
• Sağlayıcı (provider): Standart çağrıyı seçtiğiniz bayrak sistemine çeviren katmandır.
• Kancalar (hooks): Değerlendirme sürecine doğrulama, günlük ya da izleme gibi davranışlar ekler.
• Olaylar (events): Sağlayıcı durumunun ya da bayrak yapılandırmasının değiştiğini bildirir.

Şartname ayrıca güvenli bir tasarım ilkesi koyar: tipli değerlendirme (mantıksal, metin, sayı, nesne) her zaman bir varsayılan değer ister. Değerlendirme başarısız olursa uygulama çökmez, varsayılan değer döner. Kaynaklar için OpenFeature resmi tanıtımı ve CNCF proje sayfası iyi başlangıçtır.

Bayrak yönetimini kendiniz mi kurmalısınız, hazır servis mi kullanmalısınız?

Bayrak mantığı, en basit halinde bir yapılandırma dosyasıyla başlar. Küçük bir ekip için ortam değişkeni ya da bir JSON dosyası yeterli olabilir. Ancak ihtiyaç büyüdükçe bu çözüm yetmez.

Şu işaretler, daha olgun bir yönetim katmanına geçme zamanının geldiğini gösterir:

• Teknik olmayan ekip üyeleri bayrağı kod değiştirmeden çevirmek istiyor.
• Yüzde bazlı yayın ya da kullanıcıya özel kural gerekiyor.
• Kimin neyi ne zaman değiştirdiğini kayıt altına almanız gerekiyor.
• Birden fazla uygulama ve dil aynı bayrakları paylaşıyor.

Seçenekleri genel olarak üç gruba bölebiliriz: kendi yazdığınız basit çözüm, açık kaynak bir yönetim sistemi ya da ücretli hazır bir servis. Her birinin bakım yükü, maliyeti ve esnekliği farklıdır. Bu yüzden belirli bir ürünü önermiyor, seçim ölçütlerini veriyoruz.

Ölçütleriniz arasında şunlar olmalı: gecikme etkisi, çevrimdışı çalışma davranışı, yetki ve denetim kaydı, veri konumu ve standartlara uyum. Üstelik OpenFeature gibi bir standart katmanı kullanırsanız, bu seçimi ileride değiştirmek çok daha kolay olur. Fiyat ve özellik karşılaştırması için her sağlayıcının güncel resmi belgesine bakın.

Feature flag nedir sorusu gerçek bir senaryoda nasıl somutlaşır?

Feature flag nedir sorusunu somutlaştırmak için bir örnek senaryo kuralım. Bir e-ticaret ekibi yeni bir sepet sayfası geliştiriyor. Kod haftalar içinde küçük parçalarla ana hatta birleşiyor, ama sepet bayrağı kapalı olduğu için müşteriler eski sayfayı görmeye devam ediyor.

Yayın günü ekip şu sırayı izliyor:

1. İç ekip için bayrağı açıyor ve sepeti elle deniyor.
2. Küçük bir müşteri dilimine açıyor; hata ve terk oranını izliyor.
3. Sorun görmezse dilimi adım adım büyütüyor.
4. Bir sorun çıkarsa bayrağı kapatıp eski sepete dönüyor.
5. Herkes yeni sepeti kullanınca eski kodu ve bayrağı siliyor.

Bu sırada kimse yeniden dağıtım yapmaz. Ayrıca satış ekibi kampanya gününe kadar sepeti kapalı tutmak isterse, karar yine bir ayar meselesidir.

Böyle bir akışta geri alma işlemlerinin güvenli olması gerekir. Aynı işlemin iki kez çalışması sorun çıkarmasın diye idempotency yazımızı da inceleyin.

Feature flag'li kodu nasıl test edersiniz?

Feature flag nedir sorusunu öğrendikten sonra ilk gündem maddesi testtir. Bayrak ekleyince test uzayı büyür. Her bayrak, kodun iki ayrı davranış göstermesi demektir. Dolayısıyla "hangi durumu test ediyoruz?" sorusunu açıkça yanıtlamanız gerekir.

Fowler'ın önerisi basittir: en azından hedeflenen canlı durumu ve geri dönüş (fallback) durumunu test edin. Çoğu bayrak birbirinden bağımsızdır, bu yüzden tüm kombinasyonları denemek gerekmez. Etkileşen bayrakları ise birlikte test edin.

• Bayrak açıkken ve kapalıyken ana senaryoyu çalıştırın.
• Bayrak değeri okunamadığında varsayılan davranışı doğrulayın.
• Aynı kullanıcının her seferinde aynı gruba düştüğünü kontrol edin.
• Bayrak kaldırıldığında eski yolun gerçekten silindiğini doğrulayın.

Yayın öncesi kontrollerinizi bir listeye bağlarsanız hata payı düşer. Bu konuda web sitesi yayın öncesi test ve kalite kontrol listemiz size hazır bir iskelet verir.

Feature flag, yapay zekâ destekli kod ve gözlemlenebilirlik nasıl birlikte çalışır?

Yapay zekâ ile hızlı kod üretmek, henüz doğrulamadığınız kodun canlıya yaklaşması demektir. Böyle değişiklikleri bayrak arkasına koymak güvenli bir tampon sağlar. Konuya yaklaşımımızı vibe coding yazımızda anlattık; burada yalnızca bayrağın rolüne değiniyoruz.

Gözlemlenebilirlik ise bayrağın gözleridir. Bir bayrağı açtığınızda hata oranı, gecikme ve iş metrikleri değişiyorsa bunu görmeniz gerekir. Bayrak değerini günlüklere ve izlere etiket olarak eklerseniz, sorunun hangi bayrak durumunda başladığını hemen bulursunuz.

OpenFeature'ın kancaları tam bu iş içindir. Değerlendirme anında günlük ya da telemetri eklemenize izin verir. Yani bayrak kararı ile ölçüm arasındaki bağ kopmaz.

Kısacası üçlü şöyle çalışır: bayrak riski sınırlar, izleme etkiyi gösterir, kod gözden geçirme de kalite çıtasını korur.

Feature flag için pratik kontrol listesi nedir?

Bir bayrağı canlıya almadan önce aşağıdaki soruları yanıtlayın. Hepsine "evet" diyemiyorsanız bayrak henüz hazır değildir.

• Bayrağın bir sahibi ve açık bir adı var mı?
• Varsayılan değer güvenli tarafta mı?
• Bayrağın türünü ve beklenen ömrünü etiketlediniz mi?
• Kapalı ve açık durumu test ettiniz mi?
• Kimin bayrağı değiştirebileceği ve bunun kaydı belli mi?
• Açıldığında hangi metrikleri izleyeceğiniz belli mi?
• Geri alma adımı yazılı mı?
• Silme görevini iş listesine eklediniz mi?
• Bağlama kişisel veri koymadan karar verilebiliyor mu?

Bu listeyi ekip wiki sayfanıza taşıyıp her yeni bayrakta kullanın. Böylece bayrak kültürü kişiye değil, sürece dayanır.

Feature flag kurulumunda ekibimizden nasıl destek alırsınız?

Talha Aslan ve ekibi olarak yazılım projelerinde bayrak yaklaşımını mimarinin baştan bir parçası yapmayı öneriyoruz. Hangi bayrağın geçici, hangisinin kalıcı olacağını, kimin yöneteceğini ve nasıl izleneceğini proje başında netleştiririz.

Mevcut bir uygulamaya bayrak eklemek de mümkündür. Önce riskli bir özellikle küçük başlamak en sağlıklı yoldur. Ayrıntı için özel yazılım geliştirme hizmet sayfamıza bakabilirsiniz.

Özetle feature flag nedir sorusunun cevabı, riski küçülten ve kararı size bırakan bir yayın anahtarıdır. Son olarak bir hatırlatma: bu yazı genel bilgi amaçlıdır. Araç seçimi, ücretler ve güncel özellikler değişebilir; bu nedenle güncel değeri her zaman ilgili sağlayıcının resmi belgesinden kontrol edin.