放心部署
 通过可预测性达到所需的部署状态。 |
|---|
构建工作负载供应链，以支持你跨工作负载托管平台、应用程序、数据和配置资源在所有环境中一致地实现可预测性目标。 部署机制必须能够进行自动化、测试、监视和版本控制。 它应采用模块化设计，并且可以随时按需执行。 它不应表示为整体式端到端过程。 供应链并不一定是为了更快速的执行，而是为了在多次迭代中实现一致性和自我记录。
工作负载团队对供应链负责，因为它与团队自己的工作负载相关。
示例方案
Contoso Manufacturing 开发了一个基于 Java 的应用程序，用于监视和优化其制造过程。 工作负载最近已迁移到 Azure，目前正在 Azure Spring Apps、Azure Database for MySQL 和 Azure IoT 中心上运行。
通过代码部署基础结构
使用基础结构即代码 (IaC) 定义已实现生产就绪的供应链的可重复方面。 首选声明性方法而不是命令性方法。
声明式 IaC 技术的设计考虑了自动化和可重用性。 可以将基础结构部署从个人卸载到工具中，并实现一致的质量。
从基础结构的角度来看，更少的技术选择可消除工具差异，并且更容易检测到配置偏移。 还会简化维护工作。 如果所做出的选择与团队的现有技能集保持一致，则团队可以轻松采用它们。
Contoso 的挑战
- 工作负载的本地版本组合使用脚本和手动步骤来生成基础结构，并跨环境部署应用程序。 在 Azure 迁移过程的早期阶段，团队对现有命令性脚本进行了修改，以面向新平台，从而可以在最大程度上重用现有的自动化代码库。 由于缺乏 Azure 和 IaC 技术（如 Bicep）的专业知识，也采取了这种方法。
- 随着迁移取得进展，团队对平台更加熟悉，他们已确信从长远来看，将 IaC 方法与 Bicep 配合使用将是一个更好的解决方案。
应用方法和结果
- 由于缺乏内部知识，团队将迁移和扩展工作负载部署自动化脚本的工作承包给有经验的承包商，他们在项目的初始阶段与开发团队一起工作，同时向团队的其他成员提供知识转移。
- 所生成的基于 Bicep 的实现提供了一种方法，可以在 Azure 中更可靠、可管理且更高效地预配基础结构。 现在，代码更易于阅读和维护，并在 VSCode 中获得了出色的工具支持。 它还是完全幂等的，并且简化了状态管理，这是他们在以前的/命令式版本中无法完全实现的。
将 IaC 与应用程序代码同等对待
遵循面向 IaC 开发和维护的软件建议：实现适度的模块化，避免自定义或低值抽象，并遵循分层方法反映不同的生命周期。 构建基础层，其中下层保持不变，上层则根据需要进行更改。
部署项目（如应用程序二进制文件、IaC 模板和参数）是攻击面的一部分。 应用保证，例如机密管理、访问控制和其他安全支柱原则。
项目在工程严格程度上的要求与应用程序代码相同。 通过同行评审和测试进行质量控制可以让你对部署充满信心。
分层方法可简化维护工作，并建立了明确责任线的边界。
向项目添加安全控制有助于在部署过程中强化系统。
Contoso 的挑战
- 项目团队在迁移工作开始时提供了慷慨的预算，因此他们雇佣了经验丰富的承包商，这些承包商在短时间内交付了高质量的工作。 承包商使用单独的存储库进行开发，并且该存储库尚未定期进行安全审核，而主要应用程序代码存储库则进行了安全审核。
- 团队正在准备发布解决方案的重大重新设计，并且部署代码需要进行重大更改。 由于开发资源短缺，两名实习生正在进行最新一批更改。 当团队中的一位高级开发人员被调动来帮助实习生时，他注意到存储库中的多个提交不符合团队的开发标准，其中包括在代码库中硬编码 API 密钥等应用程序机密。
应用方法和结果
- 团队决定将生成和部署代码库移动到用于应用程序代码的同一存储库，并开始应用与代码库其他领域相同的工程严格级别。 在首次提交前，代码将被引入到团队标准中，移除应用程序机密，然后对其应用所有其他团队质量标准和工具。
- 因此，团队在提高代码质量的同时保护了代码库的这一部分。 今后，对代码库中此领域的更改将遵循相同的标准，并利用与核心应用程序代码库相同的工具，包括同行代码评审和使用质量与安全工具自动扫描代码。
标准化单个清单上的部署
制订在所有环境中使用的常见部署清单。 使用该清单作为绿地项目、增量工作负载更新或灾难恢复的默认机制。
应用此方法将会支持你消除维护多个资产的开销。
如果发生灾难，恢复将会快速可靠，因为你可以部署经过尝试和测试的清单，而不是创建临时环境。
Contoso 的挑战
- Contoso Manufacturing 使用完全自动化的管道将基础结构、应用程序代码和配置更改部署到开发和生产环境。 应用程序将配置为在单个区域中高度可用。 除 MySQL 数据库外，大多数应用程序组件都是无状态的。 数据库将会根据已确定的 RTO/RPO 的要求进行备份，并将备份复制到次要区域。
- 如果主要区域发生重大或灾难性故障，团队计划生成一个新环境，以在次要区域中托管应用程序。 在测试 DR 过程的计划演练期间，由于多个资源缺乏可用性和其他服务限制，因此如果尝试在次要区域中重新创建环境，部署脚本将会失败。
应用方法和结果
- 通过将一些资源的使用替换为在两个区域都可用的等效 SKU，并将一些选项设为可配置，以便可以在次要区域使用不同但有效的值，团队缓解了尝试在次要地区进行预配时遇到的问题。
- 通过该练习，团队增强了对于自身从重大基础结构故障中恢复的能力的信心。