使用功能旗標進行漸進式實驗

隨著 DevOps 小組轉向專注於持續傳遞功能的敏捷式方法，需要控制使用者如何變得越來越重要。 功能旗標是限制使用者存取新功能的絕佳解決方案，無論是為了行銷目的，還是在 生產環境中進行測試。

分離部署和暴露

使用 功能旗標，小組可以選擇在用戶體驗和/或功能內叫用的指定功能集。 新功能可以建置並部署為一般開發程式的一部分，而不需要這些功能可供廣泛存取。 功能部署與暴露程度方便分離。

旗標可向下提供運行時間控制給個別使用者

旗標也會一路提供細微的控制給個別使用者。 在啟用功能的時候，無論是針對一位使用者、一個小群組或每個人，小組只要變更功能旗標即可將功能旗標照亮，而不需要重新部署。

功能旗標的範圍會根據功能和對象的性質而有所不同。 在某些情況下，功能旗標會自動啟用每個人的功能。 在其他情況下，將會以用戶為基礎來啟用功能。 如果想要的話，Teams 也可以使用功能旗標來允許使用者選擇啟用功能。 功能旗標實作的方式確實沒有限制。

支援早期意見反應和實驗

功能旗標是支援早期實驗的絕佳方式。 有些功能可以有粗糙的邊緣，這可能只有最早的採用者。 試圖將這些尚未就緒的功能推送到更廣泛的受眾，可能會產生不滿。 但是，從願意處理進行中功能的使用者收集意見反應的好處是無價的。

快速關閉開關

有時候，能夠關閉某些專案會很有説明。 例如，假設新功能無法以預期的方式運作，而且有副作用會導致其他地方的問題。 您可以使用功能旗標快速關閉新功能，以便復原至信任的行為，而不需要重新部署。 雖然功能旗標通常考慮在使用者介面功能方面，但它們也可以輕鬆地用於架構或基礎結構的變更。

標準階段

Microsoft 會使用標準推出程序來開啟功能旗標。 有兩個不同的概念： 通道 適用於部署，而 階段 適用於功能旗標。 深入瞭解 通道和階段。

階段都是關於洩漏或曝光的。 例如，第一個階段可能是小組帳戶和成員的個人帳戶。 大部分的使用者都不會看到任何新功能，因為開啟的唯一位置旗標是在這個第一階段。 這可讓小組充分利用並實驗。 小組註銷之後，選取客戶就能夠透過功能旗標的第二個階段加入加入。

選擇加入

最好讓使用者在可行時選擇加入功能旗標。 例如，小組可能會公開與使用者喜好設定或設定相關聯的預覽面板。

搭配遙測使用旗標

功能旗標提供以累加方式公開更新的方式。 不過，小組必須持續監視正確的計量，以測量整備程度以取得更廣泛的曝光。 這些計量應包含使用行為，以及更新對系統健康情況的影響。 請務必避免假設一切都沒事的陷阱，只是因為似乎沒有發生壞事。

功能旗標範例

請考慮下列範例。 小組在 提取要求UI中新增了櫻桃挑選 和 還原 的幾個按鈕。 這些是使用功能旗標部署的。

定義功能旗標

公開的第一個功能是 [ 還原] 按鈕。 解決方案會使用 XML 檔案來定義所有功能旗標。 在此案例中，每個服務都有一個檔案，這會建立移除舊旗標的獎勵，以防止區段變得非常長。 小組會刪除舊旗標，因為有自然動機可控制該檔案的大小。

<?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" />

通用伺服器架構鼓勵在整個小組中重複使用和規模經濟。 在理想情況下，專案會有基礎結構，讓開發人員只需在中央存放區中定義旗標，併為其處理其餘的基礎結構。

檢查運行時間的功能旗標

這裡使用的功能旗標名為 SourceControl.Revert。 以下是該頁面中的實際 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>
        );
     }
}

上述範例說明 TypeScript 的使用方式，但同樣容易使用 C# 來存取。 程式代碼會檢查功能是否已啟用，如果是，則會轉譯按鈕以提供功能。 如果未啟用旗標，則會略過按鈕。

控制功能旗標

良好的功能旗標平臺會提供多種方式來管理指定的旗標是否已設定。 一般而言，旗標的使用案例是透過PowerShell和Web介面來控制。 針對 PowerShell，真正需要公開的所有功能都是取得和設定功能旗標狀態的方法，以及適用時特定使用者帳戶標識碼等專案的選擇性參數。

透過 Web UI 控制功能旗標

下列範例會使用小組針對此產品公開的 Web UI。 請注意SourceControl.Revert的功能旗標。 這裡列出兩個個人帳戶： hallux 和 buckh-westeur。 該州設定為 hallux，該州恰好在中北部，並清除了西歐的其他帳戶。

功能旗標的本質將驅動特徵公開的方式。 在某些情況下，曝光將遵循環形和階段模型。 在其他人中，使用者可以透過設定UI加入加入，或甚至是透過電子郵件傳送小組來存取。

功能旗標的考慮

一旦功能推出給所有人，大部分的功能旗標都可以淘汰。 此時，小組可以刪除程式代碼和組態中旗標的的所有參考。 最好包含功能旗標檢閱，例如在每個短期衝刺開始時。

同時，可能會有一組基於各種原因而持續的功能旗標。 例如，在生產服務完全切換之後，小組可能會想要保留一個功能旗標，以分支某些基礎結構一段時間。 不過，請記住，在明確清除功能旗標期間，未來可能會重新啟用此潛在的程式代碼路徑，因此必須在移除選項之前進行測試和維護。

功能旗標和分支策略

功能旗標可讓開發小組在 中包含 main 不完整的功能，而不會影響其他人。 只要程式代碼路徑在功能旗標後面隔離，建置和發佈該程序代碼通常很安全，而不會影響一般使用方式的副作用。 但是，如果在某些情況下，功能需要相依性，例如在公開 REST 端點時，小組必須考慮這些相依性如何建立安全性或維護工作，即使不會公開該功能也一樣。

可降低風險的功能旗標

有時候新功能可能會帶來破壞性或破壞性的變更。 例如，產品可能正經歷從寬資料庫架構到長資料庫架構的轉換。 在該案例中，開發人員應該在少量時間內建立功能分支。 然後，他們在分支上進行不穩定的變更，並將此功能保留在旗標後面。 常見的做法是小組在變更不會造成任何傷害時立即合併變更 main 。 如果不能夠將未完成的功能隱藏在功能旗標後面，這就不可行。

功能旗標有助於主要運作

如果您遵循開發階段中所討論的常識做法，則使用 main 是收緊 DevOps 週期的好方法。 與功能旗標結合時，開發人員可以快速合併上游的功能，並透過 測試gauntlet加以推送。 品質程式代碼可以快速發佈，以 在生產環境中進行測試。 在進行一些短期衝刺之後，開發人員會辨識功能旗標的優點，並主動使用這些旗標。

如何決定是否要使用功能旗標

功能小組會擁有是否需要特定變更功能旗標的決定。 並非每個變更都需要一個，因此當開發人員選擇進行指定的變更時，這是開發人員的判斷呼叫。 在稍早討論的 還原 功能案例中，請務必使用功能旗標來控制曝光。 讓小組擁有其功能區域的重要決策，是啟用有效 DevOps 組織中自主的一部分。

組建與購買

雖然可以建置自己的功能旗標基礎結構，但通常建議採用 LaunchDarkly 或 Split 之類的平臺。 最好投資建置功能，而不是重建特徵旗標功能。

下一步

深入瞭解如何在 ASP.NET Core 應用程式中使用功能旗標。