Feature Flag Kullanımı
Selamlar,
Bu yazımda sizlere Feature Flag’leri sistematik haliyle anlatacağım. Eminim birçoğunuzun çeşitli projelerde kullandığı ve uyguladığı noktalar da olmuştur.
Temel olarak “Feature Flag” bir feature’ın, ürüne ait bir özelliğin kullanıcıya gösterilmesine karar veren mekanizmadır diyebiliriz.
Feature Flag’lerin amacından bahsetmek gerekirse, amaç deployment’larla yayına alacağımız “feature”ları birbirinden ayırmak.
Ne zaman kullanılabilir?
- Aslında daha çok bir feature’un farklı versiyonlarını devreye almak istediğimizde, A/B testing yaparken
- Yayına alınacak özellik büyük kitlelerce kullanıma daha hazır değilken
- Yeni özelliği sadece belli bir kitleye ya da gruba açmak istediğimizde
feature flag kullanımı söz konusu olabilir.
Günümüzde Microsoft, Facebook, Instagram, Netflix, Reddit gibi birçok büyük şirket tarafından farklı özellikleri denemek, kullanıcıların reaksiyonlarını görmek ve ürün özelliklerine karar vermek amacıyla kullanımı var. Feature flag’ler sayesinde farklı feature’ları ayrı deployment’lar yapmadan görebiliyorlar.
Synonyms
Feature Flags, Feature Toggles, Feature Controls, Flippers
Aslında Feature Flag’leri basit if-else statement’lar olarak düşünebiliriz. Belli koşullara göre hangi seçeneğin müşteriye gösterileceği belirlenebilir.
if(condition1)
then option1
else if(condition2)
then option2
else option3
....Basit gibi gözükse de kurumsal seviyede düşünürsek bazen bir özelliğin gösterilme durumu daha kompleks olabilir. Ya da bir özelliğin gösterilme durumları başka diğer özelliklere de bağlı olabilir.
Feature Flag Tipleri
Feature flag’ler birkaç kategoriye ayrılabilir. Bunlar flag’in ne kadar yaşayacağına ve ne kadar sıklıkla değişime ihtiyaç duyacağına (statik ya da dinamik) göre değişir.
Release Toggles
Continuous Delivery yapan takımlar için release amaçlı on/off toggle’ları bu kategoridedir. Kısa süreli yaşayan statik flag’lerdir, statik olduğu için değişime uğramazlar.
Experiment Toggles
Adı üzerinde “deneysel”dirler. Değişik varyasyonları denemek için veya A/B testing için kullanılan kısa süreli ama dinamik toggle’lardır. Yani sürekli toggle ile değişiklik yapılabilir.
Ops Toggles
Yeni bir özelliği çıkarken emin olmadığımızda (örneğin performansından) sistem operatörleri tarafından gerektiğinde hızlıca disable edilebilecek flag’lerdir. Uzun süreli yaşayacak bu flag’ler dinamiktir.
Permissioning Toggles
Belli kitlelere açmak ve belli kitlelere sunulan özellikleri değiştirmek istediğimizde kullanılan, uzun süreli yaşayan ve dinamik toggle yapılarıdır.
Feature Flag’leri Kodda Nereye Koymalıyız?
Feature flag’leri kodda uygularken öncelikle “toggling mekanizması”nın nerede durması gerektiğine karar vermemiz gerekir.
İlgili makalede anlatıldığı ve yukarıdaki görselde de görüldüğü üzere burada iki yaklaşım olabilir.
Front-end
Bir web uygulamasında tarayıcıdaki JavaScript kodunda, ya da bir mobil uygulamada “toggling mekanizması”nın durması front-end yani client mekanizmaya örnektir. Bu durumda “feature flag”ler kullanıcının doğrudan eriştiği noktada olur.
Avantajları: Zaten kompleks workflow’larla uğraşan back-end taraftaki karmaşıklıktan toggling’i uzak tutmak, back-end yazılımcılarının işini kolaylaştırır.
Dezavantajları: Güvenlik kaygısı diyebiliriz. Kötü niyetli kullanıcının araya girip toggling’e müdahale etme durumu client’a koyduğumuz bir mekanizmada daha olasıdır. Böylece kullanıcı belki görmemesi gereken bir özelliği görebilir hale gelebilir.
Back-end
“Toggling mekanizması”nı back-end’e koyduğumuzda tüm kararlar back-end’te alınır.
Avantajları: Avantajları front-end’in dezavantajına karşılık olarak, kullanıcının erişemediği noktada olduğu için araya girmenin önüne geçmiş olmaktır. Güvenlik anlamında daha avantajlı ve mantıklıdır.
Dezavantajları: Back-end tarafta karmaşıklığı iyice artırmış olur. Toggling’i bu sefer back-end’te hangi katmana koymak gerektiği sorunu ortaya çıkar. Data katmanına mı, istekleri karşılayan REST handler’a mı, yoksa başka katmana mı? En sonunda feature flag’i tüm katmanlar arası geçirmeye karar verirsek karmaşıklığı en üst seviyeye çıkarabiliriz.
Feature Flag Konfigürasyonları
Hangi özelliklere toggle koyacağımıza karar verdik. Koşullarına karar verdik. Feature flag’lerin hangi tarafta front-end’te mi yoksa back-end’te mi duracağına da karar verdik. Şimdi sırada konfigürasyonunun nasıl olacağı, konfigürasyon dosyasının nerede durması gerektiğine karar verme kısmı var.
Gömülü (embedded) Konfigürasyon
En hızlı ama kirli bir çözüm olan bu konfigürasyon yönteminde hardcoded bir şekilde kodun içinde duran boolean alanlarla feature flag uygulanır. Değişiklik durumunda deployment gerekir. Uzun soluklu işlerde kullanılamaz bir konfigürasyon olarak düşünebiliriz.
Dahili (internal) Konfigürasyon Dosyası
Uygulamanın içinde duran internal bir konfigürasyon dosyasında kuralları tutma yöntemidir. Uygulama deploy olurken ilk başta okunur. Küçük kural setine göre uygulanabilir belki ama flexible yani esnek bir çözüm değildir. Kural seti değiştiğinde nihayetinde deployment gerektirir.
Harici (external) Konfigürasyon Dosyası
Uygulamanın içindeki konfigürasyon dosyasını dışarıya alma olarak düşünebiliriz. Erişilebilir bir url’den konfigürasyonlar alınabilir. Belli periyotlarla burayı yenileyip okuyarak feature flag’ler uygulanabilir. Online konfigürasyon dosyasını okuyamadığımız durum için default davranışı kod içinde belirtmemiz gerekir.
Servis Sağlayıcılar
Harici konfigürasyon dosyasında dinamikliği deployment olmadan sağlayabilirz. Ama yine de erişim, içerik, yeni konfigürasyonların yönetimi gibi konular uygulama tarafında olur. Bunun yerine bu işi yapan servis sağlayıcılar mevcut, LaunchDarkly ve Optimizely gibi. Bu tarz servisler daha büyük ölçekte feature’ları ve koşulları yönetip istatistikler çıkarabilirler. Özet ekranlarıyla da ürüne ait bilgileri detaylı sunabilirler.
Uygulamadaki ihtiyaca göre yukarıdaki konfigürasyon yöntemlerinden seçim yapılabilir.
Kritik yapıp toparlamak gerekirse;
Düzgün yönetildiğinde, düzgün bir şekilde mekanizma ve konfigürasyonlara karar verildiğinde feature flag’ler yeni özellikleri hızlı çıkmak için çok faydalı olabilir. On/off ve release mekanizmalarını yönetmek anlamında da perfect fit diyebileceğimiz durumlarda hayat kurtarabilir.
Ama, kontrolsüz bir şekilde plansızca konulan feature flag’ler de spaghetti’ye sebep olabilir, dikkat etmek gerekir.
Günün sonunda feature flag’ler “teknik borç” yaratır. İşimiz bittiğinde, artık özellikleri oturtup olgunlaştırdığımızda silmemiz gerekir.
Bir diğer konu da etik meselesi. Kitlelerde denemek için kullanıldığında özelliğin neye göre ve kime çıkarılacağı konusunda etik olarak dikkat etmek gerekir.
Feature flag’ler aslında bir “deployment çözümü” olarak uygulanmamalı. Test edilmemiş, dahili test prosedürlerinden geçmeyen kodu bu flag’lerle canlıya almamak gerekir.
Umarım keyifli bir okuma olmuştur. Hoşçakalın :)
