"Feature Flag" konusuna bir benzetme ile başlamak isterim. Evlerde ışıklar için açma kapama düğmeleri bulunur. Gereksiz ışıkların yanmasını önlemek için anahtarı kapatır, ihtiyacımız olan ışığa ait düğmeyi açarız. Enerji yönetimi de bu yolla yapılır.
"Feature Flag", uygulamalar için açma kapama düğmesidir.
Bir uygulamadaki herhangi bir özelliğin kullanılıp kullanılmayacağının ayarlanması için Feature Flag tekniği kullanılır. Kodu yayına alma sürecine gerek olmadan yazılımdaki herhangi bir davranışın çalışma zamanında, hızlı ve güvenli bir şekilde yönetilebilmesini sağlar.
Hangi durumlarda ihtiyaç duyulur?
- Özelliklerin A/B testi için
- Bazı özelliklerin ortamlara, kullanıcı gruplarına göre teste açılması
- Sistem trafiği konusundaki kritik durumları yönetmek için
- Canlı uygulama hayatına devam ederken operasyonel testlerin yapılabilmesi için
- Kod birleştirme süreçlerinde uzun süredir bekleyen kodların yönetimi için
Örnek bir hikaye
Stratejiler
-
Release Flags: Bir projede çalışan sayısının artması ve birbirinden bağımsız geliştirmelerin olması versiyon kontrol sistemindeki kod birleştirme (merging) süreçlerinin sancılı geçmesine neden olabilir. Bu nedenle; test edilmemiş veya tamamlanmamış özelliklerin üretim ortamına entegre edilmesine olanak tanır, böylece ekipler küçük ve sık güncellemeler yapabilir. Geliştirme tamamlanmamışsa ilgili flag kapalı kalacaktır. Hatta geliştirme tamamlandığında ilgili flag aktif edilebilir ya da sürecin tamamen bir parçası olmuşsa, flag kaldırılarak koddaki karmaşıklık azaltılır. Yaşam süresi açısından kısa ömürlü olan flagging stratejisidir.
-
Experiment Flags: Deneysel bir yaklaşımla, bir geliştirmenin farklı kullanıcı gruplarına göre farklı özellikler sunularak geri bildirim toplanır ve hızlı testler yapılır. Geri bildirimlere göre ek geliştirmeler ve iyileştirmeler için fırsat oluşur. Teste konu olan kullanıcı grupları değiştiğinden en dinamik olup kısa süreli yaşam süresine sahip olan flagging stratejisidir.
-
Ops Flags: Acil durumlar için operasyonel kontrolü sağlayacak devre kesicilere benzetilebilir. Uygulamadaki herhangi bir özellik, sistem üzerinde performansı veya güvenliği olumsuz etkiye sebep olursa, yetkili bir kişi tarafından kolaylıkla devre dışı bırakılabilir, sorunun tespitine istinaden güven duyulduğunda yeniden aktifleştirilebilir. Kill Switch olarak da denilen bu flag'ler, geçici ve acil durum için kullanılır ve kısa süreli olabilir. Yaşam süresi açısından aylara veya yıllara yayılabilen uzun ömürlü olan flagging stratejisidir.
-
Permission Flags: Uyguladaki belirli özelliklerin, belirli kullanıcı gruplarına veya segmentlerine göre erişimlerinin yönetilerek özelliklerin kademeli olarak sunulmasına yardımcı olur. Experiment Flag'lerden farkı, özelliklerin sunulacağı kullanıcı grupları bellidir. Bir ürünün standart planı veya daha üst özelliklere sahip pro planı olabilir. Bireysel veya kurumsal müşteriler için de farklı özellikler sunulabilir.
 |
Martin Fowler - Flags Strateji Yaşam Ömrü Dinamizim Grafiği - https://martinfowler.com/articles/feature-toggles.html |
Flag Yönetimi Yapılacak Konumun Karşılaştırılması - Benchmarking
Flaglerin nerede yönetilmesi konusunda alternatifler mevcuttur.
| Konum | Uygulanabilirlik | İstek Hızı | Caching | Güncellenme Hızı | Maliyet | Esneklik |
|---|---|---|---|---|---|---|
| Kodda | Kolay | Hızlı | Hızlı | Yavaş | Ücretsiz | Yüksek |
| Ortam değşişkenleri | Kolay | Hızlı | Hızlı | Yavaş | Ücretsiz | Düşük |
| Veri tabanları | Zor | Yavaş | Hızlı | Hızlı | Ücretsiz | Yüksek |
| 3. Parti Servisler | Kolay | Yavaş | Hızlı | Hızlı | Ücretli | Yüksek |
Seçenekler değerlendirildiğinde; veri tabanlarında flag değeri değiştirmek daha hızlı olmasına rağmen uygulamaya veri tabanı katmanı ve bağlantı kurulması gerektiğinden uygulanabilirlik zordur. Flag değerine ulaşmak için uygulama sunucusuna ek olarak veri tabanı sunucusuna istek gönderilmesi, ek kaynak kullanımından dolayı performansı zorlayacaktır.
Kod ve ortam değişlenlerinde esneklik farkı var. İki seçenek de değerlendirilebilir. Kodda daha fazla flagging yapılabilir. Ortam değişlenlerinde, true/false veya yüzdesel veriler tutulmasından dolayı esneklik düşük. Her iki durumda da veri tabanlarına göre entegrasyon süreci kolaydır.
Flag değeri değiştirmek için kod ve ortam değişlenlerinde yazılımda değişiklik yapılması ve değişikliklerin yayına alınması gerektiği için veri tabanlarına göre güncelleme hızı yavaştır.
3. Parti servisler, seçenekler arasında en maliyetlisidir. Hizmet almak için ücret ödemek gerekir. İhtiyaç duyulan hizmetlerin sağladığından emin olunmalı. Güvenlik, değişiklik performans ve flag yönetiminin yapılacağı ortamın "on premise (kendi sunucu) ve cloud (bulut)" sorgulanması gerekir.
Dezavantaj olarak "Teknik Borç" artışı
Eklenen flag"ler ilerleyen süreçlerde bakım gerektirir. Eğer bir özellik, kullanılmamasına rağmen yazılımda yaşamaya devam ederse, kod miktarında artış ve bu artışla doğru orantılı olarak kod karmaşıklığının artmasıyla sonuçlanacaktır. Her bir feature flag, karmaşıklık puanını arttırır. Geliştirme ve bakım maliyetine harcanan efor artar.
Yorumlar
Yorum Gönder