Özellik bayraklarıyla aşamalı deneme

DevOps ekipleri özelliklerin sürekli teslimi üzerine odaklanan çevik bir metodolojiye geçtikçe, yeni özelliklerin açıklanmasına ilişkin denetim ihtiyacı giderek daha önemli hale gelir. Hedef, pazarlama amacıyla bu yeni özelliklere erişimi kısıtlamak veya hedef kitleyi üretimde test etmek amacıyla sınırlamak olsun,özellik bayrakları harika bir çözümdür.

Dağıtımı ve açıkları dağıtma

Özellik bayrakları, bir ekibin belirli bir özellik kümesine kullanıcı deneyiminde görünür olup olmadığını ve/veya işlev içinde çağrılıp çağrıl olmadığını belirten ayarlardır. Bu, takımın normal geliştirme sürecinin bir parçası olarak bu özellikleri oluşturmalarına ve dağıtmalarına olanak sağlar, ancak bu özelliklerin geniş erişim için kullanılabilir durumda olması engel olur. Bu hizmet, özelliklerin dağıtımının açık kalma durumlarından farklı bir şekilde dağıtımının kolay bir yolunu sunar.

Bayraklar tek tek kullanıcılara çalışma zamanı denetimi sağlar

Bayraklar ayrıca tek tek kullanıcıya kadar ayrıntılı denetim sağlar. Bir özelliği etkinleştirme zamanı geldiğinde, ister tek bir kullanıcı, ister küçük bir grup ister herkes için olsun, ekip özellik bayrağını değiştirip yeniden kullanmak zorunda kalmadan ışığını yantır.

Özellik bayrağının kapsamı, özelliğin doğasına ve hedef kitleye göre değişir. Bazı durumlarda özellik bayrağı, işlevselliği herkes için otomatik olarak çevirir. Diğer durumlarda, bir özellik kullanıcı bazında etkinleştirilebilir. Ekipler ayrıca, kullanıcıların bir özelliği etkinleştirme seçeneğini etkinleştirmek için özellik bayraklarını kullanmayı tercih etmelerini de tercih ediyor olabilir. Özellik bayraklarının uygulanma yolu için bir sınır yoktur.

Erken geri bildirim, deneme desteği

Özellik bayrakları, erken denemeyi desteklemek için harika bir yol sağlar. Bazı özelliklerin başında kaba kenarlar olabilir ve bu da yalnızca en erken benimseyenler için ilgi çekici olabilir. Bu hazır olmayan özellikleri daha geniş bir hedef kitleye itmeye çalışmak memnuniyetsizliğin bir ürünü olabilir. Ancak devam eden bir özelliği kullanmak isteyenlerden geri bildirim toplamanın avantajı çok değerlidir.

Hızlı kapatma düğmesi

Bazen bir şeyi kapatabiliyor olmak çok yararlı olabilir. Örneğin, yeni bir özelliğin amaçlanan şekilde çalışma çalıştığını ve başka yerlerde sorunlara neden olan yan etkiler olduğunu varsayalım. Özellik bayrakları, yeniden kullanımdan güvenilir davranışa geri dönmek için yeni işlevselliği hızlı bir şekilde kapatmanın harika bir yoludur. Özellik bayrakları genellikle kullanıcı arabirimi özellikleri olarak düşünse de, mimari veya altyapı değişiklikleri için de kolayca kullanılabilir.

Standart aşamalar

Microsoft'un özellik bayraklarını açmak için kullandığı standart bir rollout işlemi vardır. İki ayrı kavram vardır: halkalar dağıtımlara, aşamalar ise özellik bayrakları için kullanılır. Halkalar ve aşamalar hakkında daha fazla bilgi.

Aşamalar, açığa çıkması veya açığa çıkmasıyla ilgilidir. Örneğin, ilk aşama bir ekibin hesabı ve üyelerin kişisel hesapları olabilir. Bayrakların açık olduğu tek yer bu ilk aşama olduğundan, şu anda bir hizmette çalışan çok fazla şey muhtemelen kullanıcıların görmeyebilirsiniz. Bu, bir ekibin tam olarak kullanmalarını ve denemelerini sağlar. Takım, onay verdiktan sonra belirli müşteriler özellik bayraklarının ikinci aşaması aracılığıyla bu seçeneği kabul eder.

Kabul etmek

Kullanıcıların mümkün olduğunda özellik bayraklarını kabul etmek iyi bir uygulamadır. Örneğin, ekip kullanıcının tercihleri veya ayarlarıyla ilişkili bir önizleme panelini açığa çıkarır.

Telemetri ile bayrak kullanma

