部署新版本：功能标志还是环？

DevOps 使我们能够快速交付、从生产反馈中学习、做出更明智的决策并提高客户满意度、获取和保留率。我们需要在导致用户体验平淡或负面的功能上快速失败，并专注于产生积极影响的功能。渐进式发布是一种 DevOps 实践，基于功能标志和基于环的部署，它允许我们在生产环境中向选定的用户发布功能，以便在向所有用户发布之前进行观察和验证。

您可能正在问自己是否应该使用基于环的部署、功能标志或两者兼而有之，以支持您环境中的渐进式发布。让我们从探索这些策略开始。

环和功能标志

基于环的部署最初在 Jez Humble 的著作 Continuous Delivery 中作为金丝雀部署被讨论。环在逐步部署和确认生产环境中的更改的同时，限制了对最终用户的影响。通过环，我们通过观察、测试、遥测诊断以及最重要的用户反馈来评估影响或“爆炸半径”。环使逐步部署二进制位和并行运行多个生产版本成为可能。您可以收集反馈，而不会影响所有用户，停用旧版本，并在您确信一切正常运行时分发新版本。

下图显示了基于环的部署过程的实现

当您的开发人员完成包含对主分支的建议更改的拉取请求时，(1) 持续集成构建执行构建、单元测试，并触发自动发布到生产环境中的金丝雀环境。当您确信该版本已准备好在生产环境中进行用户验收和探索性测试时，(2) 您批准将该版本发布到早期采用者环。同样，当您确信该版本已准备好投入黄金时段时，(3) 您批准将该版本发布到用户环。环的名称和数量取决于您的偏好，但重要的是所有环都使用相同的生产环境。

功能标志最初由 Martin Fowler 推广。标志将版本部署和功能发布分离，将运行时控制权下放给单个用户，并支持假设驱动的开发。使用功能标志并将其与遥测数据联系起来，您可以决定功能是否有助于提高用户满意度、获取和保留率。您还可以使用功能标志进行紧急回滚、在不应提供功能的区域中隐藏功能或根据需要启用遥测。

典型的功能标志实现基于 (1) 定义标志的管理服务，(2) 运行时查询以确定标志的值，以及 (3) if-else 编程结构，如图所示

无论您是与开源 扩展 社区合作，还是 将 65,000 名工程师迁移到 DevOps，功能标志和基于环的部署模型策略都非常宝贵。

回到问题：您应该使用功能标志、环还是两者都使用？

我想到 Patrick L.O. Lumumba 的名言“你不会用锤子来回应蚊子叮咬”。

我们同时使用环和功能标志来逐步在生产环境中发布新版本，无论是针对我们商业产品的热修复还是功能发布，随着发布的爆炸或影响半径的增加，它会影响 65,000 名工程师，最终影响数十万用户。功能标志允许我们 逐步展示 每个版本的新功能、执行 A/B 测试并在生产环境中进行实验。由于我们正在使用云服务和扩展，我们与用户建立了持续的反馈循环，并且能够通过切换功能标志来微调每个版本。

对于我们的开源社区扩展，我们主要使用基于环的部署来逐步向金丝雀用户、早期采用者和用户发布新版本，如下表所述。我们正在逐步在选定的扩展中实施功能标志，以 实验 并积累微调功能和管理相关技术债务的经验。

准持续交付模式 是使用这两种策略的另一个示例，首先将新功能部署到第一个环中 1% 的用户，然后是 20%、50% 和 100%，并对第二个环继续使用相同的模式，依此类推。

您可以使用基于环的部署或功能标志来实施渐进式发布 DevOps 实践——它们是共生的。这一切都归结为您在推出版本和发布功能时希望有多谨慎。我建议您尝试两者。首先使用部署环逐步发布新版本，然后使用功能标志在生产环境中微调每个版本。

当使用基于环的部署模型来部署版本时，我会想到一个 ，当使用功能标志微调版本时，我会想到一个 。

环形部署和功能标志使用愉快！

在我们的开源 扩展 的上下文中比较环和标志

有关更多详细信息，请参阅 使用功能切换进行软件开发、通过环分阶段推出您的应用程序 和 我们的功能标志调查。