你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于此 Azure 精心构建的框架卓越运营清单建议：
| OE：06 | 建立并优化您的工作流程供应链，使用可预测的自动化管道测试并在不同环境中推广更改。 设计这些管道，以一致地满足可靠性、安全性、成本效益和性能目标。 |
|---|
为了提供一种可预测的标准化方法来维护工作负荷，请在持续集成和持续交付（CI/CD）周围设计工作负载开发供应链。 维护单个标准化供应链，并使用自动化 CI/CD 管道实现它;只要这些管道都遵循相同的供应链，就可以使用多个管道。
使用标准化的供应链来保护工作负荷免受未受控的更改的风险。 在问题出现时，保持对工作负荷状态的持续可见性，以避免无法预知的行为和成本高昂的重新追查未跟踪更改。 为了最大程度地降低这些风险，请标准化定义供应链的流程和工具，并确保工作负荷团队完全承诺使用它们。
定义
| 术语 | 定义 |
|---|---|
| 供应链 | 在云工作负载中，供应链是一套标准化的工具和流程，可用于影响整个环境的基础结构和应用程序更改。 |
注意
本指南中的建议是指代码升级链中的工作负荷环境。 沙盒或其他探索性和概念验证环境对严格性和结构的要求较低。
以下建议可帮助你定义供应链的核心原则。
强制实施基于模板的自动部署的严格策略
通过供应链的流程和工具进行所有建议的工作负荷更改，并强制实施基于模板的自动化部署。 此方法使配置在环境中保持标准化、定义明确且严格控制。 对于代码升级链中的环境，禁止手动更新或与云控制平面（例如门户或 API）直接交互。 通过遵循您定义的部署实践的管道实施对环境的所有更改。 若要强制实施此策略，请限制对只读的访问，并使用授权入口在需要时授予写入访问权限。
此原则的一个重要方面是，所有更改都建议更改，直到部署到生产环境。 通过自动化测试（如集成和冒烟测试），使供应链能够自动拒绝更改。
AI 机会：手动诊断部署失败会使团队变慢，导致挫折，并创建知识孤岛。 通过首先评估提供 AI 辅助故障分析的现成 DevOps 工具来提高工作效率和复原能力。 若要扩展这些功能，请在现有工具链上分层自定义代理，以识别和解决常见问题。 对于高级方案，请考虑一种代理解决方案，用于监视管道遥测和历史事件数据，以检测定期故障模式并建议主动修正。
将可重复且不可变的基础结构部署为代码
使用基础结构即代码（IaC）部署可重复的不可变基础结构。 将基础结构作为镜像应用程序源的声明性版本控制定义进行管理。 每次应用相同的 IaC 都会创建相同的环境，就像编译时相同的源代码生成相同的二进制文件一样。
若要标准化和自动化部署和配置基础结构的方式，请采用基础结构即代码（IaC）。 将依赖人员的部署替换为完全自动化的管道，将责任从个人转移到工具和减少手动工作量。 使授权团队成员能够通过此自动化过程启动部署，以在整个环境中保持一致性和质量。
将工作负荷设计为一组逻辑组件，你可以将其捆绑到一个模板中，使部署变得简单且可重复。 可以将这些捆绑包视为 邮票 或 尺度单位。 有关详细信息，请参阅 部署标记模式。 当需要部署工作负荷以横向扩展到同一区域中的另一个区域或区域时，请使用管道部署标记。 根据你设计图章的方式，可以只部署工作负荷的子集，而不是整个工作负荷。 若要确保部署戳记自动连接到现有资源，请在 IaC 管道中包含网络组件。
若要优化 IaC 管道以保持一致性和效率，请设计不可变基础结构，而不是可变基础结构。 实施不可变基础架构，以确保在每次部署时，范围内的所有系统都同时且一致地替换为更新的配置。
在整个环境中保持准确、持续监视的资源清册，并包括审批步骤和审计追踪来跟踪所有AI操作。
在所有环境中使用相同的部署工件集
在所有环境和管道中使用同一组代码资产和制品。 组织的常见难题是非生产环境与生产环境存在差异。 手动生成生产和非生产环境可能会导致环境之间配置不匹配。 这种不匹配会降低测试速度，并使更改更有可能损害生产系统。 IaC 方法可最大程度地减少这些问题。 使用 IaC 自动化时，可以为所有环境使用相同的基础结构配置文件来生成几乎相同的环境。 可以将参数添加到基础结构配置文件，并对其进行调整以满足每个环境的要求。
若要控制成本，生产环境和非生产环境通常存在差异。 通常，非生产环境中不需要相同级别的冗余或性能，因此资源计数和 SKU 可能有所不同。 确保通过使用标准化参数来控制和了解方差，以帮助在进行更改时保持可预测性。
反映供应链中的组织结构
在供应链和管道设计中反映组织结构。 你的组织可能被团队所孤立。 可以按功能（例如网络、数据和计算）组织团队，或将它们作为管理基础结构和应用程序的 DevOps 团队进行集成。 可通过多种方式组织参与供应链的团队。 无论结构如何，供应链都依赖于跨所有团队的无缝协作。 确保所有团队都遵循标准流程并使用标准工具使供应链尽可能高效。
如果外包工作负载生命周期的一部分，供应链可能会依赖于第三方供应商。 这些供应商与内部资源一样，对供应链的成功至关重要。 确保所有团队都就所使用的流程和工具达成了相互协议。
选择正确的部署方法
标准化部署方法。 与产品所有者讨论工作负荷可接受的生产停机时间。 根据可接受的停机时间，可以选择符合要求的部署方法。 理想情况下，请在维护时段执行部署，以减少复杂性和风险。 如果无法接受停机，请使用蓝绿部署方法。
使用逐步曝光（Canary 部署）方法来降低向客户引入未检测到的错误的风险。 分阶段将更改部署到小型受控组，以便在广泛发布之前捕获问题。 初始发布组可能是已经了解发布策略的客户子群。 这部分客户可以容忍一些意外情况并提供反馈。 或者，它可能是一组内部用户，这有助于在部署期间控制 bug 的影响范围。
定义部署方法时，请采用标准策略来发布每个部署中最小的可行更改。 根据工作负荷的关键性和组件的复杂性，确定哪些内容限定为最小的可行更改。 如果使用不可变基础结构，最小的可行更改是使用最新配置重新部署资源，以替换运行以前版本的这些资源。 如果使用可变基础结构，则可以确定最小可行更改只是对资源组的单个范围更新。
遵循分层方法
遵循分层方法来反映不同的生命周期。 使基础层在大部分工作负荷的生命周期中保持静态，而应用程序层则更频繁地更改。 对每个层使用单独的部署管道，以便可以独立和适当地应用更改。
登陆区域位于体系结构的最低层。 它是基础元素（例如订阅、管理组、资源组、治理控件和网络拓扑）的逻辑分组，使你能够一致地部署和作工作负荷。 它为中心运营或平台团队提供可重复的环境配置。 为了确保一致性，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 基线体系结构。
相关链接
卓越运营清单
请参阅完整的建议集。