采用安全部署做法
 在部署过程中实施防护措施，以最大程度地减少错误或意外条件的影响。 |
|---|
在开发周期中，工作负载工件在实现和测试以及 bug 修复期间会经历许多更改。
部署过程必须遵循标准操作过程。 任何更改的部署都必须保持相同的严谨程度。 此原则同样适用于代码、配置和所有相关工件。 关键是尽早应用安全做法，以便在生产环境中具有可预测性。 即使错误到达了客户那边，你也应该能够尽快推出恢复更改。
示例场景
Contoso Air 开发了一个 Web 应用程序，它让客户能够直接通过该应用预订航班。 该应用已在生产环境中运行了一年多。
该应用完全部署在 Azure 中，基于 Azure 应用服务、Azure Cosmos DB、Azure Functions、Azure 逻辑应用和 Azure 服务总线。
编纂自动部署标准
使用自动部署过程（如管道）标准化部署任何更改的过程。 所有环境都必须使用管道。对每个环境的资产和版本进行分类，使它们易于跟踪且可识别。
一致的部署方法可减少由过程错误和差异引起的问题，并使你能够专注于工作负载问题。
标准化可确保部署安全、可靠且可重复地完成。
分类让你可以轻松查看以前部署的日志和已发生的问题。 你可以使用该信息来加快回滚和前滚操作。
Contoso 的挑战
- Contoso Air 工作负载团队使用自动生成和部署管道，但部署通常需要在整个操作中进行手动干预才能更改和验证各种配置设置。
- 由于需要手动干预，部署中经常出现错误，使得每次发布都为整个团队带来高度压力和干扰。 手动干预还使得部署在失败时难以回滚。
应用方法和成果
- 该团队分配了时间来在部署过程中自动执行配置更改，并将添加的功能集成到现有部署管道中。
- 与每个环境关联的配置设置被外部化到相应的 JSON 文件，这些文件被保存到源代码管理，以获得额外的可跟踪性。 被视为机密的设置也会保存到机密保管库存储，它们也被分配给每个环境。
- 部署期间的所有更改现在都会进行记录，实现完全的可跟踪性，以帮助开展排查工作和审核。 团队还添加了自动测试来验证管道的配置更改。
- 接下来，团队将致力于完全自动回滚，以进一步优化流程。
- 得益于新的自动化，部署变得更加可靠且可预测，团队士气也随之提高。
经常部署
定期部署小型增量更新。
从项目管理的角度来说，使用此方法可帮助使用户情景和工作项易于管理，并降低部署失败时出现大规模问题的风险。
Contoso 的挑战
- 一直以来，该团队的部署过程是每三到四个月进行一次重大发布。 这种做法使得验证发布变得困难。 由于活动部件众多，该团队在故障排除方面也遇到了困难。
- 需要版本中热修复或必须回滚和放弃的有问题的版本已多次出现。
- 发布是令人高度紧张的，并被当作是“全员投入”的事情，这一直对团队士气产生了负面影响。
应用方法和成果
- 在最近一次有问题的发布后，利益干系人要求团队想出更好的部署方法。 该团队决定改变他们的做法，采用频繁且小型的更改。 他们将每个版本的范围限定为一个或（最多）几个相关更改，当内部版本在较低环境中提升时，这些更改会经历全面的测试。
- 结果是，发布效率高了很多，质量也有所提升。 发布更易于验证了，问题也更易于排查了。
- 定期可预测的发布节奏有助于恢复团队的信心和士气。 用户也受益匪浅。 随着发布质量的提高，他们遇到的中断更少了，用上新功能的时间也提前了。
使用渐进式公开法
逐步推出更新，并尽职尽责。 你使用的部署模型需要让你能够逐步增加实例数和客户数，直到所有人安全地采用更新为止。
以可控的方式测试每个更新，以便在生产初期修复问题。 避免推出影响整个客户群的错误更新。
测试更新是否向后和向前兼容。
Contoso 的挑战
- 该团队看到，通过转换方法以生成较小的版本，实现了很大的好处。 现在，他们投入到发布的时间变少了，并感到精力充沛，可以继续在更多地改进卓越运营的道路上前进。
- 当他们试验新功能时，由于伴随这些功能的学习曲线较为陡峭，某些更改没有得到用户的好评，或者导致支持请求数增加。
- 他们想知道他们要如何继续创新应用程序，以最大限度地提高用户的工作效率，同时仍然尽量减少发布可能不太受欢迎或不易于使用的功能所带来的影响。
应用方法和成果
- 他们决定实施一个功能发布模型，它使用功能标志以增量方式向用户公开新功能。
- 在新功能的规划阶段，他们会定义一个条件，用于选择将首先向哪些用户公开该功能。 选择一小组用户先接收新功能。 取决于用户反馈，功能会连续部署到更大的组，直到整个用户群体都用上了新版本。 随着新功能向更多用户公开，支持团队会记录支持案例的结果，以便在内部共享，可能的话，也会将其用来填充外部 FAQ。