随着 DevOps 团队转向一种以持续交付功能为重点的敏捷方法，需要控制用户如何变得越来越重要。 功能标志是一个很好的解决方案，用于限制用户对新功能的访问权限，无论是出于营销目的还是 用于在生产环境中进行测试。
分离部署和曝光
使用 功能标志，团队可以选择给定的功能集在用户体验中是否可见，以及/或在功能中调用。 新功能可以作为普通开发过程的一部分生成和部署，而无需让这些功能可供广泛访问。 功能部署可以方便地将其暴露分离。
标志向单个用户提供运行时控制
标志还会一路向单个用户提供精细控制。 在启用功能时，无论是对于一个用户、一个小组还是每个人，团队只需更改功能标志即可使其亮起，而无需重新部署。
功能标志的范围因功能和受众的性质而异。 在某些情况下，功能标志将自动为每个人启用该功能。 在其他情况下，将逐用户启用一项功能。 Teams 还可以使用功能标志来允许用户选择启用功能（如果需要）。 实现功能标志的方式实际上没有限制。
支持早期反馈和试验
功能标志是支持早期试验的好方法。 某些功能可以早期有粗糙的边缘，这可能只对最早的采用者感兴趣。 试图将这些不太就绪的功能推送到更广泛的受众可能会产生不满。 但是，从愿意处理正在进行的功能的用户那里收集反馈的好处是无价的。
快速关闭开关
有时，能够关闭某些内容会很有帮助。 例如，假设新功能未按预期方式工作，并且存在导致其他地方问题的副作用。 可以使用功能标志快速关闭新功能，以便回滚到受信任的行为，而无需重新部署。 虽然在用户界面功能方面通常考虑功能标志，但它们也可以轻松地用于体系结构或基础结构的更改。
标准阶段
Microsoft使用标准推出过程来启用功能标志。 有两个单独的概念： 层 适用于部署， 阶段 用于功能标志。 详细了解 层和阶段。
阶段都与披露或曝光有关。 例如，第一阶段可以是团队帐户和成员的个人帐户。 大多数用户不会看到任何新内容，因为打开的唯一位置标志是此第一阶段。 这样，团队就可以充分利用和试验它。 团队注销后，选择客户将能够通过功能标志的第二阶段选择加入它。
选择加入
在可行的情况下，允许用户选择加入功能标志是一种好的做法。 例如，团队可能会公开与用户的首选项或设置关联的预览面板。
将标志与遥测配合使用
功能标志提供了一种以增量方式公开更新的方法。 但是，团队必须持续监视正确的指标，以衡量准备情况，以便更广泛地暴露。 这些指标应包括使用行为，以及更新对系统运行状况的影响。 请务必避免假设一切正常，只是因为似乎没有坏事发生。
功能标志示例
请考虑以下示例。 团队在拉取请求 UI 中添加了几个按钮，用于 “樱桃选取 ”和 “还原 ”。 这些标志是使用功能标志部署的。
定义功能标志
公开的第一项功能是 “还原 ”按钮。 解决方案使用 XML 文件定义所有功能标志。 在本例中，每个服务都有一个文件，这会创建一个激励措施，以删除旧标志，以防止分区变得非常长。 团队将删除旧标志，因为有一种自然动机来控制该文件的大小。
<?xml version="1.0" encoding="utf-8"?>
<!--
In this group we should register Azure DevOps specific features and sets their states.
-->
<ServicingStepGroup name="AzureDevOpsFeatureAvailability" … >
<Steps>
<!-- Feature Availability -->
<ServicingStep name="Register features" stepPerformer="FeatureAvailability" … >
<StepData>
<!--specifying owner to allow implicit removal of features -->
<Features owner="AzureDevOps">
<!-- Begin TFVC/Git -->
<Feature name="SourceControl.Revert" description="Source control revert features" />
通用服务器框架鼓励在整个团队中重复使用和规模经济。 理想情况下，项目将具有基础结构，以便开发人员只需在中央存储中定义一个标志，并为其处理其余基础结构。
在运行时检查功能标志
此处使用的功能标志名为 SourceControl.Revert。 下面是该页面中的实际 TypeScript，说明对功能可用性检查的调用。
private addRevertButton(): void {
if (FeatureAvailability.isFeatureEnabled(Flags.SourceControlRevert)) {
this._calloutButtons.unshift(
<button onClick={ () => Dialogs.revertPullRequest(
this.props.repositoryContext,
this.props.pullRequest.pullRequestContract(),
this.props.pullRequest.branchStatusContract().sourceBranchStatus,
this.props.pullRequest.branchStatusContract().targetBranchStatus)
}
>
{VCResources.PullRequest_Revert_Button}
</button>
);
}
}
上面的示例演示了 TypeScript 中的用法，但也可以使用 C# 轻松访问它。 代码检查是否启用了该功能，如果是，则呈现一个按钮来提供该功能。 如果未启用标志，则会跳过该按钮。
控制功能标志
良好的功能标志平台将提供多种方式来管理是否设置了给定标志。 通常，可以通过 PowerShell 和 Web 界面控制标志的使用方案。 对于 PowerShell，真正需要公开的所有作都是获取和设置功能标志状态的方法，以及特定用户帐户标识符等作（如果适用）的可选参数。
通过 Web UI 控制功能标志
以下示例使用团队为此产品公开的 Web UI。 请注意 SourceControl.Revert 的功能标志。 此处列出了两个个人帐户： hallux 和 buckh-westeur。 该州设置为 hallux，该州恰好在中北部，并清除了西欧的其他帐户。
功能标志的性质将驱动特征的公开方式。 在某些情况下，曝光将遵循层和阶段模型。 在其他人中，用户可能通过配置 UI 选择加入，甚至通过电子邮件向团队发送访问权限。
功能标志注意事项
向所有人推出功能后，大多数功能标志都可以停用。 此时，团队可以删除代码和配置中对标志的所有引用。 最好包括功能标志评审，例如在每个冲刺的开头。
同时，可能存在一组因各种原因而保留的功能标志。 例如，在生产服务完全切换后，团队可能想要保留一个功能标志，该标志在生产服务完全切换后一段时间内会分支某些基础结构。 但是，请记住，在显式清除功能标志期间，将来可能会重新激活此潜在的代码路径，因此需要在删除选项之前对其进行测试和维护。
功能标志和分支策略
功能标志使开发团队能够包括不完整的功能， main 而不会影响其他人。 只要代码路径在功能标志后面隔离，通常可以安全地生成和发布该代码，而不会影响正常使用。 但在某些情况下，如果某个功能需要依赖项，例如在公开 REST 终结点时，团队必须考虑这些依赖项如何创建安全或维护工作，即使没有公开该功能也是如此。
用于降低风险的功能标志
有时，新功能可能会引入破坏性或破坏性的变化。 例如，产品可能正在经历从宽数据库架构到长数据库架构的转换。 在这种情况下，开发人员应创建一个功能分支，以花费少量时间。 然后，他们在分支上做出不稳定的更改，并将该功能保留在标志后面。 一种流行的做法是团队在不会造成任何伤害的情况下立即合并更改 main 。 如果不能够将未完成的功能隐藏在功能标志后面，则这不可行。
功能标志可帮助主要工作
如果遵循 “开发 ”阶段讨论的常识做法，则采用 main 的方法是收紧 DevOps 周期的一种好方法。 与功能标志结合使用时，开发人员可以快速合并上游功能，并通过 测试 gauntlet 推送这些功能。 质量代码可以快速发布，以便在 生产环境中进行测试。 在几个冲刺之后，开发人员将认识到功能标志的优点，并主动使用它们。
如何确定是否使用功能标志
功能团队负责决定是否需要功能标志来做出给定更改。 并非每个更改都需要一个，因此在开发人员选择做出给定更改时，这是开发人员的判断要求。 对于前面讨论的 “还原 ”功能，请务必使用功能标志来控制曝光。 允许团队拥有有关其功能区域的关键决策是实现有效 DevOps 组织中的自治的一部分。
生成与购买
虽然可以生成自己的功能标志基础结构，但通常建议采用 LaunchDarkly 或 Split 等平台。 最好投资构建功能，而不是重新生成特征标志功能。
后续步骤
详细了解如何在 ASP.NET Core 应用中使用功能标志。