Özellik bayraklarıyla, takımlar güncelleştirmeleri artımlı olarak ortaya çıkarmanın bir yolunu sağlar. Ancak daha geniş bir açık için hazır olma durumunu tam olarak ölçmek için ekiplerin doğru ölçümleri sürekli izlemesi gerekir. Bu ölçümler kullanım davranışının yanı sıra güncelleştirmelerin sistem durumu üzerindeki etkisini de içermeli. Kötü bir şey olmuyor gibi görünüyorsa her şeyin yolunda olduğunu varsayma tuzaklarından kaçınmak önemlidir.

Özellik bayrağı örneği

Aşağıdaki örneği göz önünde bulundurabilirsiniz. Ekip, çekme isteği kullanıcı arabiriminde Tek tek seçme ve Geri Döndürme için birkaç düğme ekledi. Bunlar özellik bayrakları kullanılarak dağıtıldı.

Özellik bayraklarını tanımlama

İlk özellik Geri Döndür düğmesidir. Bu üründe çözüm, tüm özellik bayraklarını tanımlamak için bir XML dosyası kullanır. Bu durumda hizmet başına bir dosya vardır. Bu sayede bir ekibin bölümü çok uzun olursa temizlemenin zamanı geldi. Eski bayrakları silerler çünkü bu dosyanın boyutunu denetlemeye doğal bir motivasyon vardır.

<?xml version="1.0" encoding="utf-8"?>
<!--
  In this group we should register Azure DevOps specific features and sets their states.
-->
<ServicingStepGroup name="AzureDevOpsFeatureAvailability" … >
  <Steps>
    <!-- Feature Availability -->
    <ServicingStep name="Register features" stepPerformer="FeatureAvailability" … >
      <StepData>
        <!--specifying owner to allow implicit removal of features -->
        <Features owner="AzureDevOps">
           <!-- Begin TFVC/Git -->
           <Feature name="SourceControl.Revert" description="Source control revert features" />

Ortak bir sunucu çerçevesine sahip olmak, ekibin tamam genelinde birçok yeniden kullanımı ve ölçek ekonomisi sağlar. İdeal olarak, projenin bir geliştiricinin yalnızca merkezi bir depoda bayrak tanımlayarak altyapının geri kalanını onlar için işlemesini s gerektirecek şekilde bir altyapıya sahip olur.

Çalışma zamanında özellik bayraklarını denetleme

Burada kullanılan özellik bayrağı SourceControl.Revert olarak adlandırılmıştır. Bu sayfada yer alan ve özellik kullanılabilirlik denetimi çağrısını gösteren gerçek Typescript aşağıdadır.

private addRevertButton(): void {
 if (FeatureAvailability.isFeatureEnabled(Flags.SourceControlRevert)) {
     this._calloutButtons.unshift(
         <button onClick={ () => Dialogs.revertPullRequest(
             this.props.repositoryContext,
             this.props.pullRequest.pullRequestContract(),
             this.props.pullRequest.branchStatusContract().sourceBranchStatus,
             this.props.pullRequest.branchStatusContract().targetBranchStatus)
         }
         >
             {VCResources.PullRequest_Revert_Button}
         </button>
        );
     }
}

Yukarıdaki örnekte TypeScript kullanımı gösterilse de C# ile kolayca erişilebilir. Kod özelliğin etkinleştirildiğinden ve etkinleştirildiyse işlevi sağlamak için bir düğmeyi işler. Bayrak etkin değilse düğme atlanır.

Özellik bayrağını denetleme

İyi bir özellik bayrağı platformu, verilen bayrağın ayar olup olmadığını yönetmek için birden çok yol sağlar. Genellikle bayrağın PowerShell ve web arabirimi aracılığıyla denetlenen kullanım senaryoları vardır. PowerShell için, gerçekten açığa çıkar yapılması gereken tek şey, belirli kullanıcı hesabı tanımlayıcıları (varsa) gibi şeyler için isteğe bağlı parametrelerle birlikte bir özellik bayrağının durumunu alma ve ayarlama yollarıdır.

Web kullanıcı arabirimi aracılığıyla özellik bayraklarını denetleme

Aşağıda, ekip tarafından bu ürün için ortaya çıkacak web kullanıcı arabiriminin kullanımına bir örnek verilmiştir. SourceControl.Revert için özellik bayrağını not alma. Burada iki kişisel hesap listelenmiştir: hallux ve westeur. Durum, Hallux için ayarlanır ve bu durum Orta Kuzey'de olur ve bu durumdaki diğer hesap Batı Avrupa.

