Feature Toggle, uygulama işlevselliğini çalışma zamanında açıp kapatan bir mekanizmadır ve geliştiricilerin kod değiştirmeden veya yeniden dağıtmadan özellik kullanılabilirliğini yönetmesine olanak tanır. Koşullu derlemenin (ifdef) aksine, toggle çalışma zamanı seviyesinde çalışır ve dinamik olarak değiştirilebilir. Martin Fowler (2024)'a göre, feature toggles trunk-based development ve sürekli teslimatın temel bir öğesidir. Feature toggle ekiplere sürümleri ve deneyleri yönetmede esneklik sağlar.
Önemli Noktalar
Feature Toggle, yeni bir özelliğin kodunun, bir yapılandırma parametresinin değerini kontrol eden koşullu bir yapıya sarıldığı bir tekniktir. Parametre doğruysa — yeni işlevsellik etkin, yanlışsa — eski kod çalışır. Feature flag'dan temel farkı, toggle'ın karmaşık hedefleme kuralları veya trafik dağıtımı olmadan açık/kapalı prensibiyle çalışan ikili bir anahtar olmasıdır.
Feature toggle, yeni işlevsellik etrafında basit bir if-yapısı olarak uygulanır. Toggle değeri uygulama yapılandırmasında — ortam değişkenleri, bir JSON dosyası veya veritabanında saklanır. Uygulama başladığında, yapılandırmayı yükler ve özellik görünürlüğü hakkında kararlar almak için kullanır. En basit durumda, bir toggle değerini değiştirmek uygulamayı yeniden başlatmayı gerektirir, ancak üretim sistemlerinde toggles genellikle harici bir yapılandırma sunucusu veya API aracılığıyla sıcak yeniden yüklemeyi destekler.
JavaScript (Node.js) içinde bir feature toggle uygulamasına bakalım. Toggle, bir JSON yapılandırma dosyasında saklanır ve sunucu başladığında yüklenir. Middleware, isteği yeni veya eski işleyiciye yönlendirmeden önce toggle değerini kontrol eder. Bu uygulama, mevcut API sürümünü bozmadan ana kod dalına yeni işlevsellik eklemeye olanak tanır.
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});
ThoughtWorks'ten Pete Hodgson, feature toggles'ı yaşam süresi ve kullanım amacına göre sınıflandırarak üç ana tür tanımlar. Toggle türünü doğru belirlemek, uygun depolama mekanizmasını ve yönetim sürecini seçmeye yardımcı olur. Her türü mobil geliştirme bağlamında inceleyelim.
Business toggles en uzun ömürlü anahtarlardır. Yalnızca belirli kullanıcı kategorileri için kullanılabilen (premium özellikler, bölgesel özellikler) iş kurallarını yönetirler. Bu toggles yıllarca yaşayabilir ve genellikle ikili açık/kapalıdan daha karmaşık mantığa sahiptir. Release toggles, tamamlanmamış işlevselliği gizlemek için geçici anahtarlardır. Yaşam döngüleri birkaç günden birkaç haftaya kadar değişir. İşlevsellik tamamlandığında, release toggle koddan kaldırılır. Bu toggles, trunk-based development'ın temelidir ve geliştiricilerin tüm işlevselliğin tamamlanmasını beklemeden ana dala commit yapmasına olanak tanır.
Experiment toggles A/B testleri ve aşamalı dağıtım için kullanılır. Release toggles'ın aksine, experiment toggles yüzde tabanlı kullanıcı dağıtımını ve analitik sistemleriyle entegrasyonu destekler. Release toggles'tan daha uzun (birkaç aya kadar) yaşayabilirler, ancak deney sona erdikten sonra da kaldırılmalıdırlar. Infrastructure toggles, altyapı değişikliklerini yönetmek için anahtarlardır: veritabanı geçişi, yeni bir API sağlayıcısına geçiş, önbellek algoritmalarını değiştirme. Bu toggles, test etmeye özel dikkat gerektirir çünkü anahtarlamaları tüm hizmetin kararlılığını etkiler.
| Toggle Türü | Süre | Hedef Kitle | Örnek |
|---|---|---|---|
| Business | Aylar-yıllar | Rollere/bölgelere göre | Premium özellikler |
| Release | Günler-haftalar | Geliştiriciler/QA | Tamamlanmamış ekran |
| Experiment | Haftalar-aylar | % kullanıcı | Arayüz A/B testi |
| Infrastructure | Günler-haftalar | Dahili | DB geçişi |
“Feature toggle” ve “feature flag” terimleri sıklıkla birbirinin yerine kullanılsa da, aralarında kavramsal farklılıklar vardır. Bu farklılıkları anlamak, belirli bir görev için doğru aracı seçmeye ve ekip içinde karışıklığı önlemeye yardımcı olur. Her yaklaşımın temel farklılıklarını ve kullanım durumlarını inceleyelim.
Feature toggle öncelikle teknik bir mekanizmadır: uygulama koduna gömülü ikili bir anahtar. Toggle, yapılandırma aracılığıyla yönetilir ve harici bir altyapı gerektirmez. Feature flag ise bir yönetim platformu içeren daha geniş bir kavramdır: yapılandırma için kullanıcı arayüzü, entegrasyon için SDK, kullanım izleme, analitik ve denetim. Flags, karmaşık hedefleme kurallarını (bölge, sürüm, cihaza göre), A/B deneylerini ve otomatik kaldırmayı destekler. Feature flag'ın feature toggle'ın evrimi olduğu söylenebilir: ekipler basit yapılandırma anahtarlarıyla başlar ve büyüdükçe özelleşmiş bir platforma geçer.
Küçük ekipler ve tek hizmetli veya monolit projeler için basit yapılandırma toggles'ları tamamen yeterlidir. 5–10 geliştiriciniz ve aynı anda 1–2 aktif toggles'ınız varsa, harici bir platform gereksiz olacaktır. Feature flag platformları (LaunchDarkly, Unleash), aktif flag sayısı 20–30'u aştığında, ekipte 20+ geliştirici olduğunda veya farklı kullanıcı segmentleri için ince ayarlı erişim kontrolü gerektiğinde gerekli hale gelir. İstemci güncellemelerinin günler sürdüğü mobil uygulamalar için, feature flag platformları ek bir avantaj sağlar — yeni bir sürüm yayınlamadan uygulama davranışını değiştirme yeteneği.
Feature toggle yönetim aracı seçimi, ekip büyüklüğüne, teknoloji yığınına ve güvenlik gereksinimlerine bağlıdır. Basit yapılandırma dosyalarından kurumsal yönetim platformlarına kadar açık kaynak alternatifleri de dahil olmak üzere seçenekleri inceleyelim.
Feature toggles, CI/CD boru hattının birinci sınıf vatandaşları olmalıdır. Derleme aşamasında, boru hattı mevcut sprintte kaldırılması planlanan tüm release toggles'ların gerçekten koddan kaldırılıp kaldırılmadığını kontrol eder. Test aşamasında, farklı toggle kombinasyonlarıyla matris testleri çalıştırılır. Dağıtım aşamasında, sistem otomatik olarak toggle yapılandırmasını üretim ortamıyla senkronize eder. PagerDuty veya Opsgenie ile entegrasyon, stale toggles algılandığında veya izin verilen aktif toggles sayısı aşıldığında uyarılar oluşturulmasına olanak tanır.
Basit senaryolar için, değişikliklerde kod incelemesiyle Git'teki bir JSON yapılandırması yeterlidir. Daha gelişmiş bir seçenek, toggle yönetimi için minimum kullanıcı arayüzü ekleyen Togglz (Java) veya Gofeature (Go) kütüphaneleridir. Üretim sistemleri için, tüm diller için SDK'lar ve aktivasyon stratejisi desteğiyle Unleash (açık kaynak) veya yerleşik A/B testiyle Flagsmith önerilir. LaunchDarkly, yüksek denetim ve uyumluluk gereksinimleri olan kurumsal projeler için standart olmaya devam etmektedir. Mobil uygulamalar için, tüm çözümler önbellekleme ve çevrimdışı modla birlikte yerel SDK'lar sağlar.
Feature toggles iki ucu keskin bir araçtır. Yönetim disiplini olmadan, geliştirmeyi yavaşlatan ve kod karmaşıklığını artıran teknik borca dönüşürler. CodeScene araştırmasına (2024) göre, kod tabanlarının %35–50'si stale toggles — dağıtım tamamlandıktan sonra kodda kalan anahtarlar — içerir. Bu borcu önleme ve ortadan kaldırma stratejilerini inceleyelim.
Bir feature toggle'ı kaldırma süreci dört adımdan oluşur. Birinci: toggle'ın hedef kitlenin %100'ü için etkinleştirildiğinden veya %0'ı için devre dışı bırakıldığından emin olun (hangi kod dalının kalması gerektiğine bağlı olarak). İkinci: kodda yalnızca üretim davranışı olması gereken dalı bırakarak tüm koşullu toggle kontrollerini koddan kaldırın. Üçüncü: toggle tanımını depolama sisteminden (yapılandırma, veritabanı veya platform) kaldırın. Dördüncü: kaldırmanın işlevselliği bozmadığını onaylamak için testleri çalıştırın. Her toggle'ın, anahtar oluşturulurken kaydedilen bir sahibi ve planlanmış bir kaldırma tarihi olmalıdır.
Manuel toggle denetimi, 50 anahtarın üzerindeki ölçeklerde verimsizdir. Otomasyon üç prensibe dayanır: CI kontrolü (stale toggles birleştirmeyi engeller), izleme (her toggle'ın yaşını ve durumunu gösteren bir pano), uyarılar (bir toggle N gün boyunca değişmediyse sahibini bilgilendirme). Statik kod analizi araçları (SonarQube, ESLint eklentisi), kodda her zaman açık veya her zaman kapalı olan toggles'ları — stale toggle'ın açık bir işareti — tespit edebilir. Son kontrol, gözden geçirenin yeni toggle'ın gerçekten gerekli olduğunu ve eski kod dalının kaldırılacağını doğrulaması gereken kod incelemesidir.
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}
Sıkça Sorulan Sorular
Terimler sıklıkla birbirinin yerine kullanılır, ancak teknik olarak feature toggle kodda ikili bir anahtardır (bir yapılandırma değerini kontrol eden if-koşulu). Feature flag, kullanıcı arayüzü, SDK, analitik ve karmaşık hedefleme kuralları içeren bir yönetim platformunu kapsayan daha geniş bir kavramdır. Toggle harici altyapı gerektirmez; flag genellikle gerektirir.
Release toggles, dağıtım tamamlandıktan sonra 1–2 hafta içinde kaldırılmalıdır. Experiment toggles — A/B testi biter bitmez. Business toggles düzenli denetim gerektirir (üç ayda bir). Görev takipçisinde kaldırma görevi olmayan yeni bir toggle ekleyen PR'ları engelleyen bir CI kontrolü kurulması önerilir.
Evet, feature toggles mobil geliştirmede aktif olarak kullanılır. Ana araç, uygulamanın yeni bir sürümünü yayınlamadan anahtarları dinamik olarak yönetmeye olanak tanıyan Firebase Remote Config'tir. Alternatifler: iOS/Android için LaunchDarkly SDK, Unleash SDK, REST API ile özel toggle sunucusu. Çevrimdışı modda çalışmak için değer önbelleklemesi uygulamak önemlidir.
Ana yöntem matris testidir: toggle açık ve kapalıyken tüm testleri çalıştırmak. N toggles için tam matris testi 2^n çalıştırma gerektirir, bu nedenle pratikte kritik kombinasyonlar seçilir. Birim testleri toggle değerini mock'lamalıdır. Entegrasyon testleri belirli senaryoları doğrular. Beklenmeyen etkileşimleri tespit etmek için rastgele bir toggle kombinasyonuyla testleri çalıştıran bir adım CI'ye eklenir.
Temel riskler: 1) stale toggles — her iki dal (açık/kapalı) ile kod karmaşıklaşır ve bakımı zorlaşır; 2) testlerin birleşimsel karmaşıklığı — her toggle durum sayısını ikiye katlar; 3) ölü kod — toggle kalıcı olarak etkinleştirildikten sonra eski dal kodda kalır; 4) güvenlik — erişimi kontrol eden anahtarlar yanlış yapılandırıldığında güvenlik açıkları oluşturur. Tüm riskler disiplin ve otomasyonla yönetilebilir.
Özet
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun