你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

设计工作负载开发供应链的建议

  • 项目

适用于此 Azure Well-Architected 框架卓越运营清单建议：

OE：06 构建工作负载供应链，通过可预测的自动化管道推动建议的更改。 管道跨环境测试和提升这些更改。 优化供应链，使工作负载可靠、安全、经济高效且性能高。

本指南介绍有关设计基于持续集成和持续交付 (CI/CD) 管道的工作负载开发供应链的建议。 开发供应链，以确保具有可预测的标准化方法来维护工作负载。 CI/CD 管道是供应链的表现形式，但你应该有一个供应链。 你可能有多个管道遵循相同的流程并使用相同的工具。

合并供应链，以保护工作负载免受未正确管理工作负载更改时可能发生的损害。 请始终注意工作负荷的状态，这样就不会有遇到不可预知行为的风险。 如果需要花费关键时间在出现问题时收回未记名的更改，这种风险会加重。 若要最大程度地降低这些风险，请标准化定义供应链的流程和工具，并确保工作负载团队完全承诺使用它们。

定义

术语 定义
供应链 在云工作负载中，供应链是一套标准化的工具和流程，用于影响环境之间的基础结构和应用程序更改。

关键设计策略

注意

本指南中的建议指的是代码升级链中的工作负载环境。 沙盒或其他探索性和概念证明环境需要的严格性和结构较少。

核心原则

以下建议可帮助你定义供应链的核心原则。

通过供应链流程和工具进行建议的工作负载更改。 强制实施基于模板的自动化部署的严格策略。 此方法有助于确保跨所有环境对工作负载的配置进行标准化、明确定义和严格控制。 对于代码提升链中的环境，请勿使用手动进程或与云平台的控制平面（例如门户或 API）进行人工交互来执行更新。 遵循定义的部署做法，通过管道合并对环境所做的所有更改。 为了帮助强制实施此策略，请考虑将访问权限限制为只读作为默认设置，并使用访问授权门允许写入访问。

此原则的一个重要方面是，在将所有更改部署到生产环境之前，所有更改都是建议的更改。 通过自动化测试（如集成和冒烟测试），使供应链能够自动拒绝更改。

将可重复且不可变的基础结构部署为代码 (IaC) 。 IaC 是描述性模型中基础结构的管理，该模型使用镜像源代码的版本控制系统。 创建应用程序时，每次编译应用程序时，相同的源代码都应生成相同的二进制文件。 通过类似的方式，每次应用 IaC 模型时都会生成相同的环境。

整合 IaC，确保团队遵循标准、完善的流程。 某些组织指定单个或小组人员来部署和配置基础结构。 实现完全自动化的过程时，基础结构部署需要较少的个人管理。 责任将转移到自动化过程和工具。 团队成员可以启动基础结构部署，以保持一致性和质量。

将工作负载设计为一组逻辑组件，你可以将其捆绑到一个模板中，使部署变得简单且可重复。 可以将这些捆绑视为 缩放单元 或 缩放单元。 有关详细信息，请参阅 部署缩放单元模式。 当需要部署工作负载以横向扩展到同一区域中的另一个区域时，请使用管道部署标记。 根据缩放单元的设计方式，可以部署工作负载的子集而不是整个工作负载。 在 IaC 管道中包含网络组件，以确保部署标记自动连接到现有资源。

若要优化 IaC 管道以确保一致性和效率，请设计不可变基础结构，而不是可变基础结构。 实现不可变基础结构，以确保将范围内的所有系统同时替换为更新的配置，并且与每个部署相同。

在所有环境和管道中使用一组代码资产和项目。 组织的一个常见难题是非生产环境与生产环境不同。 手动生成生产和非生产环境可能会导致环境之间的配置不匹配。 这种不匹配会减慢测试速度，使更改更有可能损害生产系统。 IaC 方法可将这些问题降到最低。 使用 IaC 自动化时，可以对所有环境使用相同的基础结构配置文件来生成几乎相同的环境。 可以将参数添加到基础结构配置文件，并对其进行调整以满足每个环境的要求。

为了控制成本，生产环境和非生产环境之间通常存在差异。 在非生产环境中，通常不需要与在生产环境中相同程度的冗余和性能。 资源的数量和 SKU 可能因环境而异。 确保使用标准化参数控制和理解方差，以帮助在进行更改时保持可预测性。

在供应链和管道设计中反映组织结构。 你的组织可能在团队中孤立。 每个团队都可以管理供应链的一部分。 例如，许多组织都有管理基础结构域（如网络、数据和计算资源）的团队。 这些团队独立于管理应用程序开发、测试和部署的开发团队。 在某些组织中，开发和基础结构团队合并到 DevOps 团队中，这些团队共同管理所有基础结构和应用程序部署。 有多种方法可以组织供应链中涉及的团队。 供应链依赖于所有团队无缝协作。 确保所有团队都遵循标准流程并使用标准工具，使供应链尽可能高效。

如果将工作负载生命周期的一部分外包，供应链可能依赖于第三方供应商。 这些供应商与内部资源一样，对供应链的成功至关重要。 确保所有团队都就所使用的流程和工具达成一致。

标准化部署方法。 请与产品所有者讨论工作负载可接受的生产停机时间。 根据可接受的停机时间（如果有），可以选择适合要求的部署方法。 理想情况下，应在维护时段内执行部署，以降低复杂性和风险。 如果不能接受停机，请使用蓝绿部署方法。