Özellik bayrağının doğası, özelliklerin açığa çıkarılama yolunu sağlar. Bazı durumlarda, maruz kalma halkası ve aşama modelini takip eder. Diğer kullanıcılar yapılandırma kullanıcı arabirimini veya hatta erişim için ekibi e-posta ile e-posta ile almayı tercih ediyor olabilir.

Özellik bayraklarıyla ilgili dikkat edilmesi gerekenler

Özellik bayraklarının çoğu, bir özellik herkese aktarıldıktan sonra devre dışı bırakıldı. Bu noktada ekip, kod ve yapılandırmada bayrağına yapılan tüm başvuruları silebilir. Her sprint'in başında olduğu gibi bir özellik bayrağı gözden geçirmesi eklemek iyi bir uygulamadır.

Aynı zamanda, çeşitli nedenlerle kalıcı olan bir özellik bayrakları kümesi olabilir. Örneğin ekip, üretim hizmeti tamamen devreddikten sonra altyapısal bir şeyi dallandıran bir özellik bayrağı tutmak istiyor olabilir. Ancak, bu olası kod yolu gelecekte özellik bayrağının açık bir şekilde temizleninceye kadar yeniden etkinleştirilebilir, bu nedenle seçenek kaldırılana kadar test edilecek ve bakımı yapılması gerekir.

Özellik bayrakları ve dallama stratejisi

Özellik bayrakları, geliştirme ekiplerinin başka birini etkilemeden main içinde tamamlanmamış özellikler içermesini sağlar. Kod yolu bir özellik bayrağının arkasında yalıtılmış olduğu sürece, normal kullanımı etkilemeden bu kodu derlemek ve yayımlamak genellikle güvenlidir. Ancak bir özelliğin bağımlılıklar gerektirdiği durumlar (örneğin REST uç noktasının açığa çıkarılama gibi) olması, ekiplerin bu bağımlılıkların özellik açığa çıkarılamasa bile güvenlik veya bakım çalışmalarını nasıl oluşturacağına dikkat ediyor olması gerekir.

Riski azaltmak için özellik bayrakları

Bazen yeni özellikler yıkıcı veya kesintiye neden olan değişikliklere neden olabilir. Örneğin, ürün geniş bir veritabanı şemasından uzun bir şemaya dönüştürmeden geçen bir durum olabilir. Bu senaryoda geliştiricinin kısa bir süre için bir özellik dalı oluşturması gerekir. Ardından dalda karartıcı değişiklikleri yapacak ve özelliği bayrağın arkasında tutacak. Popüler bir uygulama, ekiplerin herhangi bir zarara neden olmaz değişiklikleri birleştirerek en kısa sürede main birleştirmesidir. Tamamlanmamış özelliği bir özellik bayrağının arkasında gizli tutma özelliği olmadan bu mümkün olmaz.

Özellik bayrakları main ile çalışmaya yardımcı olur

geliştirme aşamasında tartışılan yaygın yöntemlere göre bir DevOps döngüsünün sıkılaştırmanın main iyi bir yolu içinde çalışmaktır. Geliştiriciler, özellik bayrakları ile birleştirerek özelliklerini yukarı akışta hızlıca bir araya ve test gauntlet'i aracılığıyla iletir. Bu, kalite kodunun üretimde test için hızla yayımlanır. Birkaç sprint'in ardından geliştiriciler özellik bayraklarını kullanmanın ve bunları proaktif olarak kullanmanın avantajlarını hemen fark ediyor.

Özellik bayrağı kullanıp kullanmama kararı verme

Özellik ekipleri, bir özellik bayrağına ihtiyaç olup olmadığı konusunda verilen karara sahiptir. Her değişiklik için bir değişiklik gerekli değildir, bu nedenle belirli bir değişiklik yapmak için geliştiricinin karar verme çağrısıdır. Daha önce ele alınan Geri Döndürme özelliğinde, özelliğin denetimli bir şekilde ele alınarak üretime alınarak üretime alına kona bir özellik bayrağının kullanımı önemliydi. Ekiplerin özellik alanıyla ilgili önemli kararlara sahip olması, etkili bir DevOps kuruluşunda otonomiyi etkinleştirmenin bir parçası.

Derleme ve satın alma karşılaştırması

Her ekip kendi özellik bayrağı altyapısını inşa ederken, mümkünse LaunchDarklygibi bir platformu benimsemeleri önerilir. Özellik bayrağı işlevselliğini yeniden oluşturma yerine özellikleri oluşturmaya yatırım yapmak tercih edilir.

Sonraki adımlar

ASP.NET Core uygulamasında özellik bayraklarını kullanma hakkında daha fazla bilgi.