如何在gitlab-ce中启用功能标志？

Question

我们将我们的自托管gitlab-ce升级到了最新的11.11版本，该版本引入了多个审阅者合并请求审批功能。虽然通过gitlab-rails console实现了this needs to be explicitly enabled。

在运行我们的gitlab实例的机器上，我运行了gitlab-rails console并进入了一个ruby控制台，在那里我输入了Feature.enable(:approval_rules)并按下了Enter，但是我得到了：

>> Feature.enable(:approval_rules)
Nothing known about Feature.enable(

我没有太多使用ruby的经验，所以我不确定我做错了什么。我在网上搜索，但我找到了关于如何使用Ruby的“功能标志”进行开发的文档，但没有找到如何让它们成为应用程序的最终用户的文档。

Answer 1

您可以通过GitLab接口来实现。

使用有效负载发布到https://gitlab.myhost.com/api/v4/features/approval_rules

{
    "value": true
}

https://docs.gitlab.com/ee/api/features.html

此外，我发现新的审批规则工作流在从11.9升级到11.10时会自动启用，尽管我的体验可能有所不同。如果您对API端点执行GET，您将能够看到其当前状态。

如果已经启用了该功能，您可能会将新的审批规则实现与EE功能Multiple Approval Rules混淆。我只提到由于你问题中的-ce标签。

Answer 2

对于GitLab 13.5 (2020年10月)，所有人都可以使用实际的功能标志：

功能标志在所有层都可用

• 在GitLab 11.4中，we introduced Feature Flags。
• 在GitLab 12.2中，我们引入了percent rollout和user ID Feature Flag strategies.
• In GitLab 13.1，我们引入了Feature Flag user lists并支持每个and的multiple Feature Flag strategies

今年早些时候，我们承诺将moving 18 features用于我们的开源核心产品，并通过在上一版本的Starter中提供功能标志来实现这一承诺的第一步。

现在我们已经正式完成了将Feature Flags移到我们的核心产品中。我们很高兴将这些功能提供给更多的GitLab社区，并看到它将对您的开发工作流程产生积极影响。

参见Documentation和Issue。

这包括，仍然使用GitLab 13.5 (2020年10月)：

功能标记灵活的部署策略

当您现在使用percent rollout策略时，粘性或体验一致性仅由用户ID决定。这可能是有限的；例如，匿名用户不会受到此策略的影响。

通过允许您基于会话ID、用户ID或随机定义粘性(无粘性)，我们改进了此推出策略。这使您可以更好地控制卷展栏，并支持匿名用户的粘性。

参见Documentation和Issue。

feature flag API更多的是关于创建/更新/删除。

您必须使用才能启用/禁用功能标志。

Feature.disable(:feature_flags_new_version)
Feature.enable(:feature_flags_new_version)

另请参阅GitLab 13.6 (2020年11月)

更改功能标志时的

Fire Webhook

作为开发人员，您可以使用GitLab的webhook特性来处理各种事件，例如MR事件、管道事件、作业事件和部署事件。在此版本中，您现在可以在打开或关闭功能标志时使用webhook事件。此添加简化了更新CI/CD管道、接收事件的Slack通知等操作的流程。非常感谢Sashi对社区的巨大贡献！

参见Documentation和Issue。