Feature flag controls · Gitlab 中文文檔

# Feature flag controls > 原文：[https://docs.gitlab.com/ee/development/feature_flags/controls.html](https://docs.gitlab.com/ee/development/feature_flags/controls.html) * [Access](#access) * [Rolling out changes](#rolling-out-changes) * [Enabling a feature for preproduction testing](#enabling-a-feature-for-preproduction-testing) * [Enabling a feature for GitLab.com](#enabling-a-feature-for-gitlabcom) * [Communicate the change](#communicate-the-change) * [Process](#process) * [Feature flag change logging](#feature-flag-change-logging) * [Cleaning up](#cleaning-up) # Feature flag controls[](#feature-flag-controls "Permalink") ## Access[](#access "Permalink") 為了能夠在 GitLab Inc.提供的任何環境（例如分期和生產）中打開/關閉功能標記后面的功能，您需要訪問[Chatops](../chatops_on_gitlabcom.html)機器人. Chatops 機器人當前在 ops 實例上運行，該實例不同于[https://gitlab.com](https://gitlab.com)或[https://dev.gitlab.org](https://dev.gitlab.org) . 按照 Chatops 文檔[請求訪問權限](../chatops_on_gitlabcom.html#requesting-access) . 一旦您將訪問權限傳播到項目測試中，請運行： ``` /chatops run feature --help ``` ## Rolling out changes[](#rolling-out-changes "Permalink") 將更改部署到環境后，就該開始向我們的用戶推出該功能了. 沒有具體說明發布更改的確切過程，因為更改之間可能會有所不同. 但是，總的來說，我們建議逐步推出更改，而不是立即為所有人啟用更改. 我們還建議您在部署代碼*之前* *不要*啟用功能. 這使您可以將部署的功能與部署分開，從而更容易分別衡量兩者的影響. GitLab 的功能庫（使用[Flipper](https://github.com/jnunemaker/flipper) ，并在[功能標志過程](process.html)指南中進行了介紹）支持向用戶發布更改的時間百分比. 依次可以使用[GitLab Chatops](../../ci/chatops/README.html)進行控制. 有關功能標志命令的最新列表，請參見[源代碼](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb) . 請注意，該文件中的所有示例都必須在`/chatops run`之前. 如果收到錯誤消息"糟糕！不允許執行此操作. 該事件將得到報告." 這意味著您的 Slack 帳戶不允許更改功能標志，或者您沒有[訪問權限](#access) . ### Enabling a feature for preproduction testing[](#enabling-a-feature-for-preproduction-testing "Permalink") 作為功??能推出的第一步，您應該在[https://staging.gitlab.com](https://staging.gitlab.com)和[https://dev.gitlab.org](https://dev.gitlab.org)上啟用功能. 這兩個環境具有不同的范圍. `dev.gitlab.org`是具有內部 GitLab Inc.流量的生產 CE 環境，用于某些開發和其他相關工作. `staging.gitlab.com`有 GitLab.com 數據庫和知識庫的較小的子集，并沒有正常的交通. 登臺是 EE 實例，可以（非常）粗略估計您的功能在 GitLab.com 上的外觀/行為. 這兩個實例都已連接到 Sentry，因此請確保在啟用功能標志后測試功能時，檢查那里的項目是否存在異常. 對于這些預生產環境，應在功能相關的階段在 Slack 通道中運行命令. 例如，將`#s_monitor`通道用于 Monitor 階段"運行狀況"組開發的功能. To enable a feature for 25% of all users, run the following in Slack: ``` /chatops run feature set new_navigation_bar 25 --dev /chatops run feature set new_navigation_bar 25 --staging ``` ### Enabling a feature for GitLab.com[](#enabling-a-feature-for-gitlabcom "Permalink") 在[預生產](#enabling-a-feature-for-preproduction-testing)環境中成功[啟用功能](#enabling-a-feature-for-preproduction-testing)并驗證其安全性和正常工作后，您可以將更改發布到 GitLab.com（生產）. #### Communicate the change[](#communicate-the-change "Permalink") GitLab.com 上的某些功能標志更改應與公司部分進行溝通. 負責開發的人員需要確定這是否必要以及適當的通信級別. 這取決于功能及其可能產生的影響. 作為指導： * 對于低風險且易于回滾的簡單功能，只需繼續[在`#production`啟用該功能](#process) . * 對于將影響用戶體驗的功能，請考慮事先通知`#support_gitlab-com` . * 對于具有重大下游影響的功能（例如：打開/關閉 Elasticsearch 索引`#production` ），請考慮事先與`#production`協調. #### Process[](#process "Permalink") 在切換任何功能標志之前，請檢查 GitLab.com 上是否沒有正在進行的重大事件. 您可以通過檢查`#production`和`#incident-management` Slack 通道，或查找[未解決的事件問題](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/?scope=all&utf8=?&state=opened&label_name[]=incident) （盡管檢查日期和時間）來執行此操作. 我們不想在事件發生時進行更改，因為它會使實現事件的診斷和解決變得更加困難，并且由于無法評估發布是否沒有問題，因此在很大程度上會使發布過程無效. 如有疑問，請在`#production`中`#production` . 以下`/chatops`命令應在 Slack `#production`通道中執行. 當您開始啟用該功能時，請在您執行的第一個`/chatops`命令的 Slack 線程中鏈接到相關的功能標志發布問題，以便人們可以根據需要了解更改. 要在 25％的時間內啟用功能，請在 Slack 中運行以下命令： ``` /chatops run feature set new_navigation_bar 25 ``` 這將根據以下公式將功能標記設置為`true` ： ``` feature_flag_state = rand < (25 / 100.0) ``` 這將為 GitLab.com 啟用該功能，其中`new_navigation_bar`為該功能的名稱. 此命令*不*啟用用戶總量的 25％的功能. 而是在`enabled?`該功能時進行檢查`enabled?` ，它將在 25％的時間內返回`true` . 要為 25％的參與者（例如用戶，項目或組）啟用功能，請在 Slack 中運行以下命令： ``` /chatops run feature set some_feature 25 --actors ``` 這將根據以下公式將功能標記設置為`true` ： ``` feature_flag_state = Zlib.crc32("some_feature<Actor>:#{actor.id}") % (100 * 1_000) < 25 * 1_000] # where <Actor>: is a `User`, `Group`, `Project` and actor is an instance ``` 在開發過程中，應根據功能的性質來選擇演員. 對于以用戶為中心的功能： ``` Feature.enabled?(:feature_cool_avatars, current_user) ``` 對于組或名稱空間級別的功能： ``` Feature.enabled?(:feature_cooler_groups, group) ``` 對于項目級別的功能： ``` Feature.enabled?(:feature_ice_cold_projects, project) ``` 如果不確定要使用什么百分比，只需使用以下步驟： 1. 25% 2. 50% 3. 75% 4. 100% 在每個步驟之間，您都需要稍等片刻，并在[https://dashboards.gitlab.net](https://dashboards.gitlab.net)上監視適當的圖形. 等待的確切時間可能有所不同. 對于某些功能，幾分鐘就足夠了，而對于其他功能，您可能要等待幾個小時甚至幾天. 這完全取決于您，只要確保將其清楚地傳達給您的團隊和生產團隊即可，如果您預計任何潛在的問題. 功能門也可以基于`gitlab` ，例如，可以首先僅對`gitlab`項目啟用功能. 通過提供`--project`標志來傳遞項目： ``` /chatops run feature set --project=gitlab-org/gitlab some_feature true ``` 對于組， `--group`標志可用： ``` /chatops run feature set --group=gitlab-org some_feature true ``` 請注意，基于角色的門適用于百分比. 例如，如果您運行以下兩個命令，則將`group/project`視為`gitlab-org/gitlab`并將給定的示例功能視為`some_feature` ： ``` /chatops run feature set --project=gitlab-org/gitlab some_feature true /chatops run feature set some_feature 25 --actors ``` 然后將為 25％的參與者同時啟用`some_feature` ，并且始終在與`gitlab-org/gitlab`交互時`gitlab-org/gitlab` . 如果特征標記開發使用組參與者，這是一個好主意. ``` Feature.enabled?(:some_feature, group) ``` **注意：**如果要確保用戶始終開啟或關閉某項功能，則**時間百分比分布**不是一個好主意. 在這種情況下， **"參與者百分比"**展示是一種更好的方法. 最后，要在盡可能多的情況下驗證該功能被認為是穩定的，您應該通過運行以下命令**全局**啟用該標志來全面推出該功能： ``` /chatops run feature set some_feature true ``` 這會將功能標志狀態更改為始終**啟用** ，從而覆蓋上述過程中現有的門（例如`--group=gitlab-org` ）. ### Feature flag change logging[](#feature-flag-change-logging "Permalink") 任何影響 GitLab.com（生產）的功能標志更改都會自動記錄在問題中. 該問題是在[gl-infra / feature-flag-log](https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/-/issues?scope=all&utf8=?&state=closed)項目中創建的，它將至少記錄啟用功能標志的人員的 Slack 句柄，更改的時間和標志的名稱. 然后，該問題還將作為注釋標記發布到 GitLab 的內部[Grafana 儀表板上](https://dashboards.gitlab.net/) ，以使更改更加明顯. 問題格式的更改可以在[Chatops 項目中](https://gitlab.com/gitlab-com/chatops)提交. ## Cleaning up[](#cleaning-up "Permalink") 更改被視為穩定后，請提交新的合并請求以刪除功能標記. 這樣可以確保所有用戶和自我管理實例都可以使用該更改. 確保在此合并請求中添加?" feature flag"標簽，以便發行經理意識到更改隱藏在 feature 標志的后面. 如果必須將合并請求放入一個穩定的分支中，請確保還添加適當的`~"Pick into XY"`標簽（例如`~"Pick into 13.0"` ）. 有關更多詳細信息，請參見[過程文檔](process.html#including-a-feature-behind-feature-flag-in-the-final-release) . 從代碼庫中刪除功能門后，數據庫中仍然存在該標志也已部署的功能記錄. 將 MR 部署到每個環境后，可以刪除該記錄： ``` /chatops run feature delete some_feature --dev /chatops run feature delete some_feature --staging ``` Then, you can delete it from production after the MR is deployed to prod: ``` /chatops run feature delete some_feature ```