Feature Flag Nedir? Tek Kişilik Geliştirici İçin Sade Rehber

Feature flag nedir? Kodunuzun içinde duran ama açık mı kapalı mı olduğu kodun dışından okunan bir if ifadesidir. Yeni kod yolunu kapalı halde yayınlarsınız, sonra bir yapılandırma dosyasında, bir veritabanı satırında ya da bir flag servisinde değeri değiştirerek açarsınız. Yeniden deploy gerekmez. Bu tek fikir kodu yayınlamakla özelliği kullanıma açmayı birbirinden ayırır, bu yüzden bir flag sahip olabileceğiniz en ucuz geri alma mekanizmasıdır.

Bu cümlenin ikinci yarısını zor yoldan öğrendim. İlk flag'im bir ortam değişkeninde duran bir boolean'dı. Bir cuma gecesi açtım ve on bir ay boyunca var olduğunu unuttum. Hiçbir şey bozulmadı. Tam da sorun bu ve birazdan buna geleceğiz.

Kodda bir feature flag aslında nasıl görünür?

Vendor ana sayfalarının ima ettiğinden çok daha küçük. Gösterge panellerini çıkarırsanız bir flag, bir okuma ve bir dallanmadan ibarettir:

const flags = { newCheckout: false };

if (flags.newCheckout) {
  return renderNewCheckout(user);
}
return renderOldCheckout(user);

Geri kalan her şey, bu flags nesnesinin nereden geldiği ve kimin değiştirebileceği sorusudur. Dosyadaki bir sabit, deploy ederek değiştirdiğiniz bir flag'dir ve bu da tüm amacı boşa çıkarır. Ortam değişkeni yeniden başlatmada değişir. Veritabanındaki bir satır saniyeler içinde değişir. Barındırılan bir servis de saniyeler içinde değişir ve buna ek olarak kullanıcı bazlı hedefleme, bir arayüz ve bir denetim kaydı sunar.

Asıl sorun şu: kod basit, yaşam döngüsü basit değil. Üretimde iki dal demek iki davranış demektir. Bunları test etmeniz, sabah 2'de birini ayıklamanız gerekir ve bunlardan biri çürümeye mahkum.

Dört tip feature flag var ve ilk hangisine ihtiyacınız var?

Martin Fowler'ın feature toggle sınıflandırması bunları ayırmanın hâlâ en temiz yolu. İşe yarayan eksen de her tipin ne kadar yaşaması gerektiği.

Release flag'leri tamamlanmamış ya da riskli işleri gizler. Geçicidir: bir iki hafta, sonra silinir. İlk ihtiyacınız olan bu.

Ops flag'leri acil durum şalterleridir. Ağır ya da kırılgan bir özelliği (bir öneri bileşeni, bir üçüncü taraf çağrısı) yük altında deploy beklemeden kapatabilmek için sarmalarsınız. Çoğu kısa ömürlüdür, birkaçı kalıcı kalır ve bu da sorun değil.

Experiment flag'leri A/B testleri için kullanıcıları gruplara ayırır. Anlamlı bir sonuca ulaşana kadar yaşarlar, yani saatler ya da haftalar sürer ve bir şey ifade etmeleri için gerçek trafiğe ihtiyaç duyarlar.

Permission flag'leri özellikleri plana ya da hesaba göre kapıya bağlar: Pro paket, beta grubu. Yıllarca yaşayabilirler ve o noktada gerçek anlamda flag olmaktan çıkıp yetkiye dönüşürler. Bunların düzgün bir veri modeli hak eder.

40 kullanıcılı tek kişilik bir projeniz varsa release flag'lere ve belki bir acil durum şalterine ihtiyacınız var. 40 kullanıcıda experiment flag'ler veri değil gürültü üretir. Metriği ve örneklem büyüklüğünü adlandırabilene kadar bunları atlayın.

Dallar ve deploy'lar çözmeyen hangi sorunu flag'ler çözer?

Üç şey var ve yalnızca üçü önemli.

Yarım kalmış işi güvenle yayınlamak. Uzun ömürlü dallar acı verir, çünkü birleştirmek küçük bir savaştır. Flag sayesinde yeni kod kapalıyken her gün main'e birleştirebilirsiniz. Bu, herkesin tek bir dala commit attığı ve yarım kalan parçaları flag'lerin taşıdığı trunk-based geliştirmenin motorudur.

Kademeli yayılım. Özelliği önce kendiniz için açın, sonra kullanıcıların yüzde 1'i için, sonra yüzde 10 için, en sonunda herkes için. Fowler, kullanıcı ID'sinin 100'e modunu alarak yaklaşık yüzde 1'lik bir kanarya grubu seçmeyi anlatır. Bir sorun olursa etkilenen kişi sayısı tüm tabanınız yerine birkaç kişi olur.

