采用安全部署做法

在部署过程中设置防护措施，以减少错误或意外条件的影响。

设置自动化的模块化部署过程，以便每次都以相同的方式推出所有内容。 在早期应用安全做法（如测试、监视和版本控制）时，可以建立对生产的信心，并在出现问题时更轻松地恢复。

示例方案

Contoso Air 开发了一个 Web 应用程序，允许客户直接预订航班。 该应用已在生产环境中运行了一年多。

该应用完全部署在 Azure 中，基于 Azure 应用服务、Azure Cosmos DB、Azure Functions、Azure 逻辑应用和 Azure 服务总线构建。

通过代码部署基础结构

使用基础设施即代码（IaC）定义那些能够重复利用且适用于生产环境的供应链部分。 首选声明性方法而不是命令性方法。

声明性 IaC 工具旨在使自动化和重复使用变得简单。 它们使你能够将基础结构设置从个人转移到工具和管道，因此每次作都以相同的方式完成，并减少了错误。

更少的技术选项也会减少工具的差异，使查看配置偏移更容易，并简化维护。 如果选择与团队现有技能匹配的工具，则每个人都更容易上手。

Contoso 的挑战

• Contoso Air 的工作负载团队采用自动化构建和部署流水线，但在流程中通常仍需手动介入，以调整和检查不同的配置设置。

• 由于所有手动工作，部署错误经常发生。 每次发布都会给整个团队带来压力和破坏性影响的事件。 而且当部署失败时，回滚操作也并非易事。

应用方法和结果

• 团队留出时间，在部署过程中自动执行配置更改，并将新功能添加到现有部署管道中。

• 每个环境的配置设置现在都存储在单独的 JSON 文件中，这些文件保存在源代码管理中，因此易于跟踪。任何被视为机密的设置都存储在机密保管库中，为每个环境设置一个。

• 部署期间会记录每个更改，提供完整的可跟踪性，以帮助进行故障排除和审核。 团队还会向管道添加自动测试，以检查配置更改是否按预期工作。

• 接下来，该团队计划实现回滚操作的完全自动化，从而让流程更加顺畅。

• 由于新的自动化，部署更加可靠且可预测，团队士气也上升。

定期部署小型增量更新

将工作划分为可经常开发和部署的小型可管理更新。

较小的更新更易于测试和降低风险。 如果发生错误，则更容易查找和修复。 一次发布多个更改可能会导致更大的问题，并更难弄清楚出问题所在。

Contoso 的挑战

• 团队过去每三到四个月执行一次重大发布，这使得很难正确验证所有内容。 有了这么多移动部件，故障排除是一个真正的挑战。

• 曾有多次粗糙的发布 - 过程中需要紧急修复，或不得不完全回滚。

• 每次发布最终都演变成需要所有人参与解决的局面。 他们压力很大，耗尽了整个团队的精力，这确实对士气造成了很大的打击。

应用方法和结果

• 在最新的有问题发布后，利益干系人要求团队重新思考他们如何处理部署。 团队决定转变策略，进行较小且更频繁的变化。 现在，每个版本将只关注一个或几个密切相关的更新，这些更新在通过较低级别环境的过程中会经过彻底测试。

• 此更改使发布效率更高，质量也有所增加。 验证每个版本更容易，跟踪问题要简单得多。

• 一个稳定的可预测发布节奏确实有助于恢复团队的士气和信心。 用户也看到了这些优势，中断更少，对新功能的访问速度更快。

使用渐进式曝光方法

逐步推出更新，并小心谨慎。 使用部署模型，从几个实例或客户开始逐渐扩大，这样就可以确保更新能够顺利进行，然后全面投入。

以受控方式测试每个更新，以便尽早捕获和修复生产中的问题。 这种做法可帮助你避免推出可能影响所有客户的错误更新。

测试更新是否向后和向前兼容，以查看它是否适用于其他版本。

Contoso 的挑战

• 团队注意到转向较小版本带来很大好处。 他们花更少的时间管理部署，并感到有动力继续推动改进运行流程。

• 但是，当他们尝试新功能时，并不是一切都很顺利。 由于学习曲线陡峭，某些更改让用户感到困惑，导致更多的技术支持请求。

• 现在，他们正在考虑如何以真正提高用户工作效率的方式不断创新，而不会在新功能可能不受欢迎或易于使用时造成太大的中断。

应用方法和结果

• 团队决定使用功能标志逐步推出新功能，以便用户以增量方式访问新功能。

• 在规划期间，他们定义应首先看到该功能的人员。 通常，一小群用户会获得早期访问权限。 根据该组的响应方式，团队将推出扩展到更多用户，直到每个人都使用新版本。 随着越来越多的人开始使用这些功能，支持团队会跟踪支持案例中出现的内容，并在内部共享这些见解，也可能在外部常见问题解答中共享这些见解。