Yazılım ekipleri yeni bir özelliği tamamladıklarında onu hemen tüm kullanıcılara göstermek zorunda değildir. Kodu sisteme dağıtmakla, o özelliği kullanıcının karşısına çıkarmak aslında iki ayrı karardır. Bu ayrımı mümkün kılan araçlardan biri özellik bayrağıdır (feature flag veya feature toggle). Bu yazıda özellik bayraklarının ne olduğunu, klasik sürüm numaralandırmadan nasıl farklılaştığını ve sürüm yönetimi süreçlerinde nasıl bir rol oynadığını genel hatlarıyla ele alıyoruz.
Bir bakışta
- Özellik bayrağı, kod dağıtımını kullanıcıya açılmasından bağımsız kılarak kontrollü yayınlama imkanı sağlar.
- Kademeli yayınlama ve A/B testler sayesinde yeni özellikler belirli kullanıcı gruplarına kısmi olarak açılabilir.
- Çok fazla bayrak birikimi teknik borç oluşturur; kullanılmayan bayraklar düzenli temizlenmelidir.
Özellik Bayrağı (Feature Flag) Nedir?
Özellik bayrağı, en basit haliyle kod içine yerleştirilmiş bir açma-kapama anahtarıdır. Bir özelliğin kodu sisteme yüklenmiş olsa bile, bu anahtar "kapalı" durumdaysa kullanıcı o özelliği göremez; "açık" durumdaysa özellik devreye girer.
Bunu ev elektriğindeki sigorta kutusuna benzetmek mümkündür. Evin tüm kablo döşemesi tamamlanmış olabilir ama bir odanın sigortası kapalıyken o odada ışık yanmaz. Sigorta açıldığında ise aynı tesisat üzerinden akım geçmeye başlar ve ışık yanar. Özellik bayrağı da buna benzer şekilde, zaten var olan kodun devreye girip girmeyeceğini kontrol eder.
Yazılım ekiplerinin böyle bir mekanizmaya ihtiyaç duymasının temel sebebi, kod dağıtımı ile kullanıcı deneyimini birbirinden ayırarak daha kontrollü ve daha az riskli bir yayınlama süreci kurmak istemeleridir.
Feature Flag ile Klasik Sürüm Numaralandırma Arasındaki Fark
Sürüm numaralandırma (versiyonlama), bir yazılımın hangi paket halinin, hangi kod kümesiyle dağıtıldığını temsil eder. Örneğin bir uygulamanın 2.4.0 sürümü, belirli bir kod derlemesinin kullanıcıya ulaştığı anı işaret eder. Bu numara, "hangi kod dışarıda" sorusuna cevap verir.
Özellik bayrağı ise farklı bir soruya cevap verir: "Dışarıdaki kodun içindeki hangi özellik kullanıcıya görünür?" Aynı 2.4.0 sürümü içinde onlarca özellik bulunabilir; bunlardan bazıları tüm kullanıcılara açık, bazıları sadece belirli bir gruba açık, bazıları ise tamamen kapalı olabilir.
Bu iki mekanizma birbirinin yerine geçmez, birbirini tamamlar. Sürüm numarası dağıtımın kaydını tutarken, özellik bayrağı o dağıtımın içindeki görünürlüğü yönetir. Bir ekip kod dağıtımını sık sık yapıp özellikleri bayraklarla kapalı tutarak, dağıtım sıklığı ile özelliğin kullanıcıya açılma anını birbirinden bağımsızlaştırabilir.
Kademeli Yayınlama ve Belirli Kullanıcı Gruplarına Açma
Özellik bayraklarının en çok bilinen kullanım alanlarından biri kademeli yayınlamadır (gradual rollout). Bu yaklaşımda yeni bir özellik önce kullanıcıların küçük bir yüzdesine açılır, sorun görülmezse oran zamanla artırılır ve sonunda herkese ulaşır.
Benzer bir mantık A/B test senaryolarında da işler. Kullanıcıların bir kısmına eski davranış, bir kısmına yeni özellik gösterilerek hangi yaklaşımın daha iyi sonuç verdiği gözlemlenebilir. Yine beta kullanıcı gruplarına özel erişim açma da yaygın bir kullanımdır; belirli kullanıcılar (örneğin kayıtlı beta test grubu) bir özelliği erken deneyebilirken geri kalan kullanıcılar henüz bu özelliği görmez.
Bu yaklaşımın en önemli faydası, olası sorunların küçük bir kullanıcı kitlesinde fark edilip büyümeden müdahale edilebilmesidir. Bir hata, tüm kullanıcı tabanına değil sınırlı bir gruba yayılmış olur.
Riskli Güncellemelerde Hızlı Geri Alma (Rollback) İmkanı
Klasik bir güncellemede bir sorun ortaya çıktığında, genellikle önceki sürüme dönmek gerekir; bu da yeni bir dağıtım süreci, derleme ve yükleme adımları anlamına gelebilir. Özellik bayrağı kullanıldığında ise bu süreç çok daha hızlı işleyebilir: sorunlu özelliğin kodu geri çekilmez, sadece bayrak kapatılır. Böylece özellik anında devre dışı kalır ve sistem önceki davranışına döner.
Bu durum sistem ve uygulama güncellemeleriyle doğrudan ilişkilidir. Bir sistem güncellemesi dağıtıldıktan sonra beklenmeyen bir sorun fark edilirse, eğer o güncellemenin riskli kısmı bir bayrakla kontrol ediliyorsa, ekip yeni bir acil yama hazırlamak zorunda kalmadan bayrağı kapatarak durumu idare edebilir. Bu da geleneksel rollback süreçlerine kıyasla belirgin bir hız avantajı sağlar; çünkü yeni bir paket hazırlama ve dağıtma adımı beklenmez.
Değişiklik Günlüklerinde Feature Flag ile Açılan Özelliklerin Belgelenmesi
Bir özelliğin koda eklenmesi ile kullanıcıya açılması farklı zamanlarda gerçekleştiği için, bu durumun değişiklik günlüğüne (changelog) nasıl yansıtılacağı ayrı bir dikkat gerektirir. Bir özellik kod olarak dağıtılmış ama bayrağı kapalıysa, bunu changelog'da "eklendi" gibi nihai bir ifadeyle belirtmek okuyucuyu yanıltabilir.
Bunun yerine, changelog'da bayrağın durumunu da belirtmek faydalı olur: özelliğin kapalı olarak eklendiği, sınırlı bir kullanıcı grubuna kısmi açıldığı veya tüm kullanıcılara tam olarak açıldığı ayrı ayrı not edilebilir. Bu tür bir netlik hem son kullanıcıya hem de ekip içi iletişime katkı sağlar; herkes hangi özelliğin fiilen kullanılabilir olduğunu, hangisinin henüz arka planda beklediğini anlayabilir.
Sürüm Kontrolü Süreçleriyle Birlikte Kullanım
Özellik bayrakları, sürüm kontrolü (version control) süreçleriyle birlikte düşünüldüğünde kod tabanının yönetimini de kolaylaştırabilir. Normalde yarım kalan veya henüz yayına hazır olmayan bir özellik için ayrı bir dal (branch) açılıp üzerinde uzun süre çalışılması, daha sonra ana koda birleştirilmesi (merge) gerekebilir. Bu tür uzun ömürlü dallar, zamanla ana koddan uzaklaşıp birleştirme sırasında çatışmalara (conflict) yol açabilir.
Özellik bayrağı kullanıldığında, henüz tamamlanmamış bir özelliğin kodu bayrak kapalı şekilde doğrudan ana koda eklenebilir. Böylece ekip üyeleri uzun süre ayrı dallarda çalışmak yerine, değişikliklerini daha sık ana koda entegre edebilir. Bu yaklaşım, daha küçük ve daha sık dağıtımlar yapılmasına, dolayısıyla genel olarak daha esnek bir sürüm yönetimi sürecine katkı sağlar.
Çok Fazla Feature Flag Birikmesinin Getirdiği Karmaşıklık ve Teknik Borç
Özellik bayraklarının faydaları olsa da bu yöntemin bedelsiz olmadığını belirtmek gerekir. Kod tabanında çok sayıda bayrak biriktiğinde, her bir koşul kodun okunabilirliğini zorlaştırır. Bir geliştirici kodu okurken artık "bu bayrak açıksa ne olur, kapalıysa ne olur" sorularıyla uğraşmak zorunda kalır.
Test süreçleri de karmaşıklaşır; çünkü farklı bayrak kombinasyonlarının her biri ayrı bir senaryo anlamına gelebilir. Bazı durumlarda bir bayrağın hangi amaçla eklendiği zamanla unutulabilir veya hiç belgelenmemiş olabilir; bu da kodun hangi kısmının hâlâ aktif kullanıldığı, hangi kısmının artık gereksiz olduğu konusunda belirsizlik yaratır. Bu tür birikimler, zamanla klasik bir teknik borç haline gelir ve geliştirme hızını yavaşlatabilir.
Kullanılmayan Bayrakların Düzenli Temizlenmesinin Önemi
Bu riski azaltmanın en pratik yolu, artık ihtiyaç duyulmayan bayrakları düzenli olarak kod tabanından kaldırmaktır. Bir özellik tüm kullanıcılara tam olarak açıldıktan ve kararlı şekilde çalıştığı doğrulandıktan sonra, bayrağı ve bayrağa bağlı eski kod yollarını temizlemek, kod tabanını sade tutar.
Ekiplerin belirli aralıklarla mevcut bayrakları gözden geçirmesi, hangi bayrağın hâlâ aktif bir amaca hizmet ettiğini, hangisinin artık gereksiz olduğunu netleştirmeye yardımcı olur. Bu tür bir alışkanlık, kısa vadede ekstra bir çaba gibi görünse de uzun vadede okunabilir, test edilebilir ve yönetilebilir bir kod tabanı sağlar.
Sonuç olarak özellik bayrakları, geleneksel sürüm numaralandırma ve dağıtım süreçlerinin yerini almaz; onları tamamlayan bir katman sunar. Kod dağıtımı ile özelliğin kullanıcıya açılması arasına esnek bir sınır koyarak kademeli yayınlama, hızlı geri alma ve daha esnek sürüm kontrolü gibi imkanlar sağlar. Ancak bu esnekliğin sürdürülebilir olması, bayrakların dikkatli belgelenmesine ve düzenli olarak temizlenmesine bağlıdır.
