有时发布不符合预期。 尽管使用最佳做法并传递所有质量入口，但偶尔会出现导致生产部署导致用户无法预见的问题。 为了最大程度地减少和缓解这些问题的影响，鼓励 DevOps 团队采用 渐进式曝光 策略，以平衡给定版本的曝光率及其经过验证的性能。 随着发布在生产环境中证明自己，它可供更广泛的受众层使用，直到每个人都使用它。 Teams 可以使用安全部署做法，以最大限度地提高生产中发布的质量和速度。
控制客户曝光
DevOps 团队可以使用各种做法来控制向客户公开更新。 从历史上看，A/B 测试是团队的热门选择，希望了解不同版本的服务或用户界面如何针对目标目标执行。 A/B 测试也相对易于使用，因为更改通常是次要的，通常仅比较面向客户的服务边缘的不同版本。
通过层安全部署
随着平台的增长，基础结构规模和受众需求也随之增长。 这为部署模型创造了需求，该模型将与新部署相关的风险与它承诺的更新的优势进行平衡。 一般的想法是，给定版本应首先向一小群具有最高风险容忍度的用户公开。 然后，如果发布按预期工作，则可以将其公开给更广泛的用户组。 如果没有问题，则该过程可以继续通过更广泛的用户组或 层，直到每个人都使用新版本。 借助 GitHub Actions 和 Azure Pipelines 等新式持续交付平台，使用层构建部署过程可供任何规模的 DevOps 团队访问。
功能标志
某些功能有时需要部署为发布一部分，但最初不会向用户公开。 在这些情况下， 功能标志 提供一种解决方案，可通过基于环境、层或任何其他特定部署的配置更改启用功能。
用户选择加入
与功能标志类似，用户选择加入提供了限制曝光的方法。 在此模型中，给定功能在发布中处于启用状态，但不会为用户激活，除非他们特别想要该功能。 风险容忍度决策将卸载给用户，以便他们可以决定想要采用某些更新的速度。
通常同时采用多种做法。 例如，团队可能具有适用于非常具体的用例的实验性功能。 由于存在风险，因此他们将将其部署到第一层，供内部用户试用。但是，即使这些功能在代码中，用户也需要为层中的特定部署设置功能标志，以便通过用户界面公开该功能。 即便如此，功能标志可能只公开用户选择使用新功能的选项。 任何不在层、部署中或未选择加入的人员都不会向该功能公开。 虽然这是一个相当精心尝试的示例，但它有助于说明渐进式曝光的灵活性和现实性。
团队在早期面临的常见问题
随着团队走向更敏捷的 DevOps 实践，他们可能会遇到与从传统整体交付迁移的其他人一致的问题。 团队过去每隔几个月部署一次，有一种缓冲稳定思维模式。 他们预计每个部署都会在其服务中带来实质性的转变，并且会出现不可预见的问题。
有效负载太大
每隔几个月部署的服务通常会填充许多更改。 这增加了将立即出现问题的可能性，也使得很难排查这些问题，因为有很多新的东西。 通过迁移到更频繁的交付，所部署内容的差异会变小，这样就可以进行更集中的测试，更轻松地进行调试。
无服务隔离
整体式系统传统上通过对部署的硬件进行调配来缩放。 但是，当实例出现问题时，它会导致每个人出现问题。 一个简单的解决方案是添加多个实例，以便你可以对用户进行负载均衡。 但是，这可能需要重要的体系结构注意事项，因为许多旧系统不会构建为多实例。 此外，可能需要为其他位置更好地合并的功能分配大量重复资源。
随着新功能的添加，探索 微服务体系结构 是否有助于作和缩放，这要归功于更好的服务隔离。
手动步骤会导致错误
当团队每年只部署几次时，自动化交付似乎并不值得投资。 因此，手动管理许多部署过程。 这需要大量的时间和精力，并且容易发生人为错误。 只需自动执行最常见的生成和部署任务，就可以在减少丢失时间和非强制错误方面走得很远。
Teams 还可以利用 基础结构即代码 更好地控制部署环境。 这消除了对运营团队进行手动更改的请求的需求，因为新功能或依赖项引入到各种部署环境。
只有 Ops 可以执行部署
某些组织具有要求由运营人员启动和管理所有部署的策略。 尽管过去可能有充分的理由，但当开发团队可以启动和控制部署时，敏捷 DevOps 过程将大大受益。 新式 持续交付 平台可精细控制谁可以启动哪些部署，以及谁可以访问状态日志和其他诊断信息，确保合适的人员尽快获得正确的信息。
错误的部署继续进行，无法回滚
有时部署出错，团队需要解决它的问题。 但是，当流程是手动的，对信息的访问速度缓慢且有限时，可能很难回滚到以前的工作部署。 幸运的是，有各种工具和 做法 可以缓解部署失败的风险。
核心原则
希望采用安全部署做法的团队应制定一些核心原则来支撑工作。
保持一致
开发和测试环境中应使用用于在生产中部署的相同工具。 如果存在问题（例如通常来自新版本的依赖项或工具），则应在代码即将发布到生产环境之前捕获它们。
关心质量信号
太多的团队陷入了不真正关心质量信号的常见陷阱。 随着时间的推移，他们可能会发现他们编写测试或执行质量任务只是将黄色警告更改为绿色审批。 质量信号非常重要，因为它们代表了项目的脉搏。 每天应不断跟踪用于批准部署的质量信号。
部署需要零停机时间
虽然每个服务始终可用并不重要，但团队应以他们能够和应该部署新版本的心态来处理其 DevOps 交付和作阶段，而无需随时将其关闭。 现代基础结构和管道工具现已足够高级，几乎任何团队都可以针对 100% 运行时间。
部署应在工作时间发生
如果团队采用部署需要零停机时间的思维模式，那么在推送部署时并不重要。 此外，在工作时间推送部署更有利，尤其是在当天和周初。 如果出现问题，应尽早跟踪它以控制爆炸半径。 此外，每个人都会努力工作，并专注于解决问题。
基于层的部署
具有成熟 DevOps 发布实践的团队可以采用基于层的部署。 在此模型中，新功能首先向愿意接受风险最高的客户推出。 随着部署得到证实，受众将扩展到包括更多用户，直到每个人都使用它。
示例层模型
典型的层部署模型旨在通过仔细细分用户和基础结构来尽早发现问题。 以下示例演示了主团队在Microsoft如何使用层。
| 层 | 目的 | 用户 | 数据中心 |
|---|---|---|---|
| 0 | 查找部署引入的大部分影响用户的错误 | 仅限内部，对风险和 bug 的高容忍度 | 美国中西部 |
| 1 | 团队未广泛测试的区域 | 使用产品广度的客户 | 小型数据中心 |
| 2 | 与缩放相关的问题 | 公共帐户，理想情况下，使用一组不同的功能免费帐户 | 中型或大型数据中心 |
| 3 | 在内部帐户和国际相关问题中缩放问题 | 大型内部帐户和欧洲客户 | 内部数据中心和欧洲数据中心 |
| 4 | 剩余缩放单位 | 别人 | 所有部署目标 |
允许烘焙时间
术语 烘焙时间 是指允许部署在扩展到下一层之前运行的时间量。 某些问题可能需要数小时或更长时间才能开始出现症状，因此发布应在考虑就绪之前使用适当的时间。
一般情况下，24 小时的时间应该足以让大多数方案公开潜在 bug。 但是，对于在工作时间达到高峰的服务，此时段应包括高峰期（需要一个完整的工作日）。
加快修补程序
当 bug 对生产产生严重影响时，将发生 实时站点事件 （LSI）。 LSIs 需要创建 修补程序，这是一个带外更新，旨在解决高优先级问题。
如果 bug 为 Sev 0（最严重的 bug 类型），则修补程序可能尽快直接部署到受影响的缩放单元。 虽然修复不使事情变得更糟至关重要，但此严重性的 bug 被视为破坏性，因此必须立即解决它们。
分级 为 Sev 1 的 Bug 必须通过第 0 层进行部署，但随后可以在批准后立即部署到受影响的缩放单元。
必须按计划通过所有层部署具有较低严重性的 bug 修补程序。
关键结论
每个团队都希望快速、最高质量的更新。 使用正确的做法，交付可能是 DevOps 周期的高效而无痛的一部分。
- 经常部署。
- 在整个冲刺中保持绿色。
- 在开发、测试和生产中使用一致的部署工具。
- 使用允许自动化和授权的持续交付平台。
- 遵循安全部署做法。
后续步骤
了解 功能标志 如何帮助控制向用户公开新功能。