有关设计工作负荷开发供应链的建议
适用于此 Power Platform Well-Architected 卓越运营清单建议：
| OE：06 | 生成工作负荷供应链，通过可预测的自动化管道推动建议的更改。 管道跨环境测试和提升这些更改。 优化供应链，使您的工作负载可靠、安全、经济高效且高性能。 |
|---|
本指南介绍有关设计基于持续集成和持续交付 (CI/CD) 管道的工作负荷开发供应链的建议。 在云工作负荷中，供应链是一套标准化的工具和流程，用于影响环境之间的配置和工作负荷更改。 开发供应链，以确保您具有可预测的标准化方法来维护工作负荷。 CI/CD 管道是供应链的表现形式，但您应该有一个供应链。 您可能有多个管道跟随相同的流程并使用相同的工具。
合并供应链，以保护工作负荷免受未正确管理工作负荷更改时可能发生的损害。 始终了解工作负载的状态，以免遇到不可预知的行为。 如果您需要在出现问题时花费关键时间来追踪无法解释的更改，则这种风险会加剧。 若要最大程度地降低这些风险，请标准化定义供应链的流程和工具，并确保工作负荷团队完全承诺使用它们。
关键设计策略
以下建议可帮助您定义供应链的核心原则。
通过供应链流程和工具进行建议的工作负荷更改。 强制实施基于模板的自动化部署的严格策略。 此方法有助于确保跨所有环境对工作负荷的配置进行标准化、明确定义和严格控制。 对于代码提升链中的环境，请勿使用手动流程或人工交互来执行更新。 遵循定义的部署做法，通过管道合并对环境所做的所有更改。 为了帮助强制实施此策略，请考虑限制访问权限为只读作为默认设置，并使用访问授权门允许写入访问。
此原则的一个重要方面是，在将所有更改部署到生产之前，所有更改都是建议的更改。 通过自动化测试（例如集成和冒烟测试），使供应链能够自动拒绝更改。
在所有环境和管道中使用一组代码资产和项目。 组织的一个常见难点是非生产环境与生产环境不同。 手动生成生产和非生产环境可能会导致环境之间的配置不匹配。 这种不匹配会减慢测试速度，使更改更有可能损害生产系统。
在供应链和管道设计中反映组织结构。 您的组织可能在团队中孤立。 每个团队都可以管理供应链的一部分。 例如，许多组织都有管理安全性和合规性设置或环境配置的团队。 这些团队独立于管理应用程序开发、测试和部署的开发团队。 有多种方法可用于组织供应链中涉及的团队。 供应链依赖于所有团队无缝协作。 确保所有团队都遵循标准流程并使用标准工具，以使供应链尽可能高效。
如果您将工作负载生命周期的部分外包出去，您的供应链可能会依赖第三方供应商。 这些供应商与内部资源一样，对供应链的成功至关重要。 确保所有团队都就您使用的流程和工具达成一致。
标准化部署方法。 请与产品所有者讨论工作负荷可接受的生产停机时间。 根据可接受的停机时间（如果有），您可以选择适合要求的部署方法。 理想情况下，应在维护时段内执行部署，以降低复杂性和风险。
计划整体测试策略。 系统可靠性的核心原则是“左移”原则。 开发和部署应用程序的流程描述为从左到右的一系列步骤。 不应将测试限制为流程结束。 尽可能将测试移到开头或左侧。 当您及早发现错误时，修复错误会更便宜。 它们可能成本高昂，或者无法在应用程序生命周期的后期修复。
如果可能，请使用自动测试来确保一致性。 在供应链设计中包括以下类型的测试：
单元测试：单元测试通常作为持续集成例程的一部分运行。 单元测试应广泛且快速。 理想情况下，它们应覆盖 100% 的代码。 将单元测试应用于所有代码资产，包括模板和脚本。
冒烟测试：冒烟测试验证工作负载是否可以在测试环境中正常运行并按预期执行。 冒烟测试不会验证组件的互操作性。 冒烟测试验证基础结构和应用程序的部署方法是否正常工作，以及系统在该流程完成后是否按预期进行响应。
集成测试：集成测试确保应用程序组件单独运行，然后确定组件是否可以按预期相互交互。 运行大型集成测试套件可能需要相当长的时间。 这就是为什么最好在软件开发生命周期的早期结合左移原则并执行测试的原因。 为无法使用冒烟测试或单元测试进行测试的应用场景保留集成测试。 如果需要，可以定期运行长时间运行的测试流程。 定期间隔提供良好的妥协，并在引入应用程序组件后的一天内检测应用程序组件之间的互操作性问题。 某些测试应用场景受益于手动运行。 需要将人类交互元素引入测试时，请使用手动测试。
验收测试：根据上下文，您可以手动执行验收测试。 它可以部分自动化，也可以完全自动化。 验收测试确定软件系统是否符合要求规范。 此测试的主要目的是评估系统是否符合业务要求，并确定系统是否满足交付给用户所需的标准。
通过测试在整个代码提升过程中实施质量关卡。 将代码部署到较低环境（例如质量保证和测试）中，并通过较高环境（例如过渡和生产）进行部署。 当部署通过质量关口时，请确保在更改进入生产之前满足质量目标。 业务要求决定了质量关口的重点。 还要考虑基本的 Power Platform Well-Architected 原则：安全性、可靠性和性能效率。
此外，将审批工作流集成到质量关口中。 在适当的时候明确定义并自动执行审批工作流。 在您的自动化系统中定义质量验收标准，以便您可以高效、安全地通过登机口。
Power Platform 便利化
管道旨在通过 Power Platform 将 ALM 自动化以及持续集成和持续交付（CI/CD）功能引入服务，为 Power Platform Dynamics 365 客户实现应用程序生命周期管理（ALM）的大众化。
Microsoft Power Platform Build Tools for Azure DevOps 可用于自动执行与所构建 Power Platform应用程序相关的常见构建和部署任务。
GitHub Actions 使 Power Platform 开发人员能够构建自动化的软件开发生命周期工作流。 借助适用于 Microsoft Power Platform 的 GitHub Actions，您可以在存储库中创建工作流来构建、测试、打包、发布和部署应用；执行自动化；以及管理基于 Power Platform 构建的机器人和其他组件。
ALM Accelerator 是一个开源工具，由一组应用程序、脚本和管道组成，旨在自动化持续集成/持续交付过程。
使用 Azure Pipelines 自动执行测试。
Power Apps 检查器 Web API 提供了一种机制，用于针对平台的 Microsoft Dataverse 自定义项和扩展运行静态分析检查。
Microsoft Power Platform CLI（ PAC CLI）是一个命令行工具，支持解决方案的 Power Platform 导入和导出，以及打包到解决方案源文件和从 Power Platform 解决方案源文件解包。 PAC CLI 可作为 独立的命令行工具 使用，也可作为 Code Visual Studio 的扩展使用。
可以使用 Terraform、Bicep 和 Azure 资源管理器进行不可变基础结构即代码 (IaC) 部署。 根据您的要求和团队对工具的熟悉程度，您可以使用其中一个或多个工具来部署和管理资源。
组织一致性
云采用框架为中央团队提供工作负荷登陆区域的指南。 工作负载登录区域是工作负载的自定义供应链将应用程序部署到的位置。
有关详细信息，请参阅 什么是 Azure 登陆区域？ 和 Azure 登陆区域设计原则。