Feature flags process · Gitlab 中文文檔

# Feature flags process > 原文：[https://docs.gitlab.com/ee/development/feature_flags/process.html](https://docs.gitlab.com/ee/development/feature_flags/process.html) * [Feature flags for user applications](#feature-flags-for-user-applications) * [Feature flags in GitLab development](#feature-flags-in-gitlab-development) * [When to use feature flags](#when-to-use-feature-flags) * [Including a feature behind feature flag in the final release](#including-a-feature-behind-feature-flag-in-the-final-release) * [The cost of feature flags](#the-cost-of-feature-flags) # Feature flags process[](#feature-flags-process "Permalink") ## Feature flags for user applications[](#feature-flags-for-user-applications "Permalink") 本文檔僅涵蓋在 GitLab 本身的開發中使用的功能標志. 可以在[功能標志功能文檔中](../../user/project/operations/feature_flags.html)找到已部署的用戶應用程序中的[功能標志](../../user/project/operations/feature_flags.html) . ## Feature flags in GitLab development[](#feature-flags-in-gitlab-development "Permalink") 在決定是否應利用功能標志時，應考慮以下重點： * 默認情況下，功能標志應為**off** . * 功能標記應在代碼庫中保留盡可能短的時間，以減少對功能標記記帳的需求. * 使用功能標記的人員負責與負責的利益相關者清楚地傳達功能標記后面的功能狀態. 應該使用功能標記名稱以及明顯需要功能標記的默認狀態打開或關閉更新問題描述. * 合并進行更改以隱藏在功能標記后的請求，或刪除現有功能標記（因為認為功能穩定），必須分配?" feature flag"標簽. * 當功能開發將分散在多個合并請求中時，可以使用以下工作流程： 1. 在第一個合并請求中引入默認情況下**關閉**的功能標志. 2. 通過一個或多個合并請求提交增量更改，以確保只有在功能標記為**on 時**才能訪問添加的任何新代碼. 您可以在開發過程中在本地 GDK 上保持啟用功能標志. 3. When the feature is ready to be tested, enable the feature flag for a specific project and ensure that there are no issues with the implementation. 4. 準備宣布該功能時，創建一個合并請求，以添加有關該功能的[文檔](../documentation/feature_flags.html) ，包括[有關功能標志本身的文檔](../documentation/feature_flags.html)以及一個 changelog 條目. 在同一合并請求中，要么將功能標記翻轉為**默認狀態，**要么將其完全刪除以啟用新行為. 可能會想起功能標記將功能的發布延遲至少一個月（=一個發布）. 不是這種情況. 功能標記不必在特定時間段內停留（例如，至少一個版本），而是應該一直停留到功能被認為穩定為止. 穩定意味著它可以在 GitLab.com 上運行，而不會引起任何問題，例如中斷. 另請閱讀[功能標記](development.html)的[開發指南](development.html) . ### When to use feature flags[](#when-to-use-feature-flags "Permalink") 從 GitLab 11.4 開始，開發人員必須使用功能標志進行不重要的更改. 此類更改包括： * 新功能（例如，新的合并請求小部件，史詩等）. * 復雜的性能改進，可能需要在生產中進行其他測試，例如重寫復雜的查詢. * 對用戶界面的侵入性更改，例如新的導航欄或側邊欄的刪除. * 添加了對從第三方服務導入項目的支持. 在所有情況下，進行更改的人員都可以最好地決定是否需要功能標記. 例如，更改按鈕的顏色不需要功能標記，而更改導航欄則絕對需要一個功能標記. 如果您不確定是否需要功能部件標志，只需在合并請求中詢問一下，那些查看更改的人員可能會為您提供答案. 對 UI 元素使用功能標記時，請確保對基礎后端代碼*也*使用功能標記（如果有）. 這樣可以確保在啟用該功能之前絕對無法使用該功能. ### Including a feature behind feature flag in the final release[](#including-a-feature-behind-feature-flag-in-the-final-release "Permalink") 為了構建最終版本并向自我管理的用戶展示功能，功能標志至少應默認為**on** . 如果認為該功能穩定并且確信刪除該功能標志是安全的，請考慮完全刪除該功能標志. *強烈*建議在做出此決定之前**，至少在一天的** [**生產中** **全局**啟用](./controls.html#enabling-a-feature-for-gitlabcom)功能標志. 在此期間，有時會發現意外的錯誤. 從首次審查合并請求到將更改部署到 GitLab.com 的過程中，啟用默認情況下禁用的功能的過程可能需要 5 到 6 天. 但是，建議將此活動留出 10 到 14 天的時間，以解決無法預料的問題. 功能標記必須[根據其狀態（啟用/禁用）進行記錄](../documentation/feature_flags.html) ，并且當狀態更改時， **必須相應**地更新文檔. **注意：**請注意，合并功能標記的更改后不久，此類操作可使功能在 GitLab.com 上可用. 更改默認狀態或刪除功能標志必須在每月的 22 號之前*（至少在* 3-4 個工作日之前）進行，以便將更改包含在最終的自我管理版本中. 除此之外，功能標志后面的功能應： * 在所有 GitLab.com 環境中運行足夠長的時間. 該時間段取決于功能標志后面的功能，但是通常經驗法則是 2-4 個工作日應該足以收集足夠的反饋. * 在上述時間段內，該功能應向 GitLab.com 計劃內的所有用戶公開. 將功能暴露給較小的百分比或僅將一組用戶公開可能不會暴露出足夠多的信息來幫助您確定功能穩定性. 盡管很少使用，但即使使用了功能標志，發行經理也可能決定拒絕選擇或還原穩定分支中的更改. 如果更改被認為是有問題的，過于侵入性的，或者只是沒有足夠的時間來正確衡量更改在 GitLab.com 上的行為，則可能有必要. ### The cost of feature flags[](#the-cost-of-feature-flags "Permalink") 閱讀以上內容時，可能會想起此過程會增加很多工作. 幸運的是，事實并非如此，我們將說明原因. 在此示例中，我們將工作成本指定為一個數字，范圍從 0 到無窮大. 數量越大，工作越昂貴. 成本并*沒有*轉化時間，這只是相對于另一個測量一個變化的復雜性的一種方式. 假設我們正在構建一個新功能，并確定此功能的成本為 10.我們還確定，在不同位置添加功能標志檢查的成本為 1.如果不使用功能標志，并且我們的功能按預期工作，我們的總費用為 10.這是最好的情況. 最佳情況下的優化肯定會導致麻煩，而最壞情況下的優化幾乎總是更好. 為了說明這一點，假設我們的功能導致停機，并且沒有立即解決的方法. 這意味著我們必須采取以下步驟來解決停機問題： 1. 還原發行版. 2. 根據所做的更改，執行可能需要的所有清理. 3. 恢復提交，確保" master"分支保持穩定. 如果解決問題可能需要幾天甚至幾周的時間，那么這尤其必要. 4. 選擇還原提交到適當的穩定分支中，以確保在問題解決之前我們不會阻止任何將來的發行. 如歷史所示，這些步驟耗時，復雜，通常涉及許多開發人員，而且最糟糕的是：在解決問題之前，我們的用戶使用 GitLab.com 的體驗將很糟糕. 現在，我們假設所有這些的關聯成本為 10.這意味著在最壞的情況下（我們應該對其進行優化），我們的總成本現在為 20. 如果我們使用了功能標記，情況將會大不相同. 我們不需要還原版本，并且由于默認情況下功能標記是禁用的，因此我們不需要還原并選擇任何 Git 提交. 實際上，我們要做的就是禁用該功能，在最壞的情況下，執行清理. 假設這是 2 的成本.在這種情況下，我們的最佳案例成本是 11：構建功能部件的成本為 10：添加功能標志的成本為 1\. 現在最壞的情況是 13： * 10 構建功能. * 1 添加功能標志. * 2 禁用并清理. 在這里，我們可以看到，在最佳情況下，與不使用功能標記相比，所需的工作僅多一點. 同時，還原變更的過程已大大便宜了. In other words, feature flags do not slow down the development process. Instead, they speed up the process as managing incidents now becomes *much* easier. Once continuous deployments are easier to perform, the time to iterate on a feature is reduced even further, as you no longer need to wait weeks before your changes are available on GitLab.com.