你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
设计工作负荷开发供应链的建议
适用于此 Azure 精心构建的框架卓越运营清单建议：
| OE：06 | 构建工作负载供应链，通过可预测的自动化管道推动建议的更改。 管道测试并跨环境提升这些更改。 优化供应链，使工作负荷可靠、安全、经济高效且性能高。 |
|---|
本指南介绍了设计基于持续集成和持续交付（CI/CD）管道的工作负载开发供应链的建议。 开发供应链，以确保你拥有可预测的标准化方法来维护工作负载。 CI/CD 管道是供应链的表现形式，但你应具有一个单一供应链。 你可能拥有多个管道，它们遵循相同的过程并使用相同的工具。
合并一个供应链来保护工作负荷，防止在未正确管理工作负荷更改时发生的损坏。 始终注意工作负荷的状态，因此你不会面临不可预测的行为的风险。 如果需要花关键时间在出现问题时对更改进行记账，则此风险会加剧。 为了最大程度地降低这些风险，请标准化定义供应链的流程和工具，并确保工作负荷团队完全承诺使用它们。
定义
| 术语 | 定义 |
|---|---|
| 供应链 | 在云工作负载中，供应链是一套标准化的工具和流程，可用于影响整个环境的基础结构和应用程序更改。 |
关键设计策略
注意
本指南中的建议是指代码升级链中的工作负荷环境。 沙盒或其他探索性和概念证明环境需要更严格的结构和结构。
以下建议可帮助你定义供应链的核心原则。
强制实施基于模板的自动部署的严格策略
通过供应链流程和工具进行建议的工作负荷更改。 强制实施基于模板的自动部署的严格策略。 此方法有助于确保工作负载在所有环境中的配置都标准化、定义明确且严格控制。 对于代码提升链中的环境，请勿使用手动过程或人工与云平台的控制平面交互（例如门户或 API）执行更新。 按照定义的部署做法，通过管道合并环境的所有更改。 为了帮助强制实施此策略，请考虑将只读访问权限限制为默认值，并使用访问授权门允许写入访问。
此原则的一个重要方面是，所有更改都建议更改，直到部署到生产环境。 通过自动化测试（如集成和冒烟测试），使供应链能够自动拒绝更改。
将可重复且不可变的基础结构部署为代码
将可重复且不可变的基础结构部署为代码（IaC）。 IaC 是在描述性模型中管理基础结构，该模型使用镜像源代码的版本控制系统。 创建应用程序时，相同的源代码在每次进行编译时都将生成相同的二进制文件。 通过类似的方式，每次应用 IaC 模型时都会生成相同的环境。
合并 IaC，以确保团队遵循标准、完善的流程。 某些组织指定单个个人或小组来部署和配置基础结构。 实现完全自动化的过程时，基础结构部署需要较少的个人管理。 责任将转移到自动化过程和工具。 团队成员可以启动基础结构部署，以保持一致性和质量。
将工作负荷设计为一组逻辑组件，你可以将其捆绑到一个模板中，使部署变得简单且可重复。 可以将这些捆绑包视为 邮票 或 规模单位。 有关详细信息，请参阅 部署标记模式。 当需要部署工作负荷以横向扩展到同一区域中的另一个区域或区域时，请使用管道部署标记。 根据设计图章的方式，可以部署工作负荷的子集，而不是整个工作负荷。 在 IaC 管道中包含网络组件，以确保部署标记自动连接到现有资源。
若要优化 IaC 管道以保持一致性和效率，请设计不可变基础结构，而不是可变基础结构。 实现不可变基础结构，以确保范围中的所有系统同时替换为更新的配置，并且与每个部署相同。
在所有环境中使用相同的部署项目集
在所有环境和管道中使用一组代码资产和项目。 组织的常见难题是非生产环境与生产环境不同。 手动生成生产和非生产环境可能会导致环境之间配置不匹配。 这种不匹配会降低测试速度，并使更改更有可能损害生产系统。 IaC 方法可最大程度地减少这些问题。 使用 IaC 自动化时，可以为所有环境使用相同的基础结构配置文件来生成几乎相同的环境。 可以将参数添加到基础结构配置文件，并对其进行调整以满足每个环境的要求。
若要控制成本，生产环境和非生产环境通常存在差异。 在非生产环境中，通常不需要与生产环境中相同的冗余和性能。 资源的数量和 SKU 在环境之间可能有所不同。 确保通过使用标准化参数来控制和了解方差，以帮助在进行更改时保持可预测性。
反映供应链中的组织结构
在供应链和管道设计中反映组织结构。 你的组织可能被团队所孤立。 每个团队都可以管理供应链的一部分。 例如，许多组织都有管理基础结构域的团队，例如网络、数据和计算资源。 这些团队独立于管理应用程序开发、测试和部署的开发团队。 在某些组织中，开发和基础结构团队合并到 DevOps 团队中，这些团队共同管理所有基础结构和应用程序部署。 可通过多种方式组织参与供应链的团队。 供应链依赖于所有团队无缝协作。 确保所有团队都遵循标准流程并使用标准工具使供应链尽可能高效。
如果外包工作负载生命周期的一部分，供应链可能会依赖于第三方供应商。 这些供应商对于供应链的成功与内部资源一样重要。 确保所有团队都就所使用的流程和工具达成了相互协议。
选择正确的部署方法
标准化部署方法。 与产品所有者讨论工作负荷可接受的生产停机时间。 根据可以接受的停机时间（如果有的话），可以选择适合你的要求的部署方法。 理想情况下，应在维护时段内执行部署，以减少复杂性和风险。 如果无法接受停机，请使用蓝绿部署方法。
使用渐进式曝光方法可降低向客户引入未检测到的 bug 的风险。 此方法也称为 Canary 部署，以逐步顺序部署到受控用户组。 它会在影响更多用户之前捕获问题。 初始推出组可能是客户了解推出策略的子部分。 客户这一小节可以容忍一些意外行为并提供反馈。 或者，它可能是一组内部用户，这有助于在推出期间包含 bug 的爆破半径。
定义部署方法时，请采用标准策略，只部署每个部署中最小的可行更改。 根据工作负荷的关键性和组件复杂性等因素，确定最小的可行更改。 如果使用不可变基础结构，最小可行更改通常是使用最新配置部署资源来替换运行以前版本的资源。 如果使用可变基础结构，则可以确定最小可行更改只是范围内资源组的单个更新。
遵循分层方法
遵循分层方法来反映不同的生命周期。 基础层应在大部分工作负荷生命周期内保持静态，应用程序层会频繁更改。 要考虑到这些差异，应该有不同的管道，以实现每个层的更改。
登陆区域位于最低层。 登陆区域是基础元素（如订阅、管理组、资源组、治理函数和网络拓扑）的逻辑分组。 通过登陆区域，可以轻松部署和管理工作负荷，并提供中心运营团队或平台团队，并采用可重复的环境配置方法。 为了提供一致的环境，所有 Azure 登陆区域都提供一组常见的设计区域、参考体系结构、参考实现以及修改部署以符合设计要求的过程。 Azure 登陆区域设计原则提供基于策略驱动治理以及订阅民主化的建议做法。 登陆区域应在工作负荷生命周期过程中进行最少的更改。 若要查看登陆区域的示例，请参阅 什么是 Azure 登陆区域。 此概念体系结构为 Azure 提供了一组建议的意见。
核心基础结构和功能（如入口和出口网络控制器、负载均衡、网络路由解决方案、DNS 管理和核心服务器）也应需要不经常的重大更改。 但它们可能需要频繁的配置更新。
应用程序和数据层需要频繁的配置更新和频繁的基础结构更改。 这些组件应具有最动态的管道。
合并全面的测试类型
规划整体测试策略。 系统可靠性的核心原则是 左 移原则。 开发和部署应用程序的过程描述为从左到右的一系列步骤。 不应将测试限制为进程末尾。 尽可能多地将测试转移到开头或向左移动。 当你提前抓住错误时，修复错误更便宜。 在应用程序生命周期的后期，它们可能很昂贵或无法修复。
测试所有代码，包括应用程序代码、基础结构模板和配置脚本。 运行应用程序的环境应通过与应用程序代码相同的机制进行版本控制并部署。 可以使用团队已用于应用程序代码的相同测试范例来测试和验证环境。
如果可能，请使用自动测试来确保一致性。 在供应链设计中包括以下类型的测试。
单元测试：单元测试通常作为持续集成例程的一部分运行。 单元测试应广泛且快速。 理想情况下，它们应涵盖 100% 的代码，并在 30 秒内运行。
实现单元测试，以验证代码的各个模块的语法和功能是否按其应的方式工作，例如为已知输入生成定义的输出。 还可以使用单元测试来验证 IaC 资产是否有效。
将所有代码资产（包括模板和脚本）应用单元测试。
冒烟测试：冒烟测试验证工作负荷是否可以在测试环境中站出来，并按预期执行。 冒烟测试不验证组件的互操作性。
冒烟测试验证基础结构和应用程序的部署方法是否正常工作，并且系统在完成该过程后是否按预期响应。
集成测试：集成测试确保应用程序组件单独运行，然后确定组件是否可以像应那样相互交互。
运行大型集成测试套件可能需要相当长的时间。 正因如此，最好在软件开发生命周期中尽早整合转移左原则并执行测试。 对于无法使用冒烟测试或单元测试进行测试的方案，保留集成测试。
如果需要，可以定期运行长时间的测试进程。 定期间隔提供良好的妥协，并检测应用程序组件之间的互操作性问题，不超过引入一天后。
某些测试方案受益于手动运行。 需要将人工交互元素引入测试时，请使用手动测试。
验收测试：根据上下文，可以手动执行验收测试。 它可以部分或完全自动化。 验收测试确定软件系统是否满足要求规范。
此测试的主要目的是评估系统的符合业务要求，并确定系统是否满足向最终用户交付所需的条件。
在代码提升过程中实现质量入口
通过测试在整个代码提升过程中实现质量入口。 将代码部署到较低环境（如开发和测试）中，并通过更高的环境（例如过渡和生产）进行部署。 部署通过质量入口时，请确保在更改进入生产之前满足质量目标。 业务要求决定了质量入口的重点。 另请考虑基本架构良好的框架原则：安全性、可靠性和性能效率。
此外，将审批工作流集成到质量入口中。 适当时，请明确定义和自动执行审批工作流。 在自动化中定义质量验收标准，以便可以高效地安全地穿过大门。
Azure 便利化
Azure DevOps 是一系列服务，可帮助你构建协作、高效且一致的开发实践。
Azure Pipelines 提供生成和发布服务，以支持应用程序中的 CI/CD。
适用于 Azure 的 GitHub Actions 与 Azure 集成，以简化部署。 使用 GitHub Actions 自动执行 CI/CD 进程。 可以创建工作流来生成和测试存储库的每个拉取请求，或将合并拉取请求部署到生产环境。
可以使用 Terraform、Bicep 和 Azure 资源管理器进行 IaC 部署。 根据你的要求和团队对这些工具的熟悉，你可以使用其中一个或多个工具来部署和管理资源。
示例
有关演示如何使用 Azure Pipelines 生成 CI/CD 管道的示例，请参阅 Azure Pipelines 基线体系结构。
相关链接
卓越运营清单
请参阅完整的建议集。