Hızlı geri alma. Bir deploy'u geri almak bir build, bir pipeline ve biraz cesaret demek. Bir flag'i çevirmek tek bir düzenleme. Kötü bir günde fark, birkaç dakikalık acı ile bir saatlik acı arasındadır.

Bunların hiçbiri ilk günden bir vendor gerektirmez. Hepsi disiplin gerektirir.

LaunchDarkly'ye mi ihtiyacınız var, yoksa bir JSON dosyası yeter mi?

Bir JSON dosyası ya da bir veritabanı tablosu, şunlardan biri doğru olana kadar yeter: teknik olmayan biri flag'leri çevirmek zorundaysa, yüzde bazlı yayılım ya da kullanıcı bazlı hedefleme gerekiyorsa, kimin neyi değiştirdiğine dair bir denetim izine ihtiyacınız varsa ya da aynı flag'leri okuyan birden fazla servis çalıştırıyorsanız.

Tırmanacağım kaba merdiven şu sırayla:

1. Sabitler ve ortam değişkenleri. Sıfır maliyet. Bir yan projenin ilk release flag'i için uygun.

2. Çalışma zamanında okuduğunuz bir flags tablosu ya da JSON dosyası. On satır kod, anında çevirme, vendor yok. Tek başına bir yan projeyi şaşırtıcı derecede uzağa taşır.

3. Açık kaynak ya da barındırılan bir flag servisi. Hedefleme kuralları, kademeli yayılım ve başkalarının da kullanabileceği bir arayüz istediğinizde.

4. Kurumsal bir platform. Uyumluluk, onaylar ve düzinelerce mühendis işin içine girdiğinde.

Barındırılan araçlar 3. ve 4. adımları kapsar. LaunchDarkly sektörün öncüsü; en derin hedefleme ve yönetişim özelliklerine sahip, fiyatı da bunu yansıtıyor.

Statsig flag'leri deneyler ve ürün analitiğiyle birlikte sunar. Flag'in sadece açıp kapamasını değil, ne yaptığını da ölçmeyi planlıyorsanız bu mantıklı.

Ekibiniz yalnızca sizseniz ikisini de atlayın. Üç sütunluk bir tablo, üç ayda bir iki kez açtığınız bir panelden iyidir. Bir servisi yalnızca manuel yöntemin size somut bir şeye mal olduğunda seçin; mesela production yapılandırmasında pişman olduğunuz gece yarısı bir düzenleme gibi.

Bilmeye değer bir sigorta: OpenFeature, flag değerlendirmesi için satıcıdan bağımsız bir API tanımlayan CNCF kuluçka projesi. Node.js, Python, Go, Java, .NET ve web istemcileri dahil birçok dil için SDK sunuyor. Standart arayüze karşı kodlarsınız ve altındaki sağlayıcıyı değiştirirsiniz. İlk kurulumunuzu aşacağınızdan şüpheleniyorsanız, flag'leri OpenFeature üzerinden bağlamak bu geçişi bir yapılandırma değişikliğine indirger.

İlk flag'inizi karmaşa çıkarmadan nasıl eklersiniz?

Tek bir release flag ve birkaç temel kuralla başlayın. Keşke ben de bunları ilk seferinde takip etseydim.

Adını mekanizmaya değil özelliğe göre verin. new-checkout-flow yanlış gittiğinde neyin bozulduğunu söyler. flag_47 altı ay sonra hiçbir şey söylemez.

Varsayılan olarak kapalı başlatın ve kapalı olmanın eski davranış anlamına geldiğinden emin olun. "Kapalı eski, açık yeni" kuralı, baskı altında sistemi akıl yürütebilmenizi sağlar. Bunu bozarsanız her flag bir bilmeceye dönüşür.

Değerlendirmeyi tek bir yerde yapın. Fowler buna toggle inversion diyor: if (flags.x) ifadesini yirmi dosyaya serpiştirmek yerine, sistemin kenarında bir kez karar verin ve sonucu içeri geçirin. Tek bir karar noktası, tek bir değiştirilecek ve test edilecek yer demektir.

Flag'i oluşturduğunuz an silme görevini yazın. Bir tarihle birlikte backlog'a koyun. Fowler, kısa ömürlü toggle'lara son kullanma tarihi ve tarihi geçince başarısız olan testler de önerir. Silme görevi olmayan bir flag, geri ödeme planı olmayan bir kredidir.

Önemli her değerlendirmeyi loglayın. Bir kullanıcı hata bildirdiğinde flag'in hangi tarafında olduğunu bilmek istersiniz. Bunu cevaplayamıyorsanız flag bir yüktür.

Testte fazla mühendislik yapan çok kişi var. Her flag kombinasyonunu test etmeniz gerekmez, çünkü çoğu flag birbirleriyle etkileşmez. Üretimde beklediğiniz yapılandırmayı test edin, flag kapalıyken fallback'i test edin ve isterseniz tüm flag'lerin açık olduğu tek bir geçişle sapmayı yakalayın.

