Feature flag controls

Feature flag controls

为了能够在 GitLab Inc.提供的任何环境（例如分期和生产）中打开/关闭功能标记后面的功能，您需要访问Chatops机器人. Chatops 机器人当前在 ops 实例上运行，该实例不同于或https://dev.gitlab.org .

按照 Chatops 文档 .

一旦您将访问权限传播到项目测试中，请运行：

将更改部署到环境后，就该开始向我们的用户推出该功能了. 没有具体说明发布更改的确切过程，因为更改之间可能会有所不同. 但是，总的来说，我们建议逐步推出更改，而不是立即为所有人启用更改. 我们还建议您在部署代码之前 不要启用功能. 这使您可以将部署的功能与部署分开，从而更容易分别衡量两者的影响.

GitLab 的功能库（使用Flipper ，并在指南中进行了介绍）支持向用户发布更改的时间百分比. 依次可以使用GitLab Chatops进行控制.

有关功能标志命令的最新列表，请参见 . 请注意，该文件中的所有示例都必须在之前.

如果收到错误消息”糟糕！ 不允许执行此操作. 该事件将得到报告.” 这意味着您的 Slack 帐户不允许更改功能标志，或者您没有访问权限 .

作为功​​能推出的第一步，您应该在和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:

  1. /chatops run feature set new_navigation_bar 25 --dev
  2. /chatops run feature set new_navigation_bar 25 --staging

在环境中成功启用功能并验证其安全性和正常工作后，您可以将更改发布到 GitLab.com（生产）.

Communicate the change

GitLab.com 上的某些功能标志更改应与公司部分进行沟通. 负责开发的人员需要确定这是否必要以及适当的通信级别. 这取决于功能及其可能产生的影响.

作为指导：

  • 对于低风险且易于回滚的简单功能，只需继续在#production启用该功能 .
  • 对于将影响用户体验的功能，请考虑事先通知#support_gitlab-com .
  • 对于具有重大下游影响的功能（例如：打开/关闭 Elasticsearch 索引#production ），请考虑事先与#production协调.

Process

我们不想在事件发生时进行更改，因为它会使实现事件的诊断和解决变得更加困难，并且由于无法评估发布是否没有问题，因此在很大程度上会使发布过程无效.

如有疑问，请在#production中#production .

以下/chatops命令应在 Slack #production通道中执行.

当您开始启用该功能时，请在您执行的第一个命令的 Slack 线程中链接到相关的功能标志发布问题，以便人们可以根据需要了解更改.

要在 25％的时间内启用功能，请在 Slack 中运行以下命令：

  1. /chatops run feature set new_navigation_bar 25

这将根据以下公式将功能标记设置为true ：

  1. feature_flag_state = rand < (25 / 100.0)

这将为 GitLab.com 启用该功能，其中new_navigation_bar为该功能的名称. 此命令不启用用户总量的 25％的功能. 而是在enabled?该功能时进行检查enabled? ，它将在 25％的时间内返回true .

要为 25％的参与者（例如用户，项目或组）启用功能，请在 Slack 中运行以下命令：

  1. /chatops run feature set some_feature 25 --actors

这将根据以下公式将功能标记设置为true ：

在开发过程中，应根据功能的性质来选择演员.

对于以用户为中心的功能：

    对于组或名称空间级别的功能：

    1. Feature.enabled?(:feature_cooler_groups, group)

    对于项目级别的功能：

    1. Feature.enabled?(:feature_ice_cold_projects, project)

    如果不确定要使用什么百分比，只需使用以下步骤：

    1. 25%
    2. 50%
    3. 75%
    4. 100%

    功能门也可以基于gitlab ，例如，可以首先仅对gitlab项目启用功能. 通过提供--project标志来传递项目：

    对于组， --group标志可用：

    请注意，基于角色的门适用于百分比. 例如，如果您运行以下两个命令，则将group/project视为gitlab-org/gitlab并将给定的示例功能视为some_feature ：

    1. /chatops run feature set --project=gitlab-org/gitlab some_feature true
    2. /chatops run feature set some_feature 25 --actors

    然后将为 25％的参与者同时启用some_feature ，并且始终在与gitlab-org/gitlab交互时gitlab-org/gitlab . 如果特征标记开发使用组参与者，这是一个好主意.

    1. Feature.enabled?(:some_feature, group)

    注意：如果要确保用户始终开启或关闭某项功能，则时间百分比分布不是一个好主意. 在这种情况下， “参与者百分比”展示是一种更好的方法.

    最后，要在尽可能多的情况下验证该功能被认为是稳定的，您应该通过运行以下命令全局启用该标志来全面推出该功能：

    1. /chatops run feature set some_feature true

    这会将功能标志状态更改为始终启用 ，从而覆盖上述过程中现有的门（例如--group=gitlab-org ）.

    任何影响 GitLab.com（生产）的功能标志更改都会自动记录在问题中.

    该问题是在gl-infra / feature-flag-log项目中创建的，它将至少记录启用功能标志的人员的 Slack 句柄，更改的时间和标志的名称.

    然后，该问题还将作为注释标记发布到 GitLab 的内部 ，以使更改更加明显.

    问题格式的更改可以在Chatops 项目中提交.

    更改被视为稳定后，请提交新的合并请求以删除功能标记. 这样可以确保所有用户和自我管理实例都可以使用该更改. 确保在此合并请求中添加〜” feature flag”标签，以便发行经理意识到更改隐藏在 feature 标志的后面. 如果必须将合并请求放入一个稳定的分支中，请确保还添加适当的~"Pick into XY"标签（例如~"Pick into 13.0" ）. 有关更多详细信息，请参见 .

    从代码库中删除功能门后，数据库中仍然存在该标志也已部署的功能记录. 将 MR 部署到每个环境后，可以删除该记录：

    1. /chatops run feature delete some_feature --dev

    Then, you can delete it from production after the MR is deployed to prod: