Dağıtım, kodun üretime ulaştığı zamandır. Serbest bırakma, birisinin onu gerçekten kullanabileceği zamandır. Bu ikisini karıştırmak, her konuşlandırmayı biraz gergin bir an haline getirmenin en hızlı yollarından biridir.
feature flag bu iki an arasına boşluk koymaya yarar. Bugün dağıtıma çıkabilir, yarın dahili ekip için, ardından pilot müşteri için, ardından kullanıcıların %10'u için devreye alabilirsiniz. Bir şeyler ters giderse bayrağı kapatın. Sürümün tamamını geri almanız gerekmez.
Bayrak yalnızca bir if değildir
Teknik olarak genellikle if'dir. Kültürel olarak çok daha fazlası.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Bu küçük if kademeli bir kullanıma sunma, bir deney, bir geçiş, bir işletme izni veya operasyonel bir kill switch anlamına gelebilir. Sorun şu ki, eğer bunu iyi yönetemezseniz, iki yıl boyunca kodda kalan teknik borca da dönüşebilir.
OpenFeature nerede devreye giriyor?
OpenFeature, feature flag'yi ortak bir API ile değerlendirmek için açık bir spesifikasyondur. Fikir basit: uygulama kodunuz doğrudan satıcıya veya bayraklar için kullandığınız dahili sisteme bağlı olmamalıdır.
Uygulama şunu sorar:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Sağlayıcı, kuralların nereden geleceğine karar verir: SaaS, dosya, dahili hizmet, flagd, GitOps yapılandırması. Bir gün özellik işaretleme arka ucunu değiştirirseniz uygulamanın her yere yeniden yazılması gerekmez.
Bu ayrım mimari bir detay gibi görünse de proje büyüdükçe hissediliyor.
Bağlam savaşın yarısıdır
Herkes için açık veya kapalı işareti faydalıdır ancak sınırlıdır. Aşamalı teslimat şu bağlamda yaşar:
- dahili veya harici kullanıcı;
- ücretsiz veya kurumsal plan;
- köy;
- organizasyon;
- uygulama sürümü;
- istikrarlı trafik yüzdesi.
Önemli anahtar targetingKey: stabil olmalı. Her istekte değişirse, kullanıcı bir kez A varyantına, bir kez de B varyantına düşebilir. Bir deneme için bu berbat, ödeme içinse felaket olabilir.
Mantıklı bir dağıtım
Beğendiğim bir akış şu:
- bayrak kapalıyken konuşlandırın;
- geliştiriciler ve QA için ateşleme;
- Pilot müşteri veya kiracı için çalıştırma;
- %5'lik dağıtım;
- %25'lik dağıtım;
- %100 kullanıma sunma;
- Eski kodun ve bayrağın kaldırılması.
Çoğu zaman unutulan nokta ise sonuncusudur. Geçici bir bayrağın ölüm tarihi olmalıdır. Eğer sonsuza kadar kalırsa, gelecekteki her yeniden düzenlemeci şunu sormak zorunda kalacak: "Fakat bu dal hala faydalı mı?".
Kill switch: önce onları hazırlayın
kill switch, harici bir bağımlılık sizi rahatsız etmeye başladığında, bir iş çok fazla kaynak tükettiğinde veya yeni mantık garip hatalar ürettiğinde sizi kurtaran bayraktır.
İyi bir kill switch şöyle olmalıdır:
- bulunması kolay;
- runbook'ta belgelenmiştir;
- ara sıra test edilmiştir;
- etkinleştirildiğinde gözlemlenebilir;
- Kırılabilecek kısımdan mümkün olduğu kadar bağımsız.
En kötüsü kaza sırasında bayrağın var olduğunu keşfetmek ama kimse hala çalışıp çalışmadığını bilmiyor.
Gözlemlenebilirlik veya aşamalı olmayan dağıtım
Bir özelliği metriklere bakmadan %10 oranında açmak, birden fazla adım içeren bir iyimserliktir.
Her kullanıma sunma basit sorulara yanıt vermelidir:
- hatalar arttı mı?
- gecikme değişti mi?
- kullanıcılar akışı tamamlıyor mu?
- daha fazla bilet veya yeniden deneme var mı?
- Bir değişken yalnızca bir segmenti mi etkiliyor?
OpenFeature bayrak değerlendirmesi etrafındaki kancaları destekler. Hataları günlüğe kaydetmek, ölçümler eklemek veya derecelendirmeyi trace'ye bağlamak için kullanışlıdırlar.
Adlandırma ve sahiplik
İsimler önemlidir. new_ui hiçbir şey söylemiyor. checkout.v2.enabled çok daha fazlasını söylüyor.
Her bayrak için en azından şunu işaretlerdim:
- isim;
- Tanım;
- mal sahibi;
- güvenli varsayılan;
- var olmasının nedeni;
- kaldırılma tarihi veya koşulu.
Sahipsiz bir bayrak neredeyse her zaman kimsenin kaldıramayacağı bir bayraktır.
Bunları nerede değerlendirmeli
Ön uç, arka uç veya kenar? Bağlı olmak.
Bayrak düzen, kopyalama veya katılım içinse ön uçta sorun yoktur. İzinler, faturalandırma, sınırlar veya hassas verilerle ilgiliyse arka uçta yer alması gerekir. Yönlendirme veya yüksek trafik denemeleri içeriyorsa, kenar mantıklı olabilir.
Basit kural: Ön uç deneyimi iyileştirebilir ancak tek güvenlik engeli olmamalıdır.
Sonuç
feature flag iyi yapıldığında üretimle olan ilişki değişir. Riski ortadan kaldırmazlar ancak onu daha küçük ve daha yönetilebilir hale getirirler. Dilimler halinde serbest bırakabilir, gözlemleyebilir, durabilir, geri dönebilir, öğrenebilirsiniz.
OpenFeature temiz bir temel ekler: ortak bir API, değiştirilebilir sağlayıcılar ve sistemi büyütmenin daha düzenli bir yolu. Ancak disiplin sizin elinizde: Güvenli varsayılanlar, net isimler, ölçümler, sahipler ve temizlik.
En iyi bayrak, sakince salıvermenize yardımcı olan ve artık ihtiyaç duyulmadığında kaybolan bayraktır.