Feature flag'lerin kimsenin söylemediği gerçek maliyeti nedir?

Her flag bir kod yolunu ikiye katlar. Bağımsız on flag teorik olarak 1.024 kombinasyon demek. Hepsini asla test edemeyeceksiniz, ama kimsenin öngörmediği birini üretimde yine de vurabilirsiniz.

Daha acı verici maliyet ölü flag'lerdir. Yayılım biter, herkes yeni davranışta olur, flag yüzde 100'de kalır ve eski dal, kimsenin silmeye cesaret edemediği kod olarak depoda durur. Altı ay sonra kimse onu kapatmanın güvenli olup olmadığını hatırlamaz.

Bunun meşhur örneği Ağustos 2012'deki Knight Capital. Bir zamanlar emekli edilmiş bir trading fonksiyonunu etkinleştiren eski bir flag, yeni kod için yeniden kullanıldı. Sekiz sunucudan biri deploy'u kaçırdı ve eski kodu çalıştırmaya devam etti. 45 dakikada firma, çeyreklik raporuna (10-Q) göre yaklaşık 440 milyon $ kaybetti. Sonraki haberler rakamı 460 milyon $ civarına yaklaştırdı. Bu, gerçek parası ve gerçek mühendisleri olan bir trading firması, bu yüzden yan projenizin daha güvenli olduğunu iddia etmeyeceğim. Ders küçük ölçekte de geçerli: flag adını asla geri dönüştürmeyin ve ölü flag'leri arkeolojiye dönüşmeden silin.

Fowler'ın çerçevelemesi, hâlâ aklımda tuttuğum: flag'leri taşıma maliyeti olan bir envanter gibi görün. Bazı ekipler canlı flag sayısını sınırlar ve yenisini eklemeden önce birini kaldırmayı zorunlu tutar. Tek kişilik bir geliştirici için beş sert tavan yeterlidir.

Feature flag'ler ne zaman tamamen atlanmalı?

Araç satıcılarının kabul ettiğinden çok daha sık.

Özellik küçükse, değişiklik git'te kolayca geri alınabiliyorsa ve deploy'unuz iki dakika sürüyorsa atlayın. Bir flag bir dal, bir yapılandırma kaynağı ve unutulacak bir şey ekler. Geri almak flag çevirmekten hızlıysa flag bir tiyatrodur.

Henüz kullanıcınız yoksa atlayın. Sıfır kişiye kademeli yayılım sadece bir gecikmedir. Yayınlayın, loglara bakın, düzeltin.

Bir toggle ile geri alınamayan veritabanı migration'ları için de atlayın. Bir flag yeni bir kolonu arayüzden gizleyebilir ama silinmiş bir tabloyu geri getiremez. Şema değişiklikleri flag'ler olsun ya da olmasın kendi genişlet-daralt planını ister.

Flag'in değdiği durumlar: değişiklik ödemelere ya da kimlik doğrulamaya dokunuyorsa, her gün yarım kalmış işle birleştirmek istiyorsanız ya da bir üçüncü taraf bağımlılığı çökebilirse ve bir acil durum şalteri istiyorsanız.

Flag yayına alındıktan sonra neyi izlemelisiniz?

Flag maruziyeti kontrol eder, ama maruziyet ancak sonrasında ne olduğunu görebildiğinizde işe yarar. Bir özelliği kullanıcıların yüzde 10'u için hata oranlarını ve gecikmeyi izlemeden açmak, ekstra adımları olan bir yazı turadır.

İlk yayılımdan önce üç soruyu bir dakikadan kısa sürede cevaplayabildiğinizden emin olun: flag'lenmiş grupta hatalar arttı mı, gecikme kötüleşti mi, aşağı akışta bir şey değişti mi? Uptime izleme ve log arama, küçük bir ürünün bu işlerinin çoğunu kapsar. Better Stack gibi bir araç da monitörleri, durum sayfalarını ve logları tek yerde toplar ve ücretsiz bir katmanı vardır.

Bugün izlediğim kural şu: bir flag, bağlı olduğu alarm kadar iyidir. Alarm yoksa karanlıkta bir şeyleri açıyorsunuzdur.

Bu hafta gerçekte ne yapardık?

Korkup birleştirmeye cesaret edemediğiniz tamamlanmamış bir iş seçin. Bir tablodan ya da JSON dosyasından okunan bir boolean'ın arkasına koyun, varsayılan kapalı olsun ve bugün main'e birleştirin. Editörü kapatmadan önce, iki hafta sonrası için bir tarihle silme görevini yazın.

Sonra yalnızca kendiniz için açın ve bir gün kullanın. Sağlam çalışırsa genişletin. Çalışmazsa kapatın; bir dakikadan başka bir şey kaybetmediniz.

Kod tabanınızda şu anda hangi flag yüzde 100'de bir aydan uzun süredir duruyor? İlk silmeniz o olacak.