使用渐进式曝光方法来降低向广大客户引入未检测到的 bug 的风险。 也称为金丝雀部署，此方法按逐步顺序部署到受控用户组。 它会在问题影响更多用户之前捕获问题。 初始推出组可能是了解推出策略的客户子部分。 这部分客户可以容忍一定数量的意外行为并提供反馈。 或者，它可能是一组内部用户，这有助于在推出期间包含 bug 的爆发半径。

定义部署方法时，请采用标准策略，即在每个部署中仅部署最小可行更改。 根据工作负载的重要性和组件的复杂性等因素，确定最小的可行更改。 如果使用不可变基础结构，最小的可行更改通常是使用最新配置部署资源，以替换运行以前版本的资源。 如果使用可变基础结构，则可能认为最小的可行更改只是对范围内的资源组进行一次更新。

遵循分层方法来反映不同的生命周期。 基础层应在大部分工作负载生命周期中保持静态，并且应用程序层会频繁更改。 要考虑到这些差异，应使用不同的管道来影响每个层的更改。

登陆区域位于最低层。 登陆区域是基础元素（如订阅、管理组、资源组、治理函数和网络拓扑）的逻辑分组。 登陆区域使你能够轻松部署和管理工作负载，并为中央运营团队或平台团队提供可重复的环境配置方法。 为了提供一致的环境，所有 Azure 登陆区域都提供了一组通用设计领域、一个参考体系结构、一个参考实现，以及一个修改部署以满足设计要求的过程。 Azure 登陆区域设计原则提供基于策略驱动的治理以及订阅民主化的建议做法。 登陆区域应该在工作负载生命周期内需要最少的更改。 若要查看登陆区域的示例，请参阅 什么是 Azure 登陆区域。 此概念体系结构提供了一组建议用于 Azure 的意见。

核心基础结构和功能（如入口和出口网络控制器、负载均衡、网络路由解决方案、DNS 管理和核心服务器）还应不经常进行重大更改。 但它们可能需要频繁的配置更新。

应用程序和数据层需要频繁的配置更新和频繁的基础结构更改。 这些组件应具有最动态的管道。

规划整体测试策略。 系统可靠性的核心原则是 左移 原则。 开发和部署应用程序的过程描述为从左到右的一系列步骤。 不应将测试限制为过程结束。 尽可能将测试移到开头或左侧。 当你及早发现错误时，修复错误会更便宜。 它们可能很昂贵，或者无法在应用程序生命周期的后期修复。

测试所有代码，包括应用程序代码、基础结构模板和配置脚本。 运行应用程序的环境应通过与应用程序代码相同的机制进行版本控制和部署。 可以使用团队已用于应用程序代码的相同测试范例来测试和验证环境。

如果可能，请使用自动测试来确保一致性。 在供应链设计中包括以下类型的测试。

  • 单元测试：单元测试通常作为持续集成例程的一部分运行。 单元测试应广泛且快速。 理想情况下，它们应覆盖 100% 的代码，并在 30 秒内运行。

    实现单元测试，以验证各个代码模块的语法和功能是否按应有的方式工作，例如为已知输入生成定义的输出。 还可以使用单元测试来验证 IaC 资产是否有效。

    将单元测试应用于所有代码资产，包括模板和脚本。

  • 冒烟测试：冒烟测试验证工作负载是否可以在测试环境中正常运行，并按预期执行。 冒烟测试不会验证组件的互操作性。

    冒烟测试验证基础结构和应用程序的部署方法是否正常工作，以及系统在该过程完成后是否按预期进行响应。

  • 集成测试：集成测试确保应用程序组件单独运行，然后确定组件是否可以按应有的方式相互交互。

    运行大型集成测试套件可能需要相当长的时间。 这就是为什么最好采用左移原则，并在软件开发生命周期的早期执行测试。 为无法使用冒烟测试或单元测试进行测试的方案保留集成测试。

    如果需要，可以定期运行长时间运行的测试进程。 定期间隔提供良好的妥协，并在引入应用程序组件后的一天内检测应用程序组件之间的互操作性问题。

    某些测试方案受益于手动运行。 需要将人类交互元素引入测试时，请使用手动测试。

  • 验收测试：可以根据上下文手动执行验收测试。 它可以是部分自动化的，也可以是完全自动化的。 验收测试确定软件系统是否符合要求规范。

    此测试main目的是评估系统是否符合业务要求，并确定系统是否满足交付给最终用户所需的标准。

通过测试在整个代码提升过程中实现质量入口。 将代码部署到较低环境（如开发和测试），并通过高级环境（如过渡和生产）进行部署。 当部署通过质量关口时，请确保在更改进入生产之前满足质量目标。 业务要求决定了质量入口的重点。 另请考虑基本 Well-Architected 框架原则：安全性、可靠性和性能效率。

此外，将审批工作流集成到质量入口中。 在适当的时候明确定义并自动执行审批工作流。 在自动化中定义质量验收标准，以便可以高效安全地通过入口。

Azure 便利化

Azure DevOps 是一系列服务，可帮助你构建协作、高效且一致的开发实践。

Azure Pipelines 提供生成和发布服务来支持应用程序中的 CI/CD。

GitHub Actions for Azure 与 Azure 集成以简化部署。 使用 GitHub Actions 自动执行 CI/CD 过程。 可以创建工作流来生成和测试存储库的每个拉取请求，或将合并的拉取请求部署到生产环境。

可以使用 Terraform、Bicep 和 Azure 资源管理器进行 IaC 部署。 根据你的要求和团队对工具的熟悉程度，你可以使用其中一个或多个工具来部署和管理资源。

示例

有关演示如何使用 Azure Pipelines 生成 CI/CD 管道的示例，请参阅 Azure Pipelines 基线体系结构。

卓越运营清单

请参阅完整的一组建议。

卓越运营清单