Feature flags process

原文：https://docs.gitlab.com/ee/development/feature_flags/process.html

Feature flags process

Feature flags for user applications

本文档仅涵盖在 GitLab 本身的开发中使用的功能标志. 可以在功能标志功能文档中找到已部署的用户应用程序中的功能标志 .

Feature flags in GitLab development

在决定是否应利用功能标志时，应考虑以下重点：

  • 默认情况下，功能标志应为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. 准备宣布该功能时，创建一个合并请求，以添加有关该功能的文档 ，包括有关功能标志本身的文档以及一个 changelog 条目. 在同一合并请求中，要么将功能标记翻转为默认状态，要么将其完全删除以启用新行为.

可能会想起功能标记将功能的发布延迟至少一个月（=一个发布）. 不是这种情况. 功能标记不必在特定时间段内停留（例如，至少一个版本），而是应该一直停留到功能被认为稳定为止. 稳定意味着它可以在 GitLab.com 上运行，而不会引起任何问题，例如中断.

另请阅读功能标记的开发指南 .

When to use feature flags

从 GitLab 11.4 开始，开发人员必须使用功能标志进行不重要的更改. 此类更改包括：

  • 新功能（例如，新的合并请求小部件，史诗等）.
  • 复杂的性能改进，可能需要在生产中进行其他测试，例如重写复杂的查询.
  • 对用户界面的侵入性更改，例如新的导航栏或侧边栏的删除.
  • 添加了对从第三方服务导入项目的支持.

在所有情况下，进行更改的人员都可以最好地决定是否需要功能标记. 例如，更改按钮的颜色不需要功能标记，而更改导航栏则绝对需要一个功能标记. 如果您不确定是否需要功能部件标志，只需在合并请求中询问一下，那些查看更改的人员可能会为您提供答案.

对 UI 元素使用功能标记时，请确保对基础后端代码也使用功能标记（如果有）. 这样可以确保在启用该功能之前绝对无法使用该功能.

Including a feature behind feature flag in the final release

为了构建最终版本并向自我管理的用户展示功能，功能标志至少应默认为on . 如果认为该功能稳定并且确信删除该功能标志是安全的，请考虑完全删除该功能标志. 强烈建议在做出此决定之前，至少在一天的 生产中 全局启用功能标志. 在此期间，有时会发现意外的错误.

从首次审查合并请求到将更改部署到 GitLab.com 的过程中，启用默认情况下禁用的功能的过程可能需要 5 到 6 天. 但是，建议将此活动留出 10 到 14 天的时间，以解决无法预料的问题.

功能标记必须根据其状态（启用/禁用）进行记录 ，并且当状态更改时， 必须相应地更新文档.

注意：请注意，合并功能标记的更改后不久，此类操作可使功能在 GitLab.com 上可用.

更改默认状态或删除功能标志必须在每月的 22 号之前（至少在 3-4 个工作日之前）进行，以便将更改包含在最终的自我管理版本中.

除此之外，功能标志后面的功能应：

  • 在所有 GitLab.com 环境中运行足够长的时间. 该时间段取决于功能标志后面的功能，但是通常经验法则是 2-4 个工作日应该足以收集足够的反馈.
  • 在上述时间段内，该功能应向 GitLab.com 计划内的所有用户公开. 将功能暴露给较小的百分比或仅将一组用户公开可能不会暴露出足够多的信息来帮助您确定功能稳定性.

尽管很少使用，但即使使用了功能标志，发行经理也可能决定拒绝选择或还原稳定分支中的更改. 如果更改被认为是有问题的，过于侵入性的，或者只是没有足够的时间来正确衡量更改在 GitLab.com 上的行为，则可能有必要.

The cost of feature flags

阅读以上内容时，可能会想起此过程会增加很多工作. 幸运的是，事实并非如此，我们将说明原因. 在此示例中，我们将工作成本指定为一个数字，范围从 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.