Aracılığıyla paylaş


Özellik bayraklarıyla aşamalı deneme

DevOps ekipleri, özelliklerin sürekli teslimine odaklanan bir Çevik metodolojisine geçtikçe, kullanıcıların nasıl kullanılabilir hale geldiğini denetleme gereksinimi giderek daha önemli hale gelir. Özellik bayrakları, pazarlama amacıyla veya üretim ortamında test amacıyla yeni özelliklere kullanıcı erişimini sınırlamak için harika bir çözüm sağlar.

Dağıtım ve açığa çıkarma ayırma

Özellik bayraklarıyla, ekip belirli bir özellik kümesinin kullanıcı deneyiminde görünür olup olmayacağını ve/veya işlevsellik içinde çağrılmayacağını seçebilir. Yeni özellikler, bu özellikler geniş erişim için kullanılabilir olmadan sıradan geliştirme sürecinin bir parçası olarak derlenebilir ve dağıtılabilir. Özelliklerin dağıtımı, bunların açığa alınmasından kolayca ayrılmıştır.

Bayraklar tek tek kullanıcıya ç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 ( bir kullanıcı, küçük bir grup veya herkes için) ekip, özelliği yeniden dağıtmak zorunda kalmadan açmak için özellik bayrağını değiştirebilir.

Özellik bayrağının kapsamı, özelliğin niteliğine ve hedef kitleye göre değişir. Bazı durumlarda özellik bayrağı, işlevselliği herkes için otomatik olarak etkinleştirir. Diğer durumlarda, bir özellik kullanıcı bazında etkinleştirilir. Teams, kullanıcıların istedikleri takdirde bir özelliği etkinleştirmeyi kabul etmelerini sağlamak için özellik bayraklarını da kullanabilir. Özellik bayraklarının uygulanma şekliyle ilgili bir sınır yoktur.

Erken geri bildirim ve deneme desteği

Özellik bayrakları, erken denemeleri desteklemenin harika bir yoludur. Bazı özelliklerin erken aşamalarında pürüzlü kenarları olabilir ve bu da yalnızca en erken benimseyenler için ilginç olabilir. Bu tam olarak hazır olmayan özellikleri daha geniş bir kitleye göndermeye çalışmak memnuniyetsizlik doğurabilir. Ancak devam eden bir özellikle ilgilenmek isteyen kullanıcılardan geri bildirim toplamanın avantajı çok değerlidir.

Hızlı kapatma anahtarı

Bazen bir şeyi kapatabilmek yararlı olabilir. Örneğin, yeni bir özelliğin amaçlandığı gibi çalışmadığını ve başka yerlerde sorunlara neden olan yan etkileri olduğunu varsayalım. Yeniden dağıtmaya gerek kalmadan güvenilir davranışa geri dönmek için yeni işlevselliği hızla kapatmak için özellik bayraklarını kullanabilirsiniz. Özellik bayrakları genellikle kullanıcı arabirimi özellikleri açısından düşünülse de, mimari veya altyapı değişiklikleri için de kolayca kullanılabilir.

Standart aşamalar

Microsoft, özellik bayraklarını açmak için standart bir dağıtım işlemi kullanır. İki ayrı kavram vardır: kademeler dağıtımlar ve aşamalar özellik bayrakları içindir. Halkalar ve aşamalar hakkında daha fazla bilgi edinin.

Aşamalar tamamen açığa çıkması veya açığa çıkmasıyla ilgili. Örneğin, ilk aşama bir ekibin hesabı ve üyelerin kişisel hesapları olabilir. Kullanıcıların çoğu yeni bir şey görmez çünkü bayrakların açık olduğu tek yer bu ilk aşamadır. Bu, bir ekibin bunu tam olarak kullanmasına ve denemesine olanak tanır. Ekip oturumunu kapattıktan sonra, belirli müşteriler özellik bayraklarının ikinci aşaması aracılığıyla bunu kabul edebilir.

Kabul et

Kullanıcıların mümkün olduğunda özellik bayraklarını kabul etmelerine izin vermek iyi bir uygulamadır. Örneğin, ekip kullanıcının tercihleri veya ayarlarıyla ilişkili bir önizleme panelini kullanıma sunabilir.

Screenshot of opt-in preview pane.

Telemetri ile bayrakları kullanma

Özellik bayrakları, güncelleştirmeleri artımlı olarak kullanıma sunmanın bir yolunu sağlar. Ancak ekiplerin daha geniş kapsamlı pozlamaya hazır olma durumunu ölçmek için doğru ölçümleri sürekli izlemesi gerekir. Bu ölçümler hem kullanım davranışını hem de güncelleştirmelerin sistem durumu üzerindeki etkisini içermelidir. Kötü bir şey olmuyor gibi göründüğü için her şeyin yolunda olduğunu varsayma tuzağından kaçınmak önemlidir.

Özellik bayrağı örneği

Aşağıdaki örneği göz önünde bulundurun. Ekip, çekme isteği kullanıcı arabiriminde Cherry-pick ve Revert için buraya birkaç düğme ekledi. Bunlar özellik bayrakları kullanılarak dağıtıldı.

Screenshot of pull request UI example.

Özellik bayraklarını tanımlama

Kullanıma sunulan ilk özellik Geri Al düğmesiydi. Çö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 ve bu da bölümün gerçekten uzun sürmesini önlemek için eski bayrakları kaldırmaya yönelik bir teşvik oluşturur. Bu dosyanın boyutunu denetlemeye yönelik doğal bir motivasyon olduğundan ekip eski bayrakları siler.

<?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çevesi, tüm ekip genelinde yeniden kullanımı ve ölçek ekonomilerini teşvik eder. İdeal olan, bir geliştiricinin merkezi bir mağazada bayrak tanımlayabilmesi ve altyapının geri kalanının onlar için işlenmesini sağlayabileceğiniz bir altyapıya sahip olmasıdır.

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

Burada kullanılan özellik bayrağı SourceControl.Revert olarak adlandırılır. İşte bu sayfadaki özellik kullanılabilirlik denetimi çağrısını gösteren gerçek TypeScript.

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österilmektedir, ancak C# kullanılarak da kolayca erişilebilir. Kod özelliğin etkinleştirilip etkinleştirilmediğini denetler ve etkinse işlevselliği sağlamak için bir düğme oluşturur. Bayrak etkin değilse düğme atlanır.

Özellik bayrağını denetleme

İyi bir özellik bayrağı platformu, belirli bir bayrağın ayarlanıp ayarlanmayacağını yönetmek için birden çok yol sağlar. Genellikle bayrağın PowerShell ve web arabirimi aracılığıyla denetlenecek kullanım senaryoları vardır. PowerShell için, gerçekten kullanıma sunulmaları gereken tek şey, özellik bayrağının durumunu almanın ve ayarlamanın yolları ve varsa belirli kullanıcı hesabı tanımlayıcıları gibi öğeler için isteğe bağlı parametrelerdir.

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

Aşağıdaki örnek, ekip tarafından bu ürün için kullanıma sunulan web kullanıcı arabirimini kullanır. SourceControl.Revert için özellik bayrağını not edin. Burada iki kişisel hesap listelenmiştir: hallux ve buckh-westeur. Eyalet, Orta Kuzey'de olan hallux için ayarlanmış ve Batı Avrupa'daki diğer hesap için temizlenmiş.

Screenshot of controlling feature flags through web UI.

Özellik bayrağının doğası, özelliklerin kullanıma sunulduğu yolu yönlendirir. Bazı durumlarda, pozlama bir halka ve sahne modelini izler. Diğer kullanıcılar yapılandırma kullanıcı arabirimini veya erişim için ekise e-posta göndererek kabul edebilir.

Özellik bayrakları için dikkat edilmesi gerekenler

Özellik herkese dağıtıldıktan sonra özellik bayraklarının çoğu kullanımdan kaldırılabilir. 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ğı incelemesi 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 devredildikten sonra altyapı dışı bir şeyi dallandıran bir özellik bayrağı tutmak isteyebilir. Bununla birlikte, bu olası kod yolu gelecekte özellik bayrağının açıkça temizlenmesi sırasında yeniden etkinleştirilebilir, bu nedenle seçenek kaldırılana kadar test edilmesi ve korunması gerekir.

Özellik bayrakları ve dallanma stratejisi

Özellik bayrakları, geliştirme ekiplerinin başka kimseyi etkilemeden içinde eksik özellikler main içermesini sağlar. Kod yolu bir özellik bayrağının arkasında yalıtılmış olduğu sürece, normal kullanımı etkileyen yan etkiler olmadan bu kodu oluşturmak ve yayımlamak genellikle güvenlidir. Ancak, bir özelliğin REST uç noktasını kullanıma sunarken olduğu gibi bağımlılıklar gerektirdiği durumlar varsa, ekipler bu bağımlılıkların özellik kullanıma sunulmadan bile nasıl güvenlik veya bakım çalışması oluşturabileceğini göz önünde bulundurmalıdır.

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üşüm geçiriyor olabilir. Bu senaryoda, geliştiricinin kısa bir süre için bir özellik dalı oluşturması gerekir. Daha sonra dalda dengeleyici değişiklikler yapar ve özelliği bir bayrağın arkasında tutar. Popüler uygulamalardan biri, ekiplerin herhangi bir zarar vermedikleri anda değişiklikleri main birleştirerek birleştirmeleridir. Bu, tamamlanmamış özelliği bir özellik bayrağının arkasında gizli tutma özelliği olmadan mümkün olmaz.

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

Geliştirme aşamasında ele alınan sağduyul uygulamaları izlerseniz, DevOps döngüsünü sıkılaştırmanın iyi bir yoludurmain. Geliştiriciler özellik bayraklarıyla birleştirildiğinde, yukarı akış özelliklerini hızla birleştirebilir ve test gauntlet'i aracılığıyla gönderebilir. Kalite kodu üretimde test için hızla yayımlanabilir. Geliştiriciler birkaç sprint'in ardından özellik bayraklarının avantajlarını tanıyacak ve proaktif olarak kullanacaktır.

Özellik bayrağının kullanılıp kullanılmayeceğine karar verme

Özellik ekipleri belirli bir değişiklik için özellik bayrağı gerekip gerekmediğine ilişkin kararın sahibidir. Her değişiklik bir değişiklik gerektirmez, bu nedenle belirli bir değişiklik yapmayı seçtiğinde geliştirici için bir karar çağrısıdır. Daha önce açıklanan Geri Döndür özelliği söz konusu olduğunda, pozlamayı denetlemek için bir özellik bayrağı kullanmak önemliydi. Ekiplerin özellik alanlarıyla ilgili önemli kararlara sahip olmalarına izin vermek, etkili bir DevOps kuruluşunda özerklik sağlamanın bir parçasıdır.

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

Kendi özellik bayrağı altyapınızı oluşturmak mümkün olsa da LaunchDarkly veya Split gibi bir platformu benimsemeniz önerilir. Özellik bayrağı işlevselliğini yeniden oluşturmak yerine özellik 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 edinin.