"Özellik işareti" nedir?

Yüksek Ölçeklenebilirlik burada özellik işaretlerinden bahseder:

Ölçeklenebilirlik için zehirli 5 şey , "5. Özellik İşaretlerinin Eksikliği"

Özellik işaretleri tam olarak nedir?

Bir 'özellik bayrağı' (veya Özellik Değiştirme ), uygulamanızın özelliklerini (alt bölümleri) kolayca şu şekilde açma / kapatma yeteneğidir:

• belki bir yeniden dağıtım yoluyla veya
• sayfaların / özelliklerin canlı olarak değiştirilebildiği bazı dahili sayfalar.

Sanırım örnek, eğer yük çok yüksekse, db sorgularını azaltmanız gerekirse, özellik setini bir şekilde azaltmak için kontrole sahip olmanın kullanışlı olduğunu tahmin ediyorum.

Yine de bunu kullanmak isteyebileceğiniz çok sayıda başka neden var - ana sebeplerden biri Sürekli Teslimatı mümkün kılmak : işleri üretime / canlıya itmek, ancak tamamlanana kadar özelliği devre dışı bırakmak / değiştirmek. Tamamlanmamış özellikleri yalnızca geliştirici ekibine göstermek için genellikle 'geliştirici çerezi' dediğimiz şeyi kullanırız. Bu şekilde, üretimde kısmen tamamlanmış işi (oh evet! Daha iyi bir entegrasyon var mı?), Onu 'açmadan' (tamamlamadan) ve kamuya görünür hale gelmeden önce birden fazla yayın / dağıtım üzerinde test edebiliriz.

İşte bunu ASP.NET MVC arazisinde yapmanıza yardımcı olacak basit bir paket: https://github.com/cottsak/DevCookie (tam açıklama: ben yazarım)

Fowler ayrıca yukarıda bağlantılı olandan çok daha uzun bir makaleye sahip .

