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 ```