Bu gönderi (Fowler'ın sitesinde de) çeşitli geçiş stratejileri türlerini açıklıyor . DevCookie , ana hat / ana hat tabanlı stratejiyi destekler ve makalede " Yayın Geçişi " olarak adlandırılır .

Adil'in cevabı , bu altyapının bir kısmını isteyebileceğiniz birçok terim ve neden olduğunu vurguluyor. Bunlardan yalnızca bazılarına ihtiyacınız olabileceğini unutmayın. Örneğin, yalnızca basit ve çevik bir dağıtım / dağıtım iş akışını etkinleştirmek isteyebilirim ve bu nedenle basit bir altyapı yeterli olacaktır. Daha sonra A / B ile tam #leanstartup deneyine, kohort testine ve kontrollü dağıtım gibi şeylere geçmek istediğinizi seçerseniz , bu veriye dayalı geliştirme metodolojilerini ayrı bir çözüm olarak kolaylaştıran bir analitik aracı (ör. Yığın ) düşünmelisiniz. . Yukarıdakilerin tümünü yapan bir geçiş altyapısı, şişkinliğe ve gereksiz karmaşıklığa yol açacaktır.

Buraya kadar geldiyseniz , Ana Hat Geliştirme, özellik değiştirme ve TEST, QA, SIT, STAND, CROUCH gibi diğer aptalca fikirlerle ilgili diğer düşüncelerime göz atmak isteyebilirsiniz .

Özellik Bayrağı, yeni kod dağıtmadan, uygulamanızın bazı işlevlerini yapılandırma yoluyla kapatma tekniğidir.

Özellik bayrakları, özelliklerin sürekli olarak konuşlandırıldığı, ancak üretimde mutlaka "yayınlanmasının" gerekmediği CI şemasında önemli bir rol oynar.

Daha fazla bilgi burada:

• http://code.flickr.com/blog/2009/12/02/flipping-out/

-- DÜZENLE:

Özellik Bayrakları java uygulaması .

Özellik Bayrakları, özellik geçişleri, deneyler ve kontrollü sunumlar, basit ancak güçlü bir fikrin eşanlamlılarıdır: özellik sunumlarından ayrı kod dağıtımları. Açıkça söylemek gerekirse, bu özelliği müşterileriniz arasından kimin - eğer varsa - bu özelliği göreceğini seçerken özelliğinizin taahhütlerini üretime itme yeteneğidir.

Facebook Gatekeeper tarafından kısmen popüler hale getirildi . LinkedIn'in LiX'i başka bir güzel örnek.

Bu basit fikri benimsemek, aşağıdakiler dahil birçok en iyi uygulamanın temelini oluşturur:

Sürekli Dağıtım / Teslimat - bir günde birden çok kod üretime aktarır.

Trunk / Mainline Development - özellik dalları, uzun ömürlü özellik geliştirme için değil, yalnızca çekme istekleri için oluşturulmalıdır.

İşleri batırmak için Daha Fazla Serbest Bırakma Treni Yok .

Üretimde Kalite Güvencesi / Mükemmel Test - gerçek Kalite Güvencesi ve performans testi, üretim trafiğiyle üretim altyapısı üzerindedir. Kapsamlı performans laboratuvarları ve hazırlık ortamları oluşturmak için zaman kaybetmeyin.

Deney yapma - yeni bir özelliğin temel performans göstergelerinizdeki iğneyi nasıl hareket ettirdiğini öğrenin.

Sorunlar Olduğunda Düzeltmelerden veya Kod Geri Almalardan Kaçınma - hem düzeltmeler hem de kod geri dönüşleri streslidir, uzun zaman alır ve gereğinden fazla soruna yol açar. Bunun yerine özelliği kapatın veya azaltın.

Diğerleri açık kaynak kitaplıklardan bahsetmiştir. Gatekeeper ve Lix gibi - - tam çözümün iyi bir örnektir Bölünmüş . Split için çalışıyorum.

Burada birçok harika cevap var, hepsi Martin Fowler gönderisinde popüler olan önemli, temel tanıma dayanıyor :

Bunlar, "ekiplerin, kodu değiştirmeden sistem davranışını değiştirmesine [izin veren] kod parçalarıdır."

Dolayısıyla tarihsel olarak sözde kodla temsil edildiklerini düşündük:

if(app_settings["beta-mode"] == "true")
  showAwesomeNewGui();
else
  sameOldSnoozeFeset();

Bu, bunu düşünmenin tamamen doğru bir yolu ve hem Matt hem de Adil, özellik bayrağı için çeşitli taktik kullanım durumlarıyla güzel bir şekilde genişletiyor.

Ancak, dotnetdev'in orijinal soruyu sorduğundan bu yana altı yılda gerçekliğin nasıl geliştiğini ve değiştiğini yansıtan gözden geçirilmiş bir tanım sunmak istiyorum. Özellikli bir bayrak platformu olan Rollout.io için çalışıyorum , bu nedenle bu evrim için ön sırada yerim oldu.

Basitçe söylemek gerekirse, özellik bayrakları artık uygulamanızda işlevsellik parçalarını açıp kapatmanın bir yolu değil. Bu, "bu bir açıklama ve bir para birimi miktarıdır" diyerek "fatura satır öğesi nedir" yanıtını vermeye benzer. Doğru, ancak faturanın daha geniş noktasını etkilemiyor.

Özellik bayrakları, modern yazılımda kapsamlı bir stratejik çözümün taktiksel parçalarıdır. Daha fazla bilgiye sahip olduğunuz çalışma zamanına kadar kodunuzdaki önemli karar mantığını ertelediğiniz araçlardır. Ve belki de en önemlisi, sürüm numarasının 2.7'den büyük olup olmadığını görmek için tek bir kontrolle artık tek başlarına ortaya çıkmıyorlar; Bunları kullanan kuruluşlar, genellikle bunları kapsamlı, sistem çapında bir ürün yaklaşımının parçası olarak dahil eder.

Diğerlerinin de belirttiği gibi, Facebook ve LinkedIn buna öncülük etti, ancak 2018'de pek çok kuruluş bunu yapıyor. Geliştirme stratejisinin, operasyon stratejisinin (veya isterseniz DevOps stratejisinin) ve ürün stratejisinin bir parçası olarak çalışma zamanı için karar mantığı sorularını erteliyorlar. İşte bu tür soruların örnekleri.

• Kullanıma sunduğumuz yeni yönetici ekranını kimler, ne zaman görmeli?
• Bu Paskalya yumurtasının kilidini açmak için hangi üyelik seviyesi gerekiyor?
• Yeni veri tabanına ne zaman geçmeliyiz?
• Dönüşümleri iyileştirmek için ödeme düğmesine bir çitanın veya kartalın resmini koymalı mıyız?

Bu tür kararların önemli bir kısmını çalışma zamanına kadar erteleyen bir uygulamaya sahip olmak için, uygulamanıza anlık olarak özellik bayrakları atamazsınız veya kendinizi teknik borca ​​gömersiniz. Bu günlerde, birkaç farklı bileşen içeren kapsamlı bir özellik bayrağı yönetimi stratejisine sahip olmanız gerekiyor.

• Geçiş noktaları , yeni özelliklerin davranışını değiştirmek için kullanılır.
• Bir geçiş yönlendiricisi oluşturmak için birden çok geçiş noktası bir araya gelir . Geçişli bir yönlendirici, bir özelliğin durumunu belirler.
• Geçiş bağlamı , geçiş yönlendiricisine gerekli bağlamsal bilgileri sağlar (örneğin, belirli bir kullanıcı).
• Toggle configuration , ortam hakkında geçiş yönlendiricisi bilgilerini sağlar.

Öyleyse, sonunda, özellik bayrakları nelerdir?

Bunlar, hem teknik hem de pazar ihtiyaçlarına uyarlanabilen bir uygulamaya sahip olmak için daha geniş bir stratejinin önemli bir parçasıdır.

Özellik işareti (özellik çevirme veya özellik değiştirme olarak da bilinir ), potansiyel olarak pahalı bir özelliği gerektiği gibi etkinleştirmek veya devre dışı bırakmak için kullanılan bir anahtardır (örneğin, bir site beklenmedik bir trafikle dövüldüğünde). Bu, ölçeklenene kadar veya yük artışı gidene kadar size biraz zaman kazandırır.

İşte SWIG belgelerinden bir örnek .

Benim şirketimde bunun için kendi çözümümüz vardı. .jsonHer uygulama için indirilebilir bir config ( ) dosyası sağlayan bir hizmet oluşturduk . Bu yapılandırmada, özellikler için bayrakları sakladık. Bu yapılandırmaya bağlı olarak, uygulama mevcut özelliği gösterebilir veya gizleyebilir. (Örneğin, kenar çubuğunda bir menü öğesini gösterin veya gizleyin).

Ayrıca özellik bayraklarını yapılandırabileceğimiz dahili bir yönetici sayfası da oluşturduk. Bir süre oldukça iyi çalıştı, ancak bundan sonra kullanıcı hedefleme ve A / B testi yapmak isterdik. Kendi başına geliştirmek Çok fazla çaba gerektiriyordu, bu yüzden üçüncü taraf bir çözüm seçtik. Burada daha önce de belirtildiği gibi bunun için birçok çözüm var.

ConfigCat'i , özelleştirilmiş hedef grupları ve yüzdeye dayalı sunumu aynı anda desteklediği için seçtik . Sen desteklenen açık kaynak SDK'lerini kontrol edebilirsiniz github .

Özellik bayrakları (veya özellik geçişleri), uygulamayı yeniden oluşturmanıza / yeniden dağıtmanıza gerek kalmadan bir uygulamada özellikleri uzaktan etkinleştirmenize olanak tanır. Bu, kodu üretime dağıtmanıza, ancak hazır olana kadar özelliği yayınlamanıza izin vermez. Belirli kullanıcıları hedefleyebilirsiniz, böylece beta kullanıcılarınızın test etmesi için yeni bir özelliği etkinleştirebilirsiniz.

Şirketimizde daha önce LaunchDarkly'yi ve FeatureFlags.io'nun diğer önerilerini kullandık . Ayrıca, bunu denemek ve yapmak için Firebase'in Uzaktan Yapılandırmasını kullanmayı denedik, ancak bunun bu amaç için pek uygun olmadığını gördük.

Sonunda açık kaynaklı bulduğumuz Bullet Train adlı kendi versiyonumuzu geliştirdik . Hem Özellik Bayraklarını / Geçişlerini hem de Uzaktan Yapılandırmayı birleştirir.

Özellik Bayrakları birkaç amaç için kullanılır. Genel fikir, hangi kullanıcının hangi özelliği gördüğü üzerindeki kontrolü bir tür uzak kontrol paneline veya arka ofise devretmektir.

Kodda bir özellik işaretlendiğinde, uygulamanızda hangi kullanıcının onu gördüğünü belirlemek için artık birkaç yöntem kullanabilirsiniz: 1. Açık / Kapalı - özelliği tüm kullanıcılarınıza gösterin veya hiçbirine göstermeyin. 2. Aşamalı Yayın - özelliği kullanıcılarınızın yalnızca belirli bir yüzdesine gösterin, ardından kademeli olarak tüm kullanıcılara gösterin. 3. Hedefleme - özelliği, o kullanıcının özelliklerine veya özelliklerine göre belirli kullanıcılara gösterin.

Özellik Bayraklarını (booleanlar) ve Özellik Yapılandırmalarını (dizeler, sayılar vb.) Kontrol etmeye yardımcı olan araçlar genellikle Özellik Yönetim Platformları olarak adlandırılır. Özellik Yönetimi için Configz.io adında harika bir hizmet vardır.

Kodlama açısından bakıldığında, bir özellik bayrağı if, yazdığınız yeni bir kod parçasının etrafını saran bir ifade kadar basit olabilir . Ne zamanif true olarak değerlendirildiğinde (özellik bayrağı açık olduğunda), yeni kod çalıştırılacaktır.

Yazılım sunmanın gerçek dünyadan bir örneğinde, if yukarıda açıklanan ifade, yazılımın çalıştığı ortama bağlı olarak farklı şekilde değerlendirilir. Örneğin, uygulama QA sunucunuzda yürütülüyorsa, özellik bayrağı doğru olarak dönecek ve yeni özellik görüldü. Üretim sunucunuzda çalıştırılıyorsa, özellik bayrağı yanlış döndürür ve özellik gizlenir.

Kariyerim boyunca kişisel deneyimlerime göre özellik bayraklarını aşağıdaki şekillerde kullandım:

1. Özelliklerin müşterilere sunulmasından kod dağıtımlarının ayrılması. Bu, geliştirme sürecimizde özellik bayraklarını ilk kez kullanmamdı. Pazarlama ve ürün ekibimiz ile geliştirme ve sürümleri yapan mühendislik ekibi arasındaki bağımlılığı ortadan kaldırmak için kullandık. Özellik bayrakları, kodumuzu lansmandan haftalar önce dağıtmamıza izin verirken, daha önce bir sürümden önceki gece kodu dağıtıyorduk!

2. Üretimde test. Özellik bayraklarını kullanmadan önce kodumuzu yayınladığımızda bu bir ya hep ya hiç olayıydı, ya tüm müşterilerimiz bu özelliği aldı ya da hiçbiri almadı. Bir seferde kullanıcıların küçük bir yüzdesine yeni bir özellik sunmamızı sağlamak için özellik bayrakları kullandık. Bu, tüm müşteri tabanında potansiyel sorunları riske atmadan yeni bir özellik hakkında değerli geri bildirim ve veriler toplamamıza olanak sağladı.

3. Geliştirme yaşam döngüsünde ortam başına bir özelliği etkinleştirme / devre dışı bırakma. Bunu, çok daha sorunsuz bir dağıtım sürecine izin vermek için geliştirme aşamasında kapsamlı bir şekilde kullandık - özellik bayraklarının kullanımının hayati olduğu bir CI / CD ardışık düzenimiz var.

4. Bir acil anahtar oluşturma. Uygulamamızın belirli özelliklerini, o sırada uygulamayla ilgili herhangi bir sorun yaşadığımızda bu özelliği 'kapatmamıza' izin veren bir özellik bayrağıyla sarmaladık. Örneğin, kendimizi ağır bir yük altında bulursak, soruna yardımcı olmak için web sitesinin bazı önemli olmayan özelliklerini kapatabiliriz.

Özellik bayrakları hakkında daha fazla bilgiyi buradan okuyabilirsiniz .

Kodunuza çeşitli şekillerde özellik bayrakları ekleyebilirsiniz.

1. Kendinizinkini oluşturabilir veya üçüncü taraf bir özellik bayrağı kitaplığı kullanabilir ve özellik bayrağı verilerinizi dağıtım paketinize dahil edilebilecek bir yapılandırma dosyasına ekleyebilirsiniz.
2. Kendinizinkini oluşturabilir veya bir üçüncü taraf unsur bayrağı kitaplığı kullanabilir ve özellik bayrağı verilerinizi çalışma zamanında yüklenebilen bir yapılandırma dosyasına ekleyebilirsiniz.
3. Sizin için tüm özellik bayrağı ihtiyaçlarınızı yönetmek için bulut tabanlı bir özellik bayrağı yönetimi hizmeti kullanabilirsiniz.

Kendi kitaplığınızı yazmak ilk başta iyi bir fikir gibi görünebilir ve genellikle bu şekilde başlayabilir. Bununla birlikte, kullanıcıların belirli bir yüzdesine yayma veya belirli kullanıcı gruplarını hedefleme gibi daha gelişmiş özellik bayraklarının kullanım durumlarını uygulamak istediğinizde kısa süre sonra sorunlarla karşılaşabilirsiniz. Kendi özellik bayrağı uygulamanızı oluşturmanın diğer bir sorunu, birden çok dil kullanıyorsanız, kodunuzu birden çok kez uygulamanız gerekmesidir.

Özellik bayraklarını kullanmanın en iyi ve en kolay yolu, Floodgate gibi bir çevrimiçi özellik bayrağı yönetim hizmetini kullanmaktır . Bu şekilde, platformdaki tüm ağır kaldırmadan yararlanabilirsiniz, bu da uygulamanız için özellik oluşturmaya konsantre olmanızı sağlar.

NET SDK kullanarak bir uygulamaya Floodgate özellik bayrağı eklemenin bir örneğini burada bulabilirsiniz.

using FloodGate.SDK;

var floodgateClient = new FloodGateClient("API-KEY");

var flag = floodgateClient.GetValue("a-new-feature", false);

if (flag)
{
  // Execute the code for my new feature here...
}

Bir geliştirme ekibinde çalışıyorsanız ve özellik bayrakları kullanmıyorsanız ve ekip içinde dağıtımlarda ve kod yönetiminde sorunlar yaşıyorsanız. Özellik bayraklarını kullanmak, bu sorunları çözmenin harika bir yolu olabilir. Ekiplerinizin gelişim hızını hızlandıran özellik bayraklarının güzel bir yan etkisi de vardır.

Martin Fowler, burada okumanızı tavsiye ettiğim özellik bayraklarının çok derinlemesine bir yazımını veriyor .

Anladığım kadarıyla, özellik bayrakları, hangi kullanıcıların belirli özellikleri alacağına karar vererek işlevselliği sınırlamanıza yardımcı olur.

Örneğin, sadece beta kullanıcılarınızın yeni bir özelliği görmesini istediğinizi varsayalım. Bu özelliği beta kullanıcıları için "açıp kapatırsınız" ve diğer kullanıcılarınız bunu görmez.

LDUser user = new LDUser("user@test.com");

boolean showFeature = ldClient.toggle("your.feature.key", user, false);

if (showFeature) {
     // application code to show the feature 
 }
else {
     // the code to run if the feature is off
 }

LaunchDarkly'nin bazı ön uç JS A / B testleri için özellik bayraklarını test ediyorum - iyi çalışıyor gibi görünüyor. Özellik geçişleri ve özellik bayrağı kitaplıkları için bu siteye de bakabilirsiniz .

Özellik Bayrakları, temel olarak, kodda herhangi bir değişiklik yapmadan veya yeni bir sürüm yayınlamadan bir özelliği açıp kapatmanıza olanak tanır. Bu, özellikle mobil uygulama geliştiricileri için önemli bir çözümdür çünkü kullanıcıların uygulamalarını yeni bir sürüme güncelleme konusunda kontrolleri yoktur.

Mobil uygulama geliştiricileri için bu hizmeti veren birkaç şirket var.

• apptunnel.com
• apptimize.com
• launchdarkly.com

Şirketimde, SaaS uygulamamızda sunduğumuz her yeni özellik için özellik bayrakları kullanıyoruz. Performansın faydalarının yanı sıra, yeni özellikleri kademeli olarak kullanıma sunmamıza da olanak tanıyor - önce güçlü kullanıcılara yeni özellikler sunmak, onlardan geri bildirim almak ve tüm kullanıcılara sunmadan önce doğaçlama yapmak.

Ayrıca, bireysel kullanıcılara sunulan teklifleri özelleştirmemize olanak tanır - uzman kullanıcılar tüm özellikleri ister; basit kullanıcılar sadece temel şeyleri isteyebilir ve tüm güçlü karmaşık özelliklerle kafaları karışabilir. Ayrıca satış ekibimizin ek satış yapmasına da olanak tanır.

Ve elbette, diğerlerinin de belirttiği gibi, bir özelliğin performans düşüşüne neden olduğunu tespit edersek, o özelliği kapatabiliriz (ya tüm müşteriler için ya da bir soruna neden olan tek bir müşteri için).