精通微软-PowerPlatform-上的-DevOps-全-

精通微软 PowerPlatform 上的 DevOps（全）

原文：annas-archive.org/md5/500a107f5b6fc7d7506eff9576d6eaca

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

Microsoft Power Platform 是全球领先的低代码、无代码平台——一个现代化的应用运行时，能够实现无限数量的业务解决方案。 随着这些场景变得越来越复杂且业务关键，专业的 DevOps 流程需求也愈加迫切。 本书聚焦于定制软件开发项目中的著名实践，并将这些常见活动映射到 Microsoft Power Platform 工具集。 我们探讨软件开发生命周期的每个阶段，以及此软件即服务（SaaS）产品所提供的工具和功能，详细讨论诸如打包、构建、部署、测试和发布解决方案等常见的 DevOps 活动。 此外，我们深入探讨 DevSecOps 流程，并介绍在 Microsoft Power Platform 中融入安全性的开发实践。 您将了解现代 DevOps 工具，如 Azure DevOps 服务和 GitHub，以及如何为 Microsoft Power Platform 实施 DevOps 流程的不同方式。 通过正确的 DevOps 实施，我们的解决方案可以在高度监管的行业中以受控且 有序的方式运行。

我们坚信，低代码平台是为专业开发人员设计的。 Microsoft Power Platform 是一个快速应用开发框架，是唯一为公民开发者（创作者）提供 UI 界面的框架。 该平台是为专业开发人员和工程团队创建的，旨在减少业务应用程序的上市时间。 但是，这只有在专业的 DevOps 流程支持下才有效。

作为一种独特的方法，本书将这两个正交的领域结合在一起：一方面是能够构建复杂解决方案的低代码/无代码爱好者，另一方面是了解 DevOps 和应用生命周期管理的专业开发人员。 这些知识对您来说是一个独特的机会，亲爱的读者，能够帮助您建立起有力的竞争力， 在就业市场中占据优势。

作为最后的思考，随着生成性 AI 解决方案的崛起，开发者的工作将发生显著变化，重点将转向提示工程和更大的构建模块。 由于 AI 代理可以充当不同的角色（如开发者、测试人员或项目经理），并且仅凭提供的提示就能独立合成应用程序，因此我们不再编写代码行，而是制作组件。 这些组件可以与 Power Platform 提供的构建模块相对应。 考虑到 Power Platform 的 Copilot，新的应用程序构建时代刚刚开始，只有在与定制开发项目相同的 DevOps 流程得以实施时，才能获得成功。 开发项目。

本书适合的人群

本书面向对软件开发和 IT 运维领域感兴趣的专业人士，特别是那些希望了解应用程序 生命周期 管理 (ALM)以及针对 Microsoft Power Platform 的 DevOps 流程的人士。 适合以下人群：

• 软件开发人员

• DevOps 工程师

• 云架构师

• 站点可靠性工程师

• 测试人员

• 低代码工程师

本书对那些已经具备基本软件开发流程和生命周期工具理解的读者尤为有益。 此外，它也是那些对 Power Platform 的 ALM 和 DevOps 方面感兴趣的专业开发人员的绝佳资源。

本书内容

第一章，掌握 DevOps 和 ALM 以提高软件开发效率，概述了软件开发行业中最重要的突破，如敏捷、精益和 DevOps，并解释了先进的应用程序开发流程和模式，以及前沿的 DevOps 和 ALM 实践。

第二章, Microsoft Power Platform 入门，首先介绍了低代码/无代码开发方法，概述了微软 Power Platform 服务，并描述了该平台如何遵循各种治理和合规标准，使其成为一个适合企业的开发平台。 它展示了如何配置一个试用环境，可以用来配合书中的示例进行操作。 本章还深入探讨了管理 Power Platform 的工具以及开始构建业务应用程序的选项。

第三章, 在微软 Power Platform 中探索 ALM 与 DevOps，致力于建立 ALM 与 DevOps 与 Power Platform 之间的联系。 本章简要介绍了 Azure DevOps 和 GitHub。 为了帮助组织理解如何利用 Power Platform 来改善现有的应用程序组合，本章讨论了应用现代化选项。 本章最后通过连接能力成熟度模型指数（CMMI）和 Power Platform 采纳成熟度模型，帮助组织制定计划，在不同领域提高成熟度。

第四章, 理解 Power Platform 环境与解决方案，涵盖了 Power Platform 的基本构建块：环境和解决方案。 本章还讨论了环境策略、托管环境和 Power Platform 流水线。 本章最后通过一个实践实验室，指导我们如何利用 Power Platform 流水线构建第一个持续集成和持续交付流水线。

第五章, 通过 DevOps 工具简化 Power Platform 开发，更进一步，释放了超越 Power Platform 流水线的工具。 本章讨论了 Git、PAC CLI 和 Azure DevOps Services 流水线，结合 Power Platform 特定的构建任务和 GitHub 动作，来进行跨环境的 CI/CD 解决方案。 最后，本章将前一章中的 Power Platform 托管流水线结果与专业 DevOps 工具相结合，并直接从托管流水线中查看版本控制集成。

第六章，持续集成/持续部署（CI/CD）管道深度剖析，描述了 DevOps CI/CD 流程的高级模式，如 Git 分支策略、Power Platform 的自动化测试框架以及 Power Platform Catalog 的包管理。 它讲解了 Azure DevOps 中的 YAML 管道和 GitHub 工作流，这些工作流分别通过使用各种 PAC CLI 命令、GitHub 动作和 Azure DevOps 构建任务，自动启动开发者分支和开发者环境。 此外，它讨论了 Power Platform 的 ALM 加速器，以及该解决方案如何利用管道模板、分支策略和环境管理等作为可复用的解决方案应用于 我们的项目。

第七章，Power Platform 中的 DevSecOps 概述，介绍了软件开发项目中 DevSecOps 的理论，并将与安全相关的活动映射到我们 Power Platform 项目的 DevOps 流程中。 它深入探讨了 GitHub 高级安全性和静态应用程序安全测试的 CodeQL。 它介绍了解决方案检查器，并展示了如何在有 Entra ID 组、服务主体和其他安全防护措施的情况下大规模启动 DevSecOps 项目。 最后，它通过对已建立流程的表面攻击和风险分析，给出了解决方案管理的建议 ，跨租户管理。

第八章，展示 ALM 和 DevOps 实施，深入探讨了 DevOps 和 ALM 原则的实际应用。 本章提供了一个现实世界示例——Power Platform 企业模板公共仓库中的 Kudos 应用——的动手练习，从 Git 分支策略到 CI 和 CD 管道，再到自动化测试、待办事项管理以及生产环境中应用的监控。 最后，本章介绍了功能标志来控制 功能发布。

第九章, 实施融合开发方法，强调了构建融合团队的重要性，这些团队帮助组织实现目标。 本章展示了融合开发方法的示例，并讨论了 InnerSource 实践的重要性。 然后，继续探讨与 Microsoft Azure 云服务集成的可能性。 最后，通过展示一个常见的 Azure 和 Power Platform 集成场景来结束本章。

第十章, 在 Power Platform 中启用专业开发者扩展性，继续解释专业开发者在为 Power Platform 开发时的各种可能性。 本章涵盖了集成场景中连接器的强大功能以及将配置与应用程序解耦的选项。 它深入探讨了可重用组件和自定义代码组件的强大功能。 本章展示了如何开发代码组件，并如何将 ALM 实践应用于代码组件。 本章最后通过探索 Power Pages 的应用生命周期管理来结束。

第十一章, 环境管理 生命周期 与设计最佳实践，基于设计最佳实践。 本章讨论了 Power Platform 的架构设计及 Power Platform 的着陆区，解释了它们如何帮助组织构建遵循最佳实践并部署在有治理和安全环境中的应用工作负载。 接着，本章转向环境生命周期管理，并讨论了不同方法的自动化环境管理，包括基础设施即代码和 Terraform。 最后，本章通过探讨 Power Platform 卓越中心及 CoE 启动工具包如何帮助组织管理 Power Platform 租户。

第十二章，与 Copilots、ChatOps 和 AI 注入应用程序展望未来，是本书的最后一章，讨论了人工智能如何帮助组织丰富其应用程序。 它有助于理解如何使用各种 Copilot 来提高开发者的生产力，以及 AI Builder 或 Azure OpenAI 如何现代化现有的业务流程。 我们通过讨论 Copilot Studio 和它能够创建定制化 Copilot 来结束这一章和本书，Copilot 可以帮助组织使用定制的 AI 助手自动化 DevOps 流程。

要充分利用本书

你需要具备 Microsoft Power Platform 产品系列的基本了解，以及软件开发实践和 IT 应用管理、支持和监控的基础知识。 除了这些理论知识，你还需要安装以下软件组件，以便能够在本地执行提供的脚本 代码片段：

本书涉及的 软件	操作系统要求
Windows 子系统 适用于 Linux	Windows
Bash	Linux
.NET Framework 4.7.2 或更高版本	Windows
Windows PowerShell 版本 5.x	Windows
Dotnet 6	Windows 或 Linux
PAC CLI	Windows 或 Linux
Visual Studio Code	Windows 或 Linux

请注意，脚本是为在 Azure DevOps 或 GitHub 的云托管代理上运行而创建的，本地执行仅用于 演示目的。

为了充分利用本书，你需要拥有 Power Platform 开发者许可证、Azure DevOps 或 GitHub 组织（公共仓库的免费计划足矣），以及一个 Microsoft Azure 租户。 不需要 Microsoft Azure 订阅，因为我们将仅使用 Microsoft Entra ID 功能来将 Power Platform 世界与我们首选的 DevOps 工具连接起来。 当然，如果你的组织有这些在线服务的企业级套餐，使用示例的体验将更加顺畅 且直接。

书中有许多示例，是为 Azure DevOps 服务和 GitHub 创建的。 这些章节中阐述的概念在这些 DevOps 工具之外是相同的，脚本可以轻松地在这些平台之间迁移。 我们强烈建议你在自己选择的 DevOps 工具中创建工作流，因此可以选择使用 Azure DevOps 或 GitHub 来进行书中的示例。 书中的样例。

在 第七章中，建议为 GitHub 或 Azure DevOps Services 安装 GitHub 高级安全插件。 尽管可以在本地执行 CodeQL 命令，但 Azure DevOps 和 GitHub 的高级安全功能仅在公共项目和公共仓库中可用。 也是如此。

如果你正在使用本书的数字版本，我们建议你亲自输入代码，或者通过 GitHub 仓库（下一个章节提供链接）访问并 fork 代码。 这样做有助于你避免因复制粘贴代码而可能出现的错误。 代码。

你可以将现实世界的示例放在 第八章 的单独仓库中，将你在本书中学到的所有内容放入同一个解决方案中。 这样，你将拥有一个端到端的、生产就绪的 DevSecOps 参考实现，适用于 你的组织。

下载示例代码文件

你可以从 GitHub 下载本书的示例代码文件，地址为 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform。如果代码有更新，将会在现有的 GitHub 仓库中更新。

我们还提供了其他来自我们丰富书籍目录的代码包，地址为 https://github.com/PacktPublishing/。快来看看吧！

使用的约定

本书中使用了许多文本约定。

文本中的代码：指示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。 例如： “我们将通过更改 SingleLine.Text 为数字（Whole.None）来更改 高亮的属性。”

代码块设置如下 ：

 pac admin help
pac admin list help

当我们希望特别引起您对代码块中特定部分的注意时，相关的行或项会以 粗体显示：

 codeql.exe database analyze .\codeql-database-js .\codeql-pack\ javascript\codeql\javascript-queries\0.8.12\codeql-suites\ javascript-code-scanning.qls --format=csv --output=results.csv

任何命令行输入或输出如下所示：

 pac solution create-settings --solution-zip .\EnvConnRef_1_1_managed.zip

粗体：表示一个新术语、一个重要的词汇或您在屏幕上看到的词汇。 例如，菜单或对话框中的词汇会这样显示。 例如：“这次我们选择 新建 | 更多 | 环境变量。”

提示或重要说明

显示如下。

联系我们

来自读者的反馈 总是欢迎的。

一般反馈：如果您对本书的任何部分有疑问，请在邮件主题中注明书名，并通过邮件联系我们 至 customercare@packtpub.com。

勘误：虽然我们已尽一切努力确保内容的准确性，但错误偶尔会发生。 如果您发现本书中的错误，我们将感激您向我们报告。 请访问 www.packtpub.com/support/errata，选择您的书籍，点击勘误提交表单链接并填写 详细信息。

盗版：如果您在互联网上遇到任何我们作品的非法复制版本，我们将非常感激您提供该地址或网站名称。 请通过 copyright@packtpub.com 与我们联系，并提供相关材料的链接。

如果您有兴趣成为作者：如果您在某个主题上有专业知识，并且有兴趣撰写或参与撰写一本书，请 访问 authors.packtpub.com。

分享您的想法

阅读完 《Mastering DevOps on Microsoft Power Platform》后，我们非常希望听到您的反馈！ 请 点击此处直接访问亚马逊的本书评论页面 并分享 您的反馈。

您的评论对我们和技术社区都非常重要，它将帮助我们确保提供优质的 内容。

下载本书的免费 PDF 副本

感谢您购买 本书！

喜欢在路上阅读，但又无法随身携带印刷版 书籍吗？

您的电子书购买是否与您选择的设备不兼容？ 您的选择设备无法使用该电子书吗？

不用担心，现在购买每一本 Packt 图书，你都能免费获得该书的无 DRM PDF 版本 ，无需额外费用。

随时随地，任何设备都能阅读。 从你最喜欢的技术书籍中直接搜索、复制和粘贴代码到 你的应用程序中。

福利不止于此，您每天可以在 收件箱中获得独家折扣、新闻通讯和精彩的免费内容

按照这些简单的步骤获取 福利：

1. 扫描二维码或访问以下 链接

https://packt.link/free-ebook/978-1-83588-084-5

1. 提交您的购买证明 购买证明

2. 就这样！ 我们将直接把您的免费 PDF 和其他福利发送到您的 电子邮件中

第一部分：理解微软 Power Platform 中的 DevOps

在本节中，我们将建立现代 DevOps 和软件开发方法所需的基础知识，并探讨过去十年低代码/无代码框架兴起的原因。 我们将深入探讨微软 Power Platform，概述其丰富的功能集，并将这些功能与已建立的软件开发生命周期方法进行关联。 此外，我们将研究 CMMI 模型的理论及其对 Power Platform 采纳成熟度模型发展的影响，强调这一模型在 我们实践中的重要性。

本部分包括以下章节： 以下是本部分的章节：

• 第一章, 高效软件开发中的 DevOps 与 ALM 精通

• 第二章, 微软 Power Platform 入门

• 第三章, 在微软 Power Platform 中探索 ALM 与 DevOps

第一章：掌握 DevOps 和 ALM 以实现高效的软件开发

自从第一个程序在打孔卡上编写以来，软件开发实践和方法论已经发生了很大的变化。 如今，各行各业的每个业务流程都依赖软件，我们甚至无法想象没有应用程序的生活，因为它们几乎在我们与世界的每一次互动中都被使用。 在疫情期间，数字化转型得到了加速，创建更多应用程序的需求已达到一个无法仅通过传统软件开发工具和框架来满足的程度。 如今，所有组织都可以看作是软件开发公司，不论其所属行业，得益于全球的 数字化转型。

在本章中，我们将 探讨 应用生命周期管理 (ALM) 在软件开发中的背景。 我们将从 软件开发生命周期 (SDLC)概述开始，接着讨论各种软件开发方法论。 然后，我们将深入探讨 ALM 的概念，从 SDLC 的角度审视它，并探讨从需求工程到开发、测试、生产和维护的全过程。 这些知识至关重要，因为它为我们提供了有效管理和简化规划、创建、测试以及部署各种应用程序过程所需的理解。 我们还将探讨精益（Lean）概念的起源，这是一种强调为客户创造价值和消除浪费的哲学，起源于汽车 制造行业。

接着，我们将介绍敏捷宣言和 Scrum 方法论，这是现代软件开发实践中的关键框架。我们将进一步学习 DevOps 支持的架构，包括各种设计模式和非功能性需求，如可测试性和可部署性。我们还将涵盖持续集成（CI）和持续部署（CD），这两种实践自动化了应用程序生产的各个阶段。最后，我们将讨论发布列车和发布周期的概念，这些是以协调和可预测的方式管理新特性发布的策略。这些知识将帮助我们优化开发流程并提高产品质量。

到本章结束时，我们将熟悉最先进的应用程序开发流程和模式，以及前沿的 DevOps（将开发和运维团队整合在一起，持续为客户交付价值）和 ALM 实践。

本章我们将涵盖以下主要内容：

• 软件开发生命周期（SDLC）——它的全部内容

• 软件开发方法概述

• 什么是 ALM？

• 精益原则、敏捷宣言和 Scrum 方法论

• DevOps 支持的架构模式

• 持续集成（CI）和持续交付（CD）

软件开发生命周期（SDLC）——它的全部内容

软件开发生命周期（SDLC），有时也被称为软件开发过程，是用于以成本效益高的方式生产高质量软件的系统化方法论。我们可以使用过去几十年中开发的几种方法论来开发或修改计算机系统。

最初，这一概念是在 1960 年代创建的。 它的主要目标是建立一个可重复、可审计的、当时顺序的软件开发过程，覆盖从应用程序的构思到最终交付解决方案的步骤，目标是企业大型计算机系统。 自那时以来，许多改进、创新和发明已被实施，从面向对象的编程语言引入，到 DevOps 和 DevSecOps 实践，再到云原生架构，这些都推动了更新的 SDLC 方法论的出现。 随着持续的过程改进，大多数现代软件开发方法论如今遵循敏捷 原则。

阶段

无论选择哪种软件开发方法论，软件开发过程的阶段（阶段）是 相同的：

图 1.1 – 软件开发阶段

让我们来探索 这些阶段：

• 需求分析 或 需求工程是开发团队收集客户需求和目标的步骤。 开发团队与客户代表密切合作，以确定解决方案的关键特性。 在此阶段，需求也会被分析，即需求会被验证并且明确记录。 该阶段还包括识别系统的非功能需求，如性能、资源需求或可用性预期。 这是确保最终产品满足客户需求 和期望的关键步骤。

• 规划与设计阶段 是开发团队制定项目计划、安排节奏和关键交付成果的阶段。 这个过程通常以 工作分解结构 (WBS) 为结束，开发团队接着将里程碑分配到 WBS 的不同部分，以便在更高层次上跟踪进度。 里程碑通常表示合同义务的完成，从而触发财务结算。 在这一 阶段，团队还设计软件架构和 用户体验 (UX) 。通常使用 UI 的线框图和架构的原型图来获取更多的工作量估算输入。 另一种计算 WBS 任务工作量和复杂度的方法是进行 所谓的 规划扑克。团队成员使用带有数字的卡片分别为任务分配值。 最后，扑克团队成员展示他们的卡片，并讨论结果，直到达成 共识。

• 开发阶段 本质上是编码部分。 团队实现应用程序，编写单元测试，并调试代码。 传统方法将开发阶段视为仅仅是编写代码。 与此不同，敏捷方法消除了这种分离，并将测试和部署早期纳入过程。 他们这样做是为了能够以迭代方式多次重复编码-测试-部署循环。 此外，这些现代方法通过在 每个迭代结束时提供工作软件的访问，促进了开发团队与客户代表之间的协作。

• 测试与质量保证阶段 是关于为应用程序创建不同层次的测试。 开发团队编写并执行集成测试、系统测试、端到端测试、性能测试以及其他非功能性测试，如资源使用或混沌测试，以验证系统是否符合定义的需求。 过去，曾有专门的测试团队，其主要任务是提供这些测试并确保软件满足客户需求。 当 验证通过后，软件就可以交付到生产环境了。

• 部署阶段 是 开发团队将解决方案部署到客户环境中的步骤。 它不仅涉及安装系统，还可能包括配置系统和在某些情况下迁移来自旧解决方案的数据。 部署可以针对本地或云基础设施进行。 如今，这一过程已经完全自动化。 如果需要，开发团队还会进行用户培训，并将文档（用户手册）交给 客户。

• 维护阶段 是 监控生产环境中解决方案的阶段。 根据结果和客户反馈，开发团队会提供更新、升级、修复错误、安全补丁，甚至新增功能。 这一阶段有时被称为支持期，客户需要支付额外费用才能获得开发团队提供的这些服务。 开发团队。

应用运行平台

低代码/无代码平台 是 应用运行平台 ，使专业开发团队能够开发各种类型的应用。 由于这种应用开发与任何其他定制应用开发完全相同，因此可以将相同的 SDLC 方法论应用于这些低代码或 无代码应用。

根据软件开发项目的不同，组织可以采取不同的工作方式，从遵循固定的指南到适应变化的情况。 然而，在所有情况下，上述阶段是相同的。 在下一部分，我们将学习最常用的方法论。

方法论

正如我们所见，SDLC 描述了软件开发过程的主要阶段，重点关注 为什么，但它没有定义 什么 或 如何 实现这些阶段。 方法论告诉我们在这些阶段中应该交付什么，以及如何工作 的细节。

通过考察以下两种不同的方法论，我们可以更好地理解它们各自在软件 开发项目中旨在定义的内容：

• Scrum 框架会在每 2-4 周 迭代完成 SDLC 的所有阶段，包括需求分析、规划、开发、测试、部署和维护。

• 瀑布方法论 仅按顺序一次性完成 SDLC 阶段，通常需要几个月，甚至有时 需要数年

一些主要的方法论包括以下几种，按时间顺序排列：

• 瀑布

• V 模型

• XP

• 迭代式和 增量开发

• 敏捷（Scrum）

在接下来的部分中，我们将深入了解这些框架和方法论，以及它们如何应用于低代码/无代码平台，如 Microsoft Power Platform。

瀑布

这是最古老的软件 开发过程，按顺序严格定义软件 开发阶段。 并且要求严格。

它常常因为其僵化和顺序化的方法而受到批评。 正如我们将看到的，所有后续的方法论都试图以不同的方式改进这种原始方法，但它在软件开发项目中仍然有一些优势，尤其是在编写内核驱动程序或编程关键任务应用程序（如核电厂软件）方面。 下图展示了本章前面讨论过的瀑布模型中的开发阶段：

图 1.2 – 瀑布模型

这些 阶段，包括需求分析、规划和设计、开发、测试和 质量保证、部署和维护，与本章前面描述的阶段相当。 不同之处在于 这些阶段的顺序执行方式。

该模型的优点如下： 如：

• 它是 用于任务或 业务关键项目的首选方法论。

• 当 重复的 应用程序开发是必要时，它是首选。 这种情况发生在项目高度相似时，比如开发自助服务机应用或编写嵌入式软件。 在这些情况下，需求和客户期望非常明确，不预期会有任何变更。

• 项目 里程碑和截止日期已经 明确定义。

缺点 如下： 如：

• 较高的前期 设计成本

• 在 需求分析后，客户期望无法再被考虑

• 市场推出时间巨大，通常以年为单位进行衡量，并可能导致 交付过时

• 测试 直到 SDLC 的最后才开始进行 测试

尽管有上述缺点，即使在低代码/无代码平台上，我们仍然可以使用这种方法论，利用 平台提供的基础来创建我们的应用程序。

V 模型

该模型是对 之前模型的改进，以通过在 过程中引入并行活动来提高 市场推出时间 关键绩效指标 (KPI)，并通过此方式提升软件质量。

下图展示了该过程 的详细信息：

图 1.3 – V 模型

一切 从将需求（领域空间）分解为可以单独实现的模块或组件开始。 V 模型期望的是模块化架构，但不一定是松散耦合的架构，其中这些组件被视为大系统设计的子系统。 低代码/无代码平台，如微软 Power 平台，提供内建的测试和验证工具，帮助开发人员确保他们的应用程序符合需求并按预期功能运行。 在低代码/无代码环境中，可以通过遵循一个结构化的开发过程来实现 V 模型，该过程包括需求分析、设计、开发、测试和部署。 过程的每个阶段都可以使用低代码/无代码平台提供的工具和功能来完成，使开发人员能够以流畅和 高效的方式构建、测试和部署他们的应用程序。

作为美国政府标准的一部分，针对美国政府机构有一个相应的 V 模型定义。 它比原始的 V 模型定义更加详细和严格，以满足美国 政府的要求。

优点如下： 如下：

• 更快的 市场推出时间，具有更高的 整体速度

• 内建 质量保证

缺点如下： 如下： 如下：

• 它仍然是一个 僵化的过程

• 需求 变化几乎 无法管理

极限编程

极限编程 (XP)作为 一种软件开发方法论，强调 通过保持高 软件质量， 来加速开发团队对客户不断变化的需求作出反应的时间——这是任何软件开发项目中预期的——

这种方法论 已经因为一些范式的转变而闻名，例如引入 结对编程 和严格的代码审查，以及追求最简架构解决方案，这些方案被称为 最小可行产品 (MVPs)。 结对编程技术意味着两个开发者一起编写相同的代码。 一个开发者编写代码，另一个实时审查每一行新代码。 两个开发者经常在这些活动（编写和审查）之间切换，但最终，他们会在 WBS 中专注于相同的活动。 MVP 是最简化的产品，可能存在技术债务和架构违例，但已经能够展示客户或实际需求方要求的特性。 MVP 用于收集来自客户或 合同合作伙伴的反馈。

MVP 的目标是测试产品的核心假设，并评估它是否具备市场适配性，即是否对客户有价值。 在 XP 中，通常的做法是保持这些 MVP 不变，不做超出预期的事情。 XP 的主要原则如下：

• 客户参与: XP 强调开发团队与 客户之间的紧密协作

• 频繁发布: XP 主张频繁发布可用的软件，即使它没有完全实现所有功能

• 结对编程: XP 鼓励开发者成对工作，一人编写代码，另一人 进行代码审查

• 测试驱动开发: XP 强调在实现业务逻辑之前先编写测试，以 确保代码符合 需求

• 持续集成: XP 鼓励频繁集成代码变更，以尽早发现集成 问题

虽然 XP 并不是专为低代码/无代码平台设计的，但 XP 的许多原则可以应用于这些平台的开发。

XP 与低代码/无代码平台

微软 Power 平台作为低代码/无代码平台的市场领导者，支持这些原则中的一些。即使是配对编程（PowerApps 画布应用程序的共同编写功能，带有基于 YAML 的代码编辑器）、画布应用的测试驱动开发以及 CI 也已完全适配到 PowerApps 中。

优点如下：

• 它促进了团队合作与协作，从而可以更有效地解决问题和做出决策。

• 它强调客户满意度，确保客户获得他们需要的产品，也就是产品完全符合他们的期望。

• 它允许灵活性和适应性，因为随着需求的变化和新要求的出现，开发过程可以随时调整。

• 它鼓励频繁的沟通和反馈，这有助于在开发过程中尽早识别并解决问题。

缺点如下：

• 最基本的架构解决方案增加了整体的技术债务。

• 在具有严格等级制度或不重视团队合作与协作的组织中实施可能会面临挑战。

• 准确估算每次迭代所需的时间和资源可能是困难的，这会使项目规划和管理更加困难。

迭代与增量开发

在软件开发中，有两个同样重要的目标：速度和质量。我们已经在之前的方法中看到质量是如何融入到流程中的。然而，质量意味着减速，因为它需要开发团队花费时间和精力，而这些本可以用来创建新的功能和需求。这就是为什么软件行业引入了速度这一概念。速度通过团队在一段时间内交付的功能（故事点）的数量来定义。这是几乎每种 SDLC 方法中的主要 KPI 之一，也是推动增量和迭代方法发展的主要驱动力之一。

迭代和增量开发 是一种软件开发方法，强调将开发过程分解为小块可管理的任务，并 在每次迭代中交付可用的软件。 这种方法提供了灵活性和适应性，因为变更和新需求可以在 它们出现时被整合到开发过程中。

低代码平台，如微软 Power Platform，可以用来支持迭代和增量开发。 这些平台提供构建模块，使得开发人员能够快速构建和部署应用程序，而无需大量编码。 这使得能够快速和迭代地交付可用软件，从而允许频繁的反馈和适应。 在使用低代码平台进行的迭代和增量开发过程中，开发人员可以处理小块、可管理的功能，并随着开发进展不断构建和部署它们。 这使得从最终用户处获得频繁反馈成为可能，并使开发人员能够根据需要整合变更和新需求。 低代码平台提供的可视化开发环境使得更改和添加新功能变得容易，从而使开发人员能够迅速适应 不断变化的需求。

优点如下： 如以下所示：

• 它使得 能够从最终用户那里获得早期反馈和验证，从而确保产品完全符合 他们的期望

• 它使开发人员能够在开发过程中随着问题的出现实时整合变更和新需求，从而提供更大的灵活性 和适应性

• 它降低了项目失败的风险，因为问题可以在 开发过程中早期识别并加以解决

• 它使得 能够快速和迭代地交付可用的软件，从而在 开发过程中早期为最终用户和利益相关者提供价值

缺点如下： 如以下所示：

• 它可能 会给准确估算每个迭代所需的时间和资源带来挑战，这可能使得项目规划和管理 变得更加困难

• 它要求团队成员之间高度的协作和沟通 。

• 由于变更和新需求不断被整合到 开发过程中， 因此很难保持项目的一致愿景和方向 。

快速应用程序开发

快速应用程序开发 （RAD）最初作为瀑布模型的替代方法开发，正如其名字所示，它关注在软件开发生命周期中追求速度和效率。 它由 James Martin 于 1991 年正式提出。 RAD 方法强调通过迭代发布和持续的客户反馈来快速开发应用程序。 通过应用敏捷方法和快速原型设计，RAD 确保了软件的可用性、对用户反馈的响应能力和及时交付。 RAD 的过程驱动特性，专注于 测试原型 和快速调整，使得在 较短的时间内交付预期产品成为可能。

低代码或无代码平台，如 Microsoft Power Platform，是 RAD 的理想工具，因为在传统软件开发中的现有构件——如软件组件和包——之上，开发人员可以轻松添加自定义功能并专注于 价值创造过程。

优点 如下：

• 缩短开发时间并提高团队效率：RAD 方法专注于快速原型设计和迭代发布，这可以显著减少 开发时间。

• 灵活性和适应性：RAD 方法允许在开发过程中进行更改，使其更加灵活，能够适应项目需求的变化。

• 更容易的风险管理：通过将开发过程拆解为更小、更易管理的模块，可以在开发初期识别并解决问题，从而降低 重大挫折的可能性。

• 更少的自定义代码和更短的测试时间：RAD 方法依赖于使用预构建的组件和代码生成工具，这可以减少所需的手动 编码量。

• 实时用户反馈：RAD 方法允许客户随时向开发人员提供反馈，因为开发迭代非常快速，并且它们 最终总是能够交付可用的软件。

缺点 如下：

• 它可能不适用于需要详细规划和设计的大型复杂项目。 RAD 依赖于软件组件的重用，这可能会限制最终产品的灵活性和定制性。 最终产品可能会受到影响。

• RAD 可能导致产品质量较低，因为专注于快速开发可能导致采取捷径和在 开发过程中做出妥协。

• RAD 可能不适用于对安全性、可靠性和性能有严格要求的项目，因为快速开发过程可能无法进行彻底的测试 和优化。

这些缺点 与定制软件开发项目相关，因为测试原型（MVP）和技术债务是硬编码进开发过程中的。 如今，RAD 工具通过公共仓库提供框架和可重用包，支持专业开发团队获得所有快速开发的优势。

RAD 的繁荣

由于企业的数字化转型需求，世界面临传统的长开发周期和软件开发人员短缺的困境，根据 IDC 的预测，到 2025 年，大约 400 万开发人员将从市场上消失。 低代码/无代码平台抓住这一机遇，为 专业开发人员提供 RAD 工具。

敏捷

敏捷 原则强调 灵活性、协作和客户满意度。 “唯一不变的是变化”， “快速测试，快速失败”， “个人和协作优于流程”，以及 “客户优先的思维方式” 是关于敏捷开发过程最常听到的短语。

RAD 与敏捷

尽管 RAD 和敏捷方法论在某些方面有相似之处，但它们在方法上有关键的不同。 RAD 优先开发原型以收集用户 反馈，而敏捷将项目划分为更小的功能，并通过一系列迭代的冲刺逐步交付这些功能 ，贯穿整个开发周期。

在软件开发生命周期中，敏捷是一种迭代方法，专注于频繁交付可用软件，并高度适应不断变化的需求。 敏捷开发团队与客户和利益相关者紧密合作，以优先考虑特性和需求。 他们使用如 CI、自动化测试和频繁发布等技术，确保软件始终处于 工作状态。

在使用低代码平台的敏捷开发过程中，开发人员可以与终端用户密切合作，收集反馈并将变更纳入开发过程中。 低代码平台提供的可视化开发环境使得更改和添加新功能变得容易，允许开发人员迅速适应 变化的需求。

优点是 如下：

• 敏捷 开发允许早期获得终端用户的反馈和验证，这有助于确保最终产品完全符合 预期

• 它使得开发人员能够在开发过程中随时加入变更和新需求，从而提供更大的灵活性 和适应性

• 它降低了项目失败的风险，因为问题和风险可以在 开发过程中 尽早被识别和解决

• 它允许快速和迭代地交付可用软件，在 开发过程中 为终端用户和利益相关者提供价值

缺点是 如下：

• 准确估计每次迭代所需的时间和资源可能具有挑战性，这会使得项目规划和管理 更加困难

• 它需要团队成员之间高度的协作和沟通，这在某些 组织文化 中可能很难实现

• 在项目中维持一致的愿景和方向可能很困难，因为变更和新需求会不断融入 开发过程

理解敏捷概念的一种方式是将其与另一种 SDLC 方法进行比较，例如 V 模型方法。 在 V 模型方法中，产品的范围是预定的，而时间和资源是可以调整的。 使用 V 方法的组织会增加程序员的数量并延长进度，以交付他们计划发布的产品。 另一方面，在敏捷方法中，产品的范围是 可以适应的，而资源和时间是固定的。 敏捷团队承诺按时交付软件，且不增加人员。 他们交付的产品是客户需求和他们在给定 时间范围内能够创造的功能的灵活组合。

敏捷、Scrum 和精益

过去几十年里，软件行业受到了其他概念、理念和看法的重大影响。 一些方法被借鉴自其他行业，例如丰田生产系统的精益管理，另一些则由软件行业的关键人物创立。 我们将简要讨论这些方法，以便了解 DevOps 和 DevSecOps 如何成为软件行业的下一个重要步骤。 软件行业。

敏捷宣言

我们已经讨论过将敏捷作为一种软件开发生命周期（SDLC）方法，因为这个总称不仅可以直接应用于软件开发阶段，还可以映射到整个软件开发组织 及其更广泛的领域。

敏捷宣言 由一群软件开发者于 2001 年创建，他们正在寻求一种更好的软件开发方式。 他们提出了四个核心价值观和十二条原则，成为了敏捷运动的基础。 这四个核心价值观和十二条原则， 自此成为敏捷运动的基础。 敏捷宣言的四个核心价值观如下：

• 个人与互动 重于过程 和工具

• 可工作的软件 重于 详尽的文档

• 客户协作 重于 合同谈判

• 应对变化 重于 遵循 计划

这些价值观和原则已被广泛采纳，帮助软件开发团队提高了软件开发过程的效能和效率。

敏捷（Agile）作为 一个总括性术语，是一个涵盖多种方法论的广泛概念，包括精益、Scrum、看板（Kanban） 等。

精益管理

精益管理由 丰田生产方式的创始人大野耐一发展，是一种通过优化资源、减少浪费（muda ，日语中意指“浪费”）和持续改进流程来为客户创造价值的方法论。 大野的目标是缩短从汽车订单到汽车交付之间的时间：

“我们所做的就是从客户下订单的那一刻起，到我们收取现金的时刻，观察整个时间线。 我们通过去除不增加价值的浪费，来缩短这一时间线。”——大野耐一

精益管理的原则包括 以下内容：

• 价值：识别 客户重视的内容，并集中精力将其交付给客户 。

• 价值流：识别产品或服务的所有步骤，并去除那些没有 创造价值的步骤 。

• 流动：确保 创造价值的步骤平稳连续地流向 客户

• 拉动：让客户需求通过价值流拉动产品或服务，而不是根据 预测推动它 。

• 完美：不断 追求改进，识别并消除流程中的浪费（追求 完美）

任何类型的组织 都可以应用这些原则和流程来提高效率，最小化成本，并提高客户满意度。 其他行业领域，如会计，也已经应用了精益原则。 软件行业采纳这一概念也并不令人惊讶，它将自己视为一个软件生产工厂，并相应地应用 这一类比。

价值流 和 价值流分析 是 最相关的领域，为任何 组织提供了一个工具，用以理解、可视化并改善其价值 创造流程。

下图展示了一个假设的软件开发组织，以及它如何响应客户请求。 交付时间 (LT) 是指从进入阶段到关闭阶段所花费的时间，而 处理时间 (PT) 是指实际工作 或活动所花费的时间：

图 1.4 – 实践中的价值流分析

客户请求会经过不同的团队（如账户、业务分析、工程和运维），每个团队有不同的 LT 和 PT，直到它们到达生产环节。 这个假设的组织可以通过减少每个阶段的 LT 时间，并加快 PT 时间，来提高效率。

显然，低代码/无代码平台，如微软的 Power Platform，可以显著降低 不仅是 PT（处理时间），还包括任何应用程序开发项目的整体 LT（交付时间）。 它们通过使用预先构建的构件，如前端视觉组件、业务逻辑组件和数据访问层，来减少整体开发、测试和部署成本， 从而降低定制应用程序的开发成本。

Scrum

Scrum 是一种源自于一般敏捷原则的框架，常用于软件开发。 它是最广泛应用的敏捷方法之一。 正如我们之前讨论的，敏捷是一个总括性术语，可以在许多方面应用于软件开发生命周期（SDLC）方法、项目管理和组织。 Scrum 是敏捷的具体实现，具有自己的角色、事件、产物 和规则。

Scrum 是一种敏捷 框架，基于透明度、评估和调整的价值观运作。 它采用迭代和增量的方法，以增强可预测性并管理风险。 Scrum 团队通过简短且时间有限的迭代（称为冲刺）交付功能性软件，同时不断评估和调整其过程，以改善产品和工作流程。 下图展示了增量规划 和交付过程：

图 1.5 – Scrum 过程

自主的 Scrum 团队根据客户的优先级和团队的速度决定在给定冲刺中将处理哪些待办事项。这些待办事项将从产品待办列表转移到冲刺待办列表。一个冲刺通常持续 2-4 周，并且每个冲刺结束时，Scrum 团队可以交付一个潜在可交付的产品。

Scrum框架定义了三个主要的角色：产品负责人、Scrum 主管和开发团队。产品负责人负责最大化产品的价值，并代表利益相关者（客户）。Scrum 主管负责推动和支持 Scrum，组织著名的仪式，并鼓励每个人遵守 Scrum 的规则和价值观。开发团队是一个自组织的跨职能团队，负责在每个冲刺结束时交付一个潜在可交付的产品。

Scrum 有多个仪式或事件，用于规划、回顾和改进流程。这些包括冲刺规划、每日 Scrum、冲刺回顾和冲刺回顾会。冲刺规划用于规划即将到来的冲刺的工作。每日 Scrum 是一个简短的日常会议，用于同步开发团队的工作。冲刺回顾安排在当前冲刺结束时，回顾完成的待办事项，并将未完成的项转移到下一个冲刺。冲刺回顾会安排在冲刺回顾后，讨论诸如“哪些做得好？”、“哪些可以做得更好？”以及“我们如何作为团队进行改进？”等问题。结果，团队可以发现潜在的改进点，并将其规划到下一个冲刺中。

Scrum 框架很容易应用于低代码/无代码平台，因为这些平台提供一个生态系统，确保在每个冲刺结束时交付可交付的产品（应用），并且框架定义了角色和仪式。

什么是 ALM？

有很多 关于 ALM 的书籍和文章，看看这些定义，有一点在所有定义中都是共同的：ALM 比 SDLC 更广泛，涵盖了应用程序从构思到开发 再到终止的整个生命周期。

根据定义，ALM 指的是计算机程序整个生命周期的管理，包括治理、开发、维护和终止。 它涉及广泛的活动，如需求管理、软件架构和 项目管理。

SDLC 是 ALM 的一个组成部分，提供了应用程序开发阶段的详细描述。 ALM 在应用程序生命周期中可以涉及多个 SDLC 的迭代，即在不同阶段可以应用多种方法论，如敏捷方法和 V 模型。 ALM 在开发和首次发布后继续进行，直到应用程序不再使用。 不再使用。

ALM 将多个学科和角色结合在一起。 它包括项目管理、变更管理、需求管理、软件架构、CI、开发、CD、测试、发布管理和维护。 这些学科在过去是分开管理的，组织在建立 ALM 之前，通常是高度孤立的。 内部流程优先于不同角色和部门之间的协作与沟通。 组织内部。

如今，ALM 工具为软件开发团队和相关部门（如项目管理、业务分析、测试和 IT 运维）之间的沟通与协作提供了一个标准化的平台。 这些工具还可以通过自动化简化软件开发和交付的过程。 通过自动化。

现代集成的 ALM 工具，如 Azure DevOps Services、GitHub 或 GitLab，支持 以下内容：

• 需求工程

• 项目管理 – 包括规划 和跟踪

• 错误和 问题跟踪

• 版本 控制系统

• 构建 – CI

• 自动化测试

• 发布 – CD

• 在生产环境中监控应用程序，并从使用模式、遥测日志 和故障中学习

下图展示了 ALM 的主要领域以及这些不同学科如何以 循环方式协同工作：

图 1.6 – ALM 的主要领域

ALM 很容易应用于低代码/无代码平台，因为这些平台旨在作为现代应用程序运行平台，承载和执行由 专业开发人员创建的数百个甚至数千个应用程序。

在接下来的章节中，我们将学习如何结合 Microsoft Power Platform 实现 ALM 的各项规范。

CI 和 CD

CI 和 CD 是现代软件开发和 ALM 实践中广泛使用的 过程和工具。 CI 管道（工作流）用于编译源代码并使用构建代理生成二进制文件，而 CD 管道则将这些二进制文件及其配置整个解决方案部署到不同的环境，如开发、测试、 或生产环境。

CI 有时被称为 CI 构建，因为它最终在专用构建机器上执行源代码的官方编译（有时这些机器只是 Docker 容器）。 在 CI 构建过程中，还会执行单元测试；这些测试不需要协调应用程序，并且运行在毫秒级别。 CI 是确保软件质量并避免应用程序回归的最重要过程之一。 对于大型开发项目，创建 构建农场 是非常常见的， 这些构建农场由数百台构建机器组成，用于在每次 代码变更时生成交付物或包。

实践中有两个 CD 术语。 持续交付 意味着应用程序随时准备交付，但部署过程并不自动化。 持续交付的典型例子是编译代码后创建 Docker 镜像，或为生成的二进制文件创建安装程序。 持续部署 则需要一个额外的步骤，并且自动化部署过程到目标环境。 在本书中，CD 的缩写指的是后一种定义。 需要注意的是，CD 过程会将应用程序的相同版本传输到不同的环境，并在每个阶段设立质量门。 下图展示了一个典型的 CD 过程：

图 1.7 – 带质量门的 CD

在 CI 过程中成功编译源代码后，生成的二进制包会通过部署流水线。 部署流水线将这些包以完全自动化的方式传递到不同的环境（开发、UAT、生产），并通过执行 自动化测试来验证和确认更改。

在 DevOps 实践高度成熟的组织中，通常会频繁进行 CD，有时一天进行几十次甚至上百次，以将解决方案的一部分直接交付到生产环境。

作为部署过程的一部分，通常会使用 CD 工作流来实施开发应用的部署策略。 有几种部署策略可以用来发布新版本的 应用程序：

• 基本部署 是最简单的 部署策略，方法是 将应用的新版本部署到生产环境中，替换掉旧版本。 这种方法直接明了，但可能会导致停机时间，并且如果出现问题，不能提供一个简单的方式回滚到之前的版本。

• 蓝绿部署 涉及拥有两个完全相同的生产环境。 一个运行着 旧版本的 应用（蓝色），另一个运行着新版本（绿色）。 一旦新版本经过测试并准备好发布，流量将逐渐从蓝色环境切换到绿色环境。 这种方法使得如果出现问题，回滚变得容易，因为流量可以简单地切换回 蓝色环境。

• 金丝雀部署 类似于蓝绿部署， 但不是一次性切换所有流量，而是最初只有一小部分流量会被导向应用的新版本。 这种方法可以在完全发布之前，使用真实用户和真实流量来测试新版本。 如果一切顺利，流量将逐步转向新版本，直到它处理所有流量。

• A/B 测试 是一种 常用于测试应用新功能或更改的部署策略。 它涉及同时运行两个版本的应用，一部分用户被引导到旧版本，另一部分用户被引导到 新版本。

• 滚动部署 是一种策略，通过这种策略，应用程序的新版本会逐步发布到生产环境。 此操作通过一次更新一部分服务器或实例来完成，而其余的服务器或实例则继续运行应用程序的旧版本。 一旦更新完成并确认正常工作，接下来的一部分服务器或实例将被更新，以此类推，直到所有服务器或实例都运行新版本的 应用程序。

现代的 ALM 工具，如 Azure DevOps Services、GitHub 或 GitLab，提供了端到端的 CI/CD 管道和工作流支持，并自动化了所有在代码提交到 Git 仓库之后的操作。

在使用 Kubernetes 编排器托管和扩展高度分布式服务的云原生微服务架构中，广泛采用所谓的 拉取 模型 将最新版本部署到生产环境中。 这种方法被称为 GitOps。诸如 ArgoCD 或 FluxCD 之类的工具运行在 Kubernetes 集群内，当监控的 Git 仓库发生变更或提交时，这些工具会在集群内部署更新，并实现零停机时间的发布。 在低代码或无代码平台中，这种方法仅部分适用于可以考虑拉取模型的场景，例如从中央仓库获取配置数据或利用 功能开关（feature flags）。

DevOps 支持的架构模式

DevOps 是我们在软件行业中看到的左移（shift-left）方法之一。 它将运维团队（ops）与开发团队（devs）紧密结合，以实现并加速持续的价值交付给我们的客户。 这意味着对人们的思维方式和文化的改变；它要求有流程和工具来将一个组织转变为 DevOps 组织。

“你构建，它就由你来运行”是描述开发和运维团队如何需要紧密合作，形成一个多元化团队，覆盖从编码到部署再到运营的端到端重复过程的最有力的名言之一。 运维成为团队的一部分。 这种左移方法提高了组织的整体生产力。 DevOps 是一个范式转变，也是一个文化上的变革，旨在提升开发和运维团队之间的协作，并提高软件生产的效率和质量。 一种复兴 Day 0 公司 心态的方法，通常被称为 创业心态，涉及定义企业客户在受监管行业中需要实施和维护的基本规则、流程和保障措施。 在大规模下保持敏捷和价值导向意味着去除所有不属于价值创造过程的浪费。 DevOps 还为企业带来了另一个好处，那就是仅维护一个版本的已开发产品：即运行在 生产环境中的版本。

此外，DevOps 期望对生产环境中的软件进行高级监控，以避免盲目操作服务。收集遥测数据、追踪和调用栈以防故障至关重要，能够了解已开发的 服务或组件是如何被使用的。 应用性能监控 (APM)工具，如 Azure 应用洞察，可以用于监控并主动发现性能下降，避免 故障发生。

DevOps团队同样强调，解决方案应该能够创建零停机部署的生产环境。 如 Kubernetes 等调度器和应用程序运行时通过设计本身支持这一方法，采用 滚动部署。

在高度成熟的 DevOps 团队中，滚动向前的概念也被广泛应用。滚动向前意味着，如果在生产部署过程中遇到问题或错误，团队会为其修复并推出该版本。 回滚到先前版本不再被考虑。

DevOps 还在软件开发行业定义了新的角色。 其中之一是 直接负责个人 （DRI）角色，这个角色 也被称为 Google 的 警长 或 Facebook 的 指定响应个人。该 DRI 负责事故管理、服务可用性和服务健康。 他们是冲刺期间的唯一联系人，既包括内部也包括外部。 如果发生高影响或中等影响的停机，他们将与客户、报纸以及其他媒体沟通。 这显著改善了整体客户体验。 另一方面，他们还在服务事故发生期间，向其他 DevOps 团队提供信息。

高度成熟的 DevOps 团队及其成员甚至可以在每个冲刺中担任不同的角色。 例如，DRI 角色在团队内每个冲刺中轮换。 这为团队成员带来了巨大的好处：经过几个冲刺后，团队中的每个人都可以在每个领域（编码、测试和操作 服务）积累专家知识。

DevOps 还假设高度自动化的流程。 在大型 IT 公司中，有一些工程团队遵循自动化一切的原则。 经验法则是：如果我们只需要做一次，我们可以手动完成，但如果需要重复做，即使只是再做一次，我们就有责任创建自动化脚本 来实现它。

任何架构都涉及到所谓的 -ilities ，它们是非功能性要求，如可审计性、可用性、兼容性、组合性、可配置性、可访问性、适应性、可承受性、可定制性、可演示性、可部署性、耐用性、可用性、可扩展性、灵活性、互操作性、可管理性、可移植性、可预测性、可恢复性、可靠性、可重复性、可重用性、可扩展性、可维护性、社会性、简易性、可测试性、可持续性、可追溯性、可复制性等。

Power Platform 和 -ilities

Power Platform 组件 被设计成这样，几乎所有这些能力都可以开箱即用。 作为 Power Platform 解决方案架构师，我们无需担心诸如审计性、可用性、可重用性等要求，因为这些都由 底层应用程序运行时作为 软件即服务 （SaaS）提供。

有两个非常重要的因素 对于 DevOps 来说：

• 可部署性 指的是 能够轻松、可靠地将应用程序的新版本部署到生产环境的能力。 生产环境

• 可测试性 指的是 系统或其组件是否能够轻松地进行测试，以确保它们符合指定要求并且 正确地运作

这两者 能力 使得开发人员能够更改代码库中的任何部分，并轻松、可靠地部署新版本。 理想的 DevOps 架构基于松耦合的服务（不一定是微服务），这些服务可以在不同的发布周期中部署到生产环境。 应用程序及其组件被设计为支持多种部署策略，例如基础部署、蓝绿部署、金丝雀部署、A/B 测试和滚动部署，正如 前面提到的那样。

下图展示了基于单体架构的部署与现代 基于微服务的方法：

图 1.8 – 单体架构与松耦合服务和发布

在单体架构中，尽管 团队们在软件的不同部分进行工作，但发布只能是一次性进行的，包含所有服务的更改。 如果 A 团队开发的 A 服务导致发布失败，那么 B 团队和 C 团队的更改也无法到达生产环境。 另一方面，如果底层软件架构基于松耦合服务（例如，基于 OpenAPI 规范的 REST API 端点），那么不同团队开发的服务可以并行部署到生产环境中。 部署 失败的影响仅限于局部，从而减少了 爆炸半径 在生产环境中的影响。

ALM 和 DevOps

ALM 是一个更广泛的概念，涵盖了软件开发的各个方面，而 DevOps 主要关注开发与运维团队之间的协作，以提高软件开发过程的效率。 DevOps 可以视为 ALM 的一部分，因为它有助于简化软件应用程序的开发、测试和部署。

如果大型工程组织需要基于 DevOps 实践在企业规模上运行敏捷， 精益敏捷框架 （SAFe）提供了 合适的结构。

SAFe 是一个用于在企业规模实施敏捷原则的模式和实践框架。 它详细定义了角色和职责，并提供了如何通过价值创造过程在如此大规模上规划和管理工作的具体指导。 SAFe 旨在在大型团队和业务单元中实施敏捷实践，并使得能够获得这些敏捷 团队进展的组合级概览。

SAFe 基于七个核心的业务敏捷能力，这些能力包括精益敏捷领导力、团队和技术敏捷性、敏捷产品交付、企业解决方案交付、精益组合管理、组织敏捷性和持续学习文化。 这些能力旨在帮助组织实现其业务目标，并为 客户提供价值。

SAFe 还包括 一个 敏捷发布列车的概念，这是一个跨职能的敏捷团队，负责按同步节奏规划、构建和交付软件。 在这种方法中， 发布列车 负责协调应用程序新版本的部署，使用 DevOps 架构支持的部署策略。 这使得发布过程更加顺畅高效，同时确保应用程序以高质量和高可靠性持续交付给用户。 SAFe 可以通过定制我们的工作项跟踪体验来支持功能、史诗、发布列车以及 多个待办事项列表，在 Azure DevOps 服务中的 Azure Boards 上实现。

总结

在本章中，我们探索了软件行业中最重要的突破，深入研究了各种 SDLC 方法论、敏捷宣言、精益管理、Scrum 框架、ALM 和 DevOps 实践。 我们了解了定义现代应用程序开发和架构的模式和实践。 这些技能和经验是软件开发的基础，且是每位工程师必须掌握的核心概念。

正如我们所总结的，现代应用程序开发遵循 DevOps 原则，利用 ALM 工具和学科来最大化价值。 现代应用程序架构基于松耦合服务或微服务，并支持两个关键模式：可部署性 和可测试性。

在接下来的章节中，我们将探索如何将这些现代应用程序开发模式和实践应用于 Microsoft Power Platform，以及如何为 Power Platform 实施 DevOps 和 ALM。

进一步阅读

• Geoffrey Elliott (2004). 全球商业信息技术：一种集成系统方法。 皮尔森 教育: https://www.amazon.com/Global-Business-Information-Technology-integrated/dp/0321270126

• Everatt, G.D.; McLeod, R Jr (2007). “第二章: 软件开发生命周期”。 软件测试：跨整个软件开发生命周期的测试。 约翰·威利与 儿子公司: [https://dahlan.unimal.ac.id/files/ebooks/2007%20[McLeod_R.]_Software_Testing_Testing_Across_the_E.pdf](https://tinyurl.com/uw2r7c8r)

• V-Model： 美国交通部，联邦公路管理局。 系统工程手册 ITS: https://www.fhwa.dot.gov/cadiv/segb/index.cfm

• Power Apps RAD： https://powerapps.microsoft.com/zh-cn/rapid-application-development-rad/

• ALM: DAVID CHAPPELL (2008): 什么是应用程序生命周期管理？: https://aws.amazon.com/what-is/application-lifecycle-management/

• 精益管理： 大野耐一：丰田生产方式 系统： https://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143

• DevOps： https://learn.microsoft.com/en-us/devops/what-is-devops

• 麦肯锡公司：通过开发者速度推动商业成果 2020： https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance#/

• DRI 角色： https://www.microsoft.com/insidetrack/blog/rotating-devops-role-improves-engineering-service-quality/

• SAFe: https://scaledagileframework.com/agile-release-train/

第二章：开始使用 Microsoft Power Platform

Microsoft Power Platform，作为多年来被公认为领先的企业低代码应用平台，是一种帮助组织实现业务流程数字化的技术。 在本章节中，我们将为你提供 Microsoft Power Platform 的概述，并帮助你理解为什么每位专业软件开发人员或业务用户都应该掌握这项低代码/无代码 应用平台的技能。

我们将探索 Microsoft Power Platform 家族中的各种产品，例如 Power Automate、Power Pages 和 Copilot Studio。 熟悉 Microsoft Power Platform 家族成员将帮助你更好地理解如何挑选和选择合适的服务来简化你的工作流程。 我们将创建我们的第一个试用环境，以测试 Power Platform 的功能。 然后，我们将进入 Power Platform 管理，讨论 Microsoft Power Platform 遵循的标准和合规性规定，并以使用 Power Apps 和 Power Automate 的一些常见真实世界商业解决方案的解释作为结束。

在本章节中，我们将讨论以下 主要内容：

• 低代码/无代码的崛起 低代码/无代码的崛起

• 开始使用 Microsoft Power Platform 服务

• Power Platform 管理

• 治理、合规性和 数据隐私

• 开始构建真实世界的 商业解决方案

技术要求

本章节不要求任何特定的技术前提。 我们将介绍 Microsoft Power Platform 服务和管理配置选项，你可以通过使用带有现代浏览器并连接互联网的工作站来跟随学习。

在本章节中，我们将使用一组试用的 Microsoft Power Platform 许可证，以便创建一个 Power Platform 环境，之后你可以继续使用它来测试 Microsoft Power Platform 服务。

如果你已经拥有自己的 Microsoft Power Platform 环境，可以随时使用它来跟随本章节的内容，更重要的是，之后的章节会有更多动手练习，你可以继续使用它。 我们建议为本书中的工作创建一个单独的 Power Platform 环境。

低代码/无代码的崛起

在本 节中，我们将探讨 低代码/无代码 (LCNC) 开发的概念，并探索为什么市场上对采用这种方法及其相关工具的需求日益增加。 通过这样做，我们将深入了解这种应用开发方法的意义以及它在 未来的发展方向。

LCNC 是一种应用开发方法，允许开发者在较短时间内以较少或无需编写代码的方式创建软件应用，并借助 软件即服务 (SaaS) 平台，抽象化了与扩展、数据管理等相关的复杂性。 尽管我们经常看到 LCNC 作为一个完整的术语，但 LC 和 NC 之间还是存在一些区别。

LC 开发方法仍然要求应用开发者至少具备基本的软件开发知识，因为某些部分的应用可能仍然需要使用代码来支持业务逻辑或某些功能。 这使得我们能够构建比 NC 应用程序更为复杂和精密的软件应用。

在今天的 人工智能 (AI) 和 AI 助手（例如微软的 Copilots），它们通过仅使用自然语言指令帮助我们提高工具使用效率，我们也可以通过仅提供自然语言提示，从中获得完整的代码。 这缩小了 LC 和 NC 开发方法之间的差距。 然而，这些 AI 助手之所以被称为 Copilot，是有原因的，因为用户仍然需要理解收到的建议，以验证其是否会执行所指示的操作。 本书的最后一章将介绍微软的 Copilots，特别是适用于 Power Platform 服务的 Copilots，这将帮助我们进一步了解如何从中受益。

NC 开发方法专注于使用可视化工具，通过拖放功能直观地构建应用程序，允许进行简单的定制，如属性和配置。 使用这种方法意味着我们的定制性会更受限制；相反，我们不需要任何软件开发的先验知识。 这使得几乎任何组织中的人都可以成为应用程序开发者。 NC 方法还可以用于快速原型开发应用程序，之后将其交给具有 LC 经验的专业开发者或应用程序开发者，进一步扩展应用程序的 复杂逻辑。

许多平台，包括 Microsoft Power Platform，结合了这两种开发方法，从而使组织能够根据项目/应用程序和 可用资源选择合适的方法。

LCNC 应用程序开发方法并不是什么新鲜事物。 LCNC 开发平台可以追溯到 20 世纪 80 年代。 Microsoft Excel、第四代编程语言以及快速应用程序开发工具在 Microsoft Power Platform 的发展中都发挥了重要作用。 第四代编程语言 (4GLs)实际上是专门为那些不一定是软件开发者的人设计的，因为与其他编程语言相比，编程语言更简化，操作时需要的命令更少。 编程语言。

尽管市场上有许多工具可以使用户使用 NC 方法构建他们的应用程序和网站，但微软工具如 Microsoft Excel、Access 以及其他商务生产力工具的丰富历史，在我们今天所知的 LCNC 开发平台的创建中，起到了重要作用。 它们今天的面貌。

LCNC 开发方法背后的理念是为非开发者、业务分析师和业务用户提供一个平台，他们可以利用已有的知识来使用该平台。 由于许多用户已经知道如何使用像 Microsoft Excel、Microsoft Word 和 Microsoft PowerPoint 这样的微软工具，他们可以轻松学习如何使用 Microsoft Power Platform，它就像是这些产品的组合。 这使得任何人都能更快地创建业务应用程序，无需或仅需少量编写代码。 有趣的是，甚至代码编写部分也遵循相同的模式，并与 Microsoft Excel 中的公式编写经验相匹配，这进一步强化了微软工具之间连接体验的理论。 Microsoft 工具。

LCNC 开发的当前状态与未来趋势

随着工作节奏的加快 以及不断推动数字化运营的需求，许多公司寻求在更短的时间内做更多的事情，借助的工具不仅可以被传统的软件开发人员使用，还能被其他员工使用。 任何有决心开发新应用、数字化并优化业务流程的人，都可以成为应用开发者，构建支持业务运营的应用程序、自动化工作流和聊天机器人。 “每个人都可以成为开发者”这一理念推动了 LCNC 工具的普及。 然而，我们看到这些工具普及的背后，还有其他一些原因。 这些工具的普及有着更多的推动力。

在过去五年中，全球范围内对 LC 开发平台的兴趣显著增加。 推动这一增长并促使各组织加速数字化转型的最大里程碑无疑是 COVID-19 大流行。 在全球大流行期间，各组织急于寻找快速适应市场变化并数字化其运营的方式。 这需要更快地开发业务应用程序，从而 增加了对熟练专业开发人员的需求。 然而，结果是，这导致了市场上专业开发人员的短缺。

根据 2022 年美国劳工统计局的预测，在未来 10 年内，应用开发和质量保证测试需求将增长 25%，这一增速远高于所有职业的平均水平，正如他们报告中所提到的。 公司现在可以通过招聘 LC 开发人员或培训其业务用户成为 应用开发者 来弥补专业开发人员的短缺。

根据 Gartner 的预测，LC 开发技术市场将进一步增长。 根据 2022 年的市场研究，预计到 2024 年，LC 应用平台将成为 LC 开发技术市场的最大组成部分，收入将接近 123 亿美元。 LC 应用平台预计将在 2024 年达到接近 123 亿美元的收入。 收入将继续增长。

在我们讨论 LC 开发工具时，你可能会认为这只涉及软件应用程序开发领域；然而，我们不应忽视对超自动化的日益关注。 这是一个涵盖多种技术的领域，包括 机器人过程自动化 (RPA) 和 数字过程自动化 (DPA)，这些技术帮助组织 应对其 业务操作数字化的巨大需求。

同样，AI 助手，如 Microsoft Copilot，可以帮助提高 LCNC 工具的采用率。 仅凭自然语言，应用开发者就可以将他们的想法转化为完全 功能性的应用程序。

理解 LCNC 的好处

LCNC 开发 方法为组织提供了多个好处。 其中一个最大好处是，几乎任何人都可以成为应用开发者，无论他们的开发技能如何，这有助于弥合专业开发者的差距。 那些没有软件开发经验、且偏好可视化开发体验的人可以利用 NC 方法，而那些具有一定软件开发技能或编写公式经验的人可以从 LC 方法中受益，在这种方法中，应用开发者可以专注于特定业务应用的业务逻辑，而非专注于软件应用程序的底层源代码。 软件应用程序。

这种开发方法能够帮助组织节省时间和成本，使他们能够以更少的资源、更快速和更轻松的方式构建定制的软件应用程序，同时其应用程序由 SaaS 平台提供支持，该平台提供安全性、可扩展性、治理和 数据管理。

最后，我们不能忽视这样一个事实，即 LCNC 开发工具提供了与第一方和第三方工具的极好集成可能性，这使得软件应用程序的开发速度更快，不同系统、应用程序 和服务之间实现集成。

开始使用 Microsoft Power Platform 服务

本节将介绍 Microsoft Power Platform 及其基本组成部分。 我们将解释这些工具如何帮助用户创建业务应用程序、自动化流程，甚至获取数据洞察。 我们还将解释如何创建自己的 Power Platform 试用帐户，以创建一个可用于测试平台功能的环境，并帮助你跟随以下章节。

什么是 Microsoft Power Platform？

Microsoft 的 LCNC 开发方法不限于单一工具；相反，它提供了一个用户 工具套件 ，涵盖不同的重点领域， 允许用户单独使用或结合使用这些工具，构建端到端的 业务解决方案。

Microsoft Power Platform 包括五个 主要产品：

• Power Apps

• Power Automate

• Copilot Studio

• Power Pages

• Power BI

这些服务都通过一个可扩展的基于云的数据存储系统连接，称为 Microsoft Dataverse。

图 2.1 – Power Platform 的五大主要产品和支持服务

拥有多样化的 LCNC 产品组合使用户能够以灵活且模块化的方式构建业务解决方案。 这些工具不仅与其他 Microsoft 产品本地集成，还使用户能够更 高效地构建解决方案。

通过此功能，用户还可以灵活地仅为所使用的产品购买许可证，因为 Microsoft Power Platform 的服务是单独授权的。 许可证可以是独立的，例如 Power Apps Premium 许可证，也可以与 其他许可证一起包含。

作为一个包含许可的示例，一些微软产品（例如 Microsoft 365 或 Dynamics 365）使你可以使用选定的微软 Power Platform 服务的有限功能。此类封装许可类型被称为“种子许可”。例如，Microsoft 365 E3 或 E5 的许可证包括 Power Apps 和 Power Automate 的有限功能集。要启用 Power Apps 和 Power Automate 的所有 Premium 功能，需购买并使用单独的 Premium 许可证。通常，这些许可证使用按用户订阅的模式；不过，也有其他变体。

重要提示

尽管本书不会深入讨论许可细节，但我们鼓励大家浏览微软网站上提供的各种许可模型，因为微软 Power Platform 的许可会定期更新，这使得它成为一个高度动态的话题。管理员和 DevOps 工程师应将定期检查变更作为其职责的重要组成部分。保持信息更新有助于在 Power Platform 生态系统中确保有效的管理和合规性。

有关 Power Platform 功能和定价的更多信息，请参阅 Power Platform 许可指南，您可以在以下文档页面访问：learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus。

2016 年 10 月，微软发布了普遍可用的 Power Apps 和 Flow（现称为 Power Automate），今天，我们拥有一个非常成熟的平台，连续五年被 Gartner 评为“企业 LC 应用平台”领域的领导者，在 Gartner Magic Quadrant TM 中名列前茅。

虽然该平台主要面向市民开发者，但它使你能够构建集成场景，并且具有可扩展性，甚至适用于专业开发者（例如，通过在 Azure API 管理中发布的自定义 API 构建自定义连接器，使用 Power Apps 组件框架开发代码控件，以及使用AI Builder发布自定义模型）。

接下来，让我们来看看微软 Power Platform 的家庭成员。

Power Apps

Power Apps 是一款 允许用户创建和运行定制业务应用程序的产品。 应用程序可以通过使用 Visual Maker Studio 和拖放功能，无需大量编码就能快速开发。 专业开发者和应用程序开发者可以创建连接到各种数据源，并通过连接器与许多现有应用程序和服务集成的应用程序。 应用程序可以作为画布应用程序开发，重点是设计和定制界面，或者作为模型驱动的应用程序开发，重点是数据模型。 画布应用程序的一个有趣方面是，这种类型的应用程序可以打包成原生的移动应用程序包，类似于定制的 Android 和 iOS 应用程序。 然后，这些应用程序可以通过 Google Play 商店、Apple Business Manager、Microsoft Intune 和 Microsoft App Center 分发给移动终端用户。

Power Automate

Power Automate 是一款 基于云的工作流服务，帮助客户解决超自动化问题。 它不仅限于构建自动化简单的日常重复任务的工作流，还可以自动化跨各种服务和系统的复杂业务流程。 如果你已经使用 应用程序接口 (API)来访问一些后台服务，那么 数字化流程自动化 (DPA)可以通过 Power Automate 来实现。 如果你想要 自动化在桌面应用程序中执行的重复任务，或者通过 RPA 构建网页自动化，Power Automate 可以为你提供 支持。

Copilot Studio

Copilot Studio 是一个 构建独立助手的平台。 它基于 Power Virtual Agents 平台构建，该平台用于构建智能虚拟助手和聊天机器人。 Copilot Studio 使我们能够通过构建控制对话流程或使其更具动态性的主题来创建自定义助手，借助 大型语言模型 (LLMs)，例如 GPT。 自定义助手帮助用户执行任务或回答问题。 它们可以通过连接器和插件与组织数据相连接，组织数据作为知识库，通过后端系统来解决复杂任务。 助手可以通过不同的渠道发布，如网站、自定义的移动/网页应用程序，或任何其他用于通信的服务，如 Facebook、Slack、 或 Twilio。

Power Pages

Power Pages 是一个 企业级、可扩展且安全的基于云的服务，用于构建丰富且数据驱动的网站。 它广泛依赖于 Dataverse 来存储配置和数据，这些数据会在网站上展示。 尽管它是 Power Platform 家族中最年轻的成员之一，但 Power Pages 在发展成今天所知的产品过程中，经历了相当长的历程。 它始于微软收购 Adxstudio Inc.，然后变成了 Power Apps Portals，而今天，我们 拥有了 Power Pages。 它的核心保持不变——一个允许用户创建、托管和管理现代且具有视觉吸引力的网站的平台，以数据为 核心。

Power BI

而 Power Platform 家族中的其他产品旨在自动化业务流程和构建业务应用程序，Power BI 是一套工具，使我们能够深入了解数据并构建智能报告，帮助我们快速提取数据中的关键信息。 仪表板和报告可以遵循与业务应用开发相同的 LCNC 方法进行构建。 通过使用拖放体验，我们可以连接各种数据源，构建表示 提取数据的图表和方块。

Power Platform 的扩展生态系统

除了这五个核心产品外，Power Platform 产品还由其他服务和功能支持，如 Dataverse、Power Fx、连接器、Copilots 和 AI Builder。 Power Platform 中的 Copilots 和 AI Builder 将在本书的最后一章深入讲解，但我们将在 这一章讨论其余内容。

Dataverse

Dataverse 是一个 安全且可扩展的云数据存储，广泛应用于 Dynamics 365 和 Power Platform。 它允许我们创建将被业务应用程序使用的新表，并对其应用严格的安全模型和治理策略，如权限、基于列的安全性和审计能力。 它还允许我们在 Dataverse 中创建视图和表单，随后可以在数据模型上快速构建应用程序。 Dataverse 还允许我们构建定义数据生命周期流转和适用业务规则的业务流程流。 这些规则适用于表格。

Power Fx

Power Fx 是一个 通用的 LC 语言，广泛应用于 Microsoft Power Platform。 最初在 Power Apps 中出现的 Power Fx，现在已扩展到其他 Power Platform 服务，为构建公式提供了统一的体验。 Power Fx 被用于在业务解决方案中构建自定义逻辑。 凭借类似电子表格的公式和与 Microsoft Excel 的相似性，它促进了快速的采用。 Power Fx 是开源的，这 使得它具有更高的透明度并且 支持社区协作。

连接器

连接器 在 Microsoft Power Platform 生态系统中发挥着至关重要的作用。 它们充当 Power Platform 与外部服务或数据源之间的集成桥梁。 每个连接器都有一组自己的触发器和操作。 从许可角度来看，它们被分为标准连接器和高级连接器，但从技术角度来看，它们被分为预构建连接器（连接到第一方或第三方服务）和自定义连接器。 我们将在 后续章节中深入探讨连接器。

设置我们的第一个环境

现在我们对 Power Platform 家族中的产品有了更好的了解，接下来我们来创建一个环境，用于测试 这些服务。

如前一部分简要提到的，Power Platform 产品是单独授权的，因此在创建试用环境时需要特别注意。 我们建议首先创建一个 Microsoft 365 E3 或 E5 试用环境。 这 将使我们能够测试与 Microsoft 365 或 Office 365 服务的集成功能——例如，在 Power Automate 中创建一个工作流，使用 Office 365 中的 Outlook 发送电子邮件。 另外，可以使用 OneDrive for Business/SharePoint Online 文档库来存储和管理一些 Excel 文件，然后这些文件在 Power Apps 中使用，数据通过表单 和图库进行可视化展示。

获取 Microsoft 365 E3 或 E5 试用账户

通过搜索 Microsoft 365 (M365) 网站上的 可用计划和 定价，我们可以找到多个带有一个月免费试用的 M365 计划。 此类计划的示例如下： https://www.microsoft.com/en-us/microsoft-365/enterprise/office-365-e3。由于链接可能会发生变化，我们建议浏览 M365 网站上的可选项，并在 立即购买 按钮下，会有一个 免费试用 选项，可以启用免费试用。 然后，向导会引导我们完成试用许可证的配置过程。 首先，我们需要 提供我们的电子邮件地址和 登录 信息。

图 2.2 – 一个 Microsoft 365 E3 试用账户

请记住，我们可能需要添加信用卡，仅用于验证。 我们建议在租户中至少保持添加的支付方式，直到完成所有所需试用许可证的配置，因为 Power Platform 许可证也需要支付方式进行验证。 一旦我们完成了将选择的试用许可证添加到租户，或者我们想要移除支付方式以避免任何可能的许可证延期和相关费用时，我们可以在 Microsoft 365 管理中心 (https://admin.microsoft.com) 使用全局管理员帐户移除支付方式。 如果我们后来决定 继续使用此试用帐户并将其转换为更长期的测试环境或生产环境，我们可以向帐户中添加支付方式，并继续在 此租户中运行服务。

我们可以通过登录到 Microsoft 365 管理中心，进入 帐单 | 支付方式 部分，添加新支付方式，或者选择现有的支付方式并 将其移除。

现在我们已经创建了一个 Microsoft 365/Office 365 租户，接下来让我们将 Power Platform 产品添加到 租户中。

Power Platform 试用许可证

由于 Power Platform 产品 是单独授权的，因此每个我们即将测试的产品都需要单独获得试用许可证。 不过，如果我们打算将大部分时间投入到 Power Apps 和 Power Automate 中，另有一种选择——Power Apps 开发者计划。 让我们仔细看看 这两种选择。

单独的产品试用许可证

在 Microsoft 365 管理中心停留，前往 帐单 | 购买服务 并寻找你想要添加的 Power Platform 产品许可证。 它们中的大多数都有可以添加到租户的免费试用。 我们可以使用右侧的搜索功能 购买服务 部分来更快速地找到产品，例如 Power Automate Premium，如下所示的 截图所示。

图 2.3 – 购买服务

接下来，点击所选产品许可证的 详细信息 按钮，这将打开一个 产品详情 页面。 如果所选产品允许添加试用许可证，则会在 开始免费试用 选项旁边显示 购买 按钮。 选择后，您将开始将许可证添加到租户的过程。 如果您在前一步中已将信用卡作为 Microsoft 365 租户的支付方式，您将能够通过点击 立即试用 按钮在 结账 屏幕上添加试用许可证。 我们可以采用相同的方法将任何其他 Power Platform 产品添加到 租户中。

图 2.4 – 确认试用许可证的订单

试用许可证通常以 25 个用户许可证为一组，非常适合在业务用户和开发人员之间进行内部分发，以测试产品功能。 试用许可证的有效期为 30 天。 试用许可证到期后，我们可以购买所需的计划以继续使用 该产品。

某些产品也 附带附加组件，例如 Power Automate 无人值守 RPA 附加组件。 这些附加组件通常依赖于独立许可证，通常称为合格的基础许可证。 一旦我们为租户添加了所需的合格基础许可证，例如 Power Automate Premium 试用版，就可以添加选择的附加组件——在这种情况下，是 Power Automate 无人值守 RPA 附加组件试用版。 我们可以在 计费 | 购买服务 部分搜索附加组件，正如我们之前所做的，或者在 附加组件 部分找到它们，位于 产品详情 屏幕中，如下图所示：

图 2.5 – 添加附加组件试用许可证

Power Apps 开发者计划

Power Apps 开发者计划 是一个免费的开发环境，可用于开发和测试业务应用程序。 它允许您使用 Power Apps 和 Power Automate 的高级功能，包括高级连接器和 Dataverse。 任何拥有 Microsoft 工作或学校帐户并连接到 Microsoft Entra ID 的用户，都可以注册此开发者计划。 我们可以通过以下网站获取 Power Apps 开发者计划 ： https://powerapps.microsoft.com/en-us/developerplan/。如果开发者拥有 Visual Studio 订阅，则可以在 Visual Studio 订阅的 Dev Essentials 网站上激活 Power Apps 开发者计划 （https://my.visualstudio.com/benefits）：

图 2.6 – 通过 Visual Studio 订阅启用 Power Apps 开发者计划

每个用户最多可以拥有 三个 Power Platform 租户中的开发环境。 开发者环境可以由管理员为用户创建，也可以由用户自行创建；但是，管理员也可以阻止用户创建此类环境 的可能性。

与期限为 30 天的试用许可证相比，Power Apps 开发者计划不会过期，并且只要该计划有任何活动，就会保持有效。 如果超过 90 天没有活动，计划将被删除。 另一个重要说明是，试用许可证带来了付费许可证的所有功能，而 Power Apps 开发者计划则不包含所有功能/能力。 此外，开发者环境不能转换为生产环境，尽管试用环境可以转换为生产环境。 开发者环境在 Dataverse 容量上也有限制，最大数据库大小为 2 GB。

开发者计划是一个完美的选择，可以在独立的开发环境中测试和构建 Power Platform 中的业务解决方案。 一旦我们对解决方案感到满意，就可以遵循 持续集成/持续部署 (CI/CD) 管道 将解决方案部署到测试和 生产环境中。

Power Platform 管理

本节探讨了 Power Platform 管理员可以使用哪些工具来配置 Power Platform 环境、管理 Power Platform 产品功能，以及如何了解不同环境中 Power Platform 产品的使用情况。 不同的环境。

除了 Microsoft 365 管理中心，管理员还应该知道另一个管理中心，帮助他们管理 Power Platform 租户。

Power Platform 管理中心 是一个统一平台，用于与 Power Platform 相关的管理任务。 它可以通过 https://admin.powerplatform.microsoft.com/ 访问，并允许管理员执行与 Power Platform 相关的大多数操作，例如一般环境管理、产品功能管理，以及获取关于 产品使用情况的分析洞察。

重要说明

需要注意 Power BI 有一个单独的管理中心，叫做 Power BI 管理中心（可通过 https://app.powerbi.com/admin-portal）访问，允许 Power BI 管理员管理其 Power BI 实例。 Power BI 管理中心不在 本书的讨论范围内。

Power Platform 为管理员提供了三种交互和管理方式——通过 Power Platform 管理中心、PowerShell cmdlet 和连接器——Power Platform 管理员和 Power Platform 开发者。

Power Platform 管理中心

熟悉 Microsoft 365 管理中心的用户会发现这个管理中心相似且易于使用。 使用 Power Platform 管理中心，管理员可以管理环境、查看关键指标和使用情况、理解并采取有关许可证和容量利用的措施等等。 这些控制项被整齐地分组，放置在管理中心左侧的导航菜单栏中，提供简洁的 用户体验。

图 2.7 – Power Platform 管理中心

一个常被忽视的功能是 帮助 + 支持 功能，允许管理员在需要 Microsoft 支持时提交支持请求。 在这里，管理员还可以查看之前提交的支持请求、其状态以及 沟通历史。

在 帮助 + 支持 中有一个方便的功能，名为 已知问题，该功能通知管理员有关 Dynamics 365 和 Power Platform 产品当前已知的活动问题。 它解释了每个已知问题，并提供了一个解决方法。 这是一个方便的方式，可以主动向管理员告知平台已知问题的状态。 除此之外，还有 Power Platform 的服务健康状况。 有关此信息可以在 Power Platform 管理中心的主页上找到，在那里我们可以找到一个 服务健康 仪表板，包含关于 Power Platform 服务的任何事件或通知的信息。

消息中心 提供有关之前和即将进行的服务更新的信息，说明它们可能如何影响用户，以及如何做好准备以尽量减少潜在影响。 有关服务健康和即将进行的计划变更的更多信息，可以在 Microsoft 365 管理中心找到。

Power Platform 管理中心还为管理员提供了设置各种 策略的可能性，从 数据丢失防护 （DLP）策略 到 计费策略。

租户设置可以通过进入 Power Platform 管理中心 | 设置来访问。这些是适用于整个 Power Platform 组织的租户级设置。 在这里，您可以配置诸如租户级分析、未分配的 AI Builder 信用使用情况和环境分配等设置。 我们将在本书后续章节中详细介绍这些设置，当我们探讨 IT 团队与 DevOps 原则对齐的重要性时。 了解哪些租户级设置可用非常重要，因为它们对用户体验有很大影响。 IT 管理员应当检查这些设置，理解它们，并为 他们的组织进行正确配置。

在 租户级别的设置旁边，我们有环境设置，可以通过访问 Power Platform 管理中心 | 环境 | 选择一个环境 | 设置来访问。 设置 按钮会在选择环境后出现在上方工具集选项中。 此 设置 部分为您提供环境设置的访问权限，包括从 产品 和 功能 配置到 审计和日志 管理，适用于所选环境：

图 2.8 – 访问环境设置

功能 配置允许我们启用或禁用 Power Platform 中通常可用的功能或预览功能。 例如，随着生成性人工智能的引入，Copilot 和其他与 AI 相关的功能现在可以提供给 Power Platform 用户，但前提是这些功能在 功能 配置中已启用。 一些新功能默认启用，管理员可以在此处禁用它们。 我们建议访问 消息中心 （可以在 Power Platform 管理中心的主页上找到），阅读微软 Power Platform 博客上的文章，或者查看 Dynamics 365 和 Microsoft Power Platform 发布计划，以 了解 Microsoft 中的新版本和即将发布的功能 Power Platform：

图 2.9 – 环境设置

Power Platform 管理和自动化，适用于管理员、开发者和开发人员

从管理员中心的图形用户界面切换到 命令行界面 （CLI），我们可以看到 Power Platform 提供了一套命令工具，用于自动化管理任务。 根据我们是否来自负责管理环境的 IT 运维团队，是否是需要管理应用的应用开发者，或者是旨在打包解决方案并自动化业务解决方案部署的专业开发者，每个人都会使用不同的 CLI 工具。

开发人员的 Power Platform CLI

Power Platform CLI (PAC CLI) 是管理 Power Platform 的首选和最推荐的 CLI 工具。 它面向开发者和管理员，提供一套命令，支持与解决方案打包、环境生命周期、代码组件、Dataverse 环境等相关的各种操作。 管理员将会发现许多便捷的命令，可以简化管理任务。 PAC CLI 支持内环和外环开发，这意味着在内环开发中，开发人员使用该 CLI 来处理解决方案，而在外环中，开发人员使用 CLI 工具确保所生产的解决方案能够部署到 其他环境中，遵循 应用生命周期管理 (ALM) 策略。

Power Platform CLI 的安装可以在 Windows、macOS 和 Linux 设备上进行。 可以通过 一个 .MSI 安装包进行安装。

首先，针对 VS， Power Platform 工具 可以 在 VS Code 内的 扩展 部分找到，或者在 VS Code 的 市场中找到。你可以在 VS Code 内使用搜索框查找该扩展，然后点击 安装 按钮进行安装。 市场也可以采用类似的方法。 请访问 https://marketplace.visualstudio.com/vscode 进入 VS Code 市场，使用搜索框查找 Power Platform 工具 扩展，然后点击 安装。该扩展由微软发布（我们可以看到已验证的发布者标记），并且是免费的。 安装完成后，VS Code 将激活该扩展，并在主侧边栏中显示。 卸载扩展在 VS Code 中进行，方法与安装类似，只需点击 卸载 按钮：

图 2.10 – VS Code 的扩展

接下来，我们还可以使用 PAC CLI，通过 使用 .NET 工具 (dotnet 工具)。 在这种情况下，工作站上需要安装 .NET（目前推荐使用 .NET 6.0 版本）。 然后可以在终端或命令提示符下使用以下命令进行安装：

 dotnet tool install --global Microsoft.PowerApps.CLI.Tool

同样的方法适用于 macOS 和 Linux。

命令目前分为 23 个组。 每个组都有其特定的用途，例如 pac admin 用于操作 Power Platform 管理员帐户， pac data 用于操作 Dataverse 组织， pac pcf 用于操作 Power Apps 组件框架项目， pac connector 用于连接器。

在我们开始使用这些命令之前，我们需要在计划运行命令的工作站上创建一个身份验证配置文件。 可以使用 pac auth create 命令创建身份验证配置文件，系统会打开一个提示框 用于输入凭证：

 # more specific auth profile creation with environment info
pac auth create --environment xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --name DevInitialAuth

为了列出选定设备上的所有身份验证配置文件，我们可以运行 以下命令：

 pac auth list

这将返回关于工作站上所有身份验证配置文件的信息。 我们可以通过提供授权配置文件的索引或名称，在它们之间来回切换： 授权配置文件：

 pac auth select --name DevInitialAuth

现在我们已经有了身份验证配置文件，可以运行 pac 命令来执行所需的任务。 为了了解 PAC CLI 中有哪些可用的命令，我们可以运行 以下命令：

 pac help

为了获得某个特定命令的详细帮助，我们只需在每个命令后添加 help 即可： 我们想要使用的每个命令：

 pac admin help
pac admin list help

命令中的帮助开关 返回一个使用示例，非常方便，特别是当我们第一次运行命令时。 以下是一个 admin 命令的示例，用于列出我们在连接的 Power Platform 组织中的所有沙盒类型环境。

 pac admin list –-type Sandbox

在接下来的章节中，我们还将使用 PAC CLI，并提供更多具体的示例。

管理员使用的 PowerShell

在PAC CLI旁边，我们有适用于管理员的 PowerShell 命令，模块名称为Microsoft.PowerApps.Administration.PowerShell，它允许我们执行一系列操作来管理 Power Platform 租户、环境以及 Power Apps 和 Power Automate 产品。

管理员的 PowerShell 模块可以通过以管理员身份运行 PowerShell 并安装必要的模块来进行安装，使用以下命令。 作为前提条件，我们应使用 Windows PowerShell 版本 5.x，并且在安装过程中，设备上应已安装 NuGet 提供程序。 如果 NuGet 提供程序尚未安装，安装过程会要求我们先安装它，然后再继续安装 PowerShell 管理员模块。 使用 PowerShell 命令的管理员需要具备以下角色之一才能操作 PowerShell cmdlet – Power Platform Administrator、Dynamics 365 Service Administrator 和 Microsoft Entra ID Global Administrator：

 Install-Module -Name Microsoft.PowerApps.Administration.PowerShell

另外，如果我们没有管理员权限，可以将作用域设置为当前用户， 针对选定设备：

 Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser

我们可能会被要求更改InstallationPolicy，确认从不受信任的存储库安装，并然后继续。

更新模块可以通过以下命令完成：

 Update-Module -Name "Microsoft.PowerApps.Administration.PowerShell"

一旦 cmdlets 安装完成，并且在我们开始执行管理 Power Platform 的命令之前，我们需要获取一个授权令牌，该令牌将与我们执行的 Power Platform PowerShell 命令相关联。 要获取令牌，我们需要调用Add-PowerAppsAccount，该命令将提供一种交互式方式，通过我们的管理员帐户登录。 如果我们的帐户 受到 USGov 或 Preview保护，我们应向 Add-PowerAppsAccount 命令添加 -Endpoint 参数，并指定 所需的端点：

 $password = ConvertTo-SecureString "securePassword" -AsPlainText -Force
Add-PowerAppsAccount -Username adminuser@domain.com -Password $password

一旦我们提供了凭证并获得了授权令牌，就可以继续运行管理员命令。 如果我们需要支持来查看可用的命令以及如何使用它们，我们可以使用一个简单的命令，Get-Help，后面跟上 cmdlet 名称，如下所示：

 Get-Help Get-AdminPowerApp -Detailed

Get-Help将下载模块的最新帮助文件，并为我们提供反馈。

重要提示

查找任务的正确命令及如何编写命令的示例，可以通过Get-Help来完成。然而，随着技术的发展，借助生成式 AI，我们现在可以更快地获得命令的答案和支持。现在，我们可以通过自然语言向像 Microsoft Copilot 这样的工具寻求帮助，完成某项任务。

所有管理员可用命令的列表可以在这里找到。

PowerShell 用于应用程序开发者

应用程序开发者有自己的模块，可以让他们管理 Power Apps 应用、Power Automate 流程，以及在流、应用和连接器之间定义的连接器和权限。

安装过程与管理员模块相同——通过以管理员身份运行 PowerShell 或定义-Scope为CurrentUser。首先，我们需要安装该模块：

 Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber

我们可能会被要求更改InstallationPolicy。确认从不受信的存储库安装并继续。

管理员的处理流程与之前相同——在运行任何命令之前，我们需要获取一个授权令牌。此操作通过Add-PowerAppsAccount命令完成，支持交互式身份验证模式；它还可以与 MFA 支持的帐户一起使用：

 Update-Module -Name "Microsoft.PowerApps.PowerShell"

所有可用的制造商命令列表可以在这里找到。

管理员和管理连接器

最后但同样重要的是，使用管理员和管理连接器的选项，它们在 Power Platform 中与其他 1,000 多个可用连接器一起随时可用。

连接器被分为五个不同的组：

• Power Platform for Admins：使 管理员能够管理环境生命周期，管理 DLP 策略，并在 指定环境中创建 Dataverse 数据库。

• Power Apps for Admins：使 管理员能够查看和设置跨 Power App 应用程序、连接器，以及连接的各种权限和所有者。

• Power Apps for Makers：允许 应用程序开发者发布他们的应用程序，并查看和管理他们的应用程序、连接器，以及连接。

• Power Automate for Admins：使 管理员能够管理 Power Automate 流程状态，通过停止、运行或删除 流程。

• Power Automate Management：允许 应用程序开发者查看和编辑他们在特定环境中有权限的流程。 此连接器还包含一些特定于管理员的操作，可以用来修改流程所有者或恢复 已删除的流程。

所有这些连接器都是标准类型的连接器，并且可以在所有地区的 Power Apps 和 Power Automate 中使用。 Power Platform for Admins 版本 2 (V2) 在公共预览中可用，您可以在 Azure Logic Apps 中使用相同的连接器。 目前它还不完全与 V1 兼容，但连接器会随着时间的推移不断更新，因此我们可以预期，在某个时刻，V2 会替代 V1。 通过使用连接器中可用的操作，管理员可以自动化重复的管理任务。 例如，管理员可以使用 Power Automate 创建自动化工作流，自动化创建 Power Platform 环境的过程，同时获得 Power Automate 产品的所有好处，比如能够查看流程 运行历史的输出。

治理、合规性和数据隐私

本节介绍了 Microsoft Power Platform 如何符合许多法规和标准，以及它如何为客户提供一套工具，以使其应用程序符合所需的法规。 它解释了 Microsoft Power Platform 如何遵循与其他 Microsoft 产品和服务相同的方法，保持合规，并遵循 Microsoft 对 客户的承诺。

微软承诺对其客户透明，展示用于确保客户数据在微软产品线中安全、合规和隐私保护的政策、操作实践和技术。 微软声明数据仍由客户掌控，并且对数据存储的位置保持透明。 微软还解释了数据在静态存储时如何保护，以及如何在传输过程中进行加密，并且最终通过其服务和部门来保护客户数据。 这样的承诺非常大胆，并为客户提供了信任感。 这些声明支持微软的 云服务 ，这些服务建立在四个基本原则之上： 安全性、隐私与控制、合规性和透明度。 安全性 专注于保护客户免受外部网络威胁。 隐私与控制 使客户能够控制对其数据的访问。 合规性 确保微软的服务符合全球标准。 透明度则是为客户提供政策和程序的洞察。

即使微软为其客户提供了所有承诺，我们仍然需要理解，云部署遵循共享责任模型。 这意味着， 根据组织使用的云服务模型类型，无论是 基础设施即服务（ IaaS ）、平台即服务（ PaaS ）还是 SaaS，不同的责任层次分别由云服务提供商和其客户承担。

Power Platform 是一个企业级 SaaS 平台，这意味着管理物理数据中心、物理网络、主机、操作系统和网络控制是微软的责任领域。 然而，客户使用的 Power Platform 产品属于共享责任模型。 在共享责任模型下，组织必须记住，它们有责任确保其最终产品的安全性，并遵守相关的法规。 需要遵守的规定。

共享责任模型的一个好例子是微软如何持续监控威胁态势，并以一种保护 Power Platform 免受 OWASP 前十名风险的方式构建 Power Platform。 OWASP 前十名 是针对有兴趣了解 web 应用安全的开发人员的标准意识文档。 微软在 Power Platform 中实施控制措施来防范这些风险，同时也为客户提供了可以在 Power Platform 或支持的服务中使用的指导和控制措施，如 Entra ID，以进一步保护他们的 Power Platform 应用免受威胁，例如破坏性访问控制、加密失败和 安全配置错误。

治理和合规性也与数据驻留领域相关。 让我们来看看微软如何处理 客户数据。

数据驻留

与其他微软服务一样，Power 平台服务托管在微软遍布全球的数据中心，并通过微软的网络基础设施进行连接，以减少网络延迟并确保数据传输的安全性。 Power Platform 客户可以在全球不同地理位置（区域）创建环境，从而将服务和数据更靠近最终用户。 这种方式对拥有全球分支机构的公司非常便利。 世界各地的公司都可以受益。

客户可以在全球各地的数据中心区域创建环境，如美国、欧洲、亚洲、澳大利亚、阿联酋、英国、日本、法国、 和瑞士。

有时，环境的位置在 Power Platform 中某些产品功能的可用性方面可能起到重要作用。 尽管功能会逐步在所有数据中心位置启用，但评估拥有一个备用测试环境的选项以验证 预览功能始终是明智之举。

对于在 以下地区运营的组织 而言， 欧盟 （EU），Power Platform 支持 欧盟数据边界 （EU Data Boundary），这是一个地理上定义的边界，帮助客户满足其数据驻留要求，将 数据驻留限制在仅限欧盟和 欧洲自由贸易协会 （EFTA）国家。

实践中数据驻留要求的一个好例子是 生成性人工智能 （GenAI）功能 在 Microsoft Power Platform 中的应用。 Power Platform 利用 Azure OpenAI 服务来实现其 GenAI 功能，但也可能发生 Azure OpenAI 服务并不位于与 Power Platform 托管的相同数据中心区域。 组织可以选择允许或禁止数据在区域之间的流动。 这意味着，如果特定功能在某个环境区域没有启用，通过允许数据流动，数据可能会流向启用了某项服务的区域。

观察托管在欧洲地区的环境，一旦启用数据移动功能，并使用 GenAI 能力，数据交易可以转移到瑞典或瑞士地区，这些地区已启用相应的服务。 这两个国家都位于欧盟数据边界内。 其他国家/地区可能有其他与 GenAI 功能相关的地理区域对。

与欧盟一起，另一项保护个人及其数据的法规是通用数据保护条例 （GDPR）。GDPR 为那些向欧盟居民提供商品和服务或收集并分析欧盟居民数据的组织引入了新规则，无论您或您的企业位于何处。 Microsoft Power Platform 为组织提供了一组服务和 功能，这些服务和功能可在接收到 数据主体权利 （DSR）请求后使用。 DSR 请求 是数据主体（个人）向数据控制者（提供服务的组织）提出的正式请求，要求数据控制者处理存储在其系统中的个人数据。 数据主体有权要求删除其数据，限制数据的处理，获取其在数据控制者系统中的数据副本等。 这意味着 Power Platform 必须为管理员提供基于 DSR 请求的能力，以查找并处理数据。

在 Power Apps 中，管理员可以使用 Power Platform 管理中心或上一节中的 CLI 命令集来查找并导出用户的数据。 例如，在 Power Apps 中，这些数据可能包括用户有权使用的应用列表、用户创建的环境、用户创建的连接或作为共享连接使用的连接，等等。

重要提示

关于欧盟数据边界和 GDPR 以及如何使用 Power Platform 中的功能响应 DSR 请求，还有很多内容可以写，我们在这里无法详细讨论。 要了解更多信息，我们建议访问 Microsoft Trust Center（https://www.microsoft.com/en-us/trust-center/product-overview），以及在 Microsoft Docs 中响应 DSR 请求（https://learn.microsoft.com/en-us/power-platform/admin/powerapps-privacy-dsr-guide）。

合规性要求

公司必须满足其商业解决方案的监管合规标准。 这就是为什么微软确保其产品和服务符合许多全球、地区、行业或美国政府特定的合规性规定。 因此，Power Platform 和其他微软在线服务实施了一个安全框架，遵循行业最佳实践，并遵守各种全球 标准，例如 国际标准化组织（ISO） 的标准，如 ISO 27000 系列标准（ISO 27001，ISO 27017，ISO 27018 等）和 系统和组织控制（SOC） ，例如 SOC 1 和 2；行业特定的 标准，如 HIPAA 和 PCI-DSS；或者与特定国家或地区相关的区域性标准，如适用于欧盟的 GDPR。

Power Platform 和其他微软在线服务会定期接受合格的第三方认证评估员的审计，以确保符合全球标准 和规定。

除了全球标准和法规外，微软通过其产品条款，之前发布了一份单独的文档，名为《在线服务条款》（OST），该文档解释了微软对客户的合同承诺，涵盖了使用微软产品的不同方面，包括关于客户数据处理和安全的隐私与安全条款及其他数据类型的条款。

任何人都可以使用微软信任中心，了解微软的产品及其如何遵循不同的安全、隐私和合规性标准及法规。

使用微软服务信任门户，客户可以调查与数据安全和合规性相关的各种文档，例如针对特定标准或法规的合规证明，或其他文档，如审核检查或对 Power Platform 产品的渗透测试。

数据保护

微软 Power Platform 具备安全策略和流程，帮助保护客户数据免受损坏、泄露和丢失的风险。这包括帮助保护客户数据免受数据泄露和数据丢失事件的机制。微软在多个层面应用安全机制并保护数据，从数据中心的物理安全到网络安全，保护静态数据和传输中的数据，并允许客户设置嵌入产品中的额外安全控制，从而进一步提升安全级别。

在微软在线服务的核心部分，包括 Power Platform 服务中，租户隔离至关重要，这就是为什么微软采取了帮助正确隔离租户的机制。微软 Entra ID 在此过程中发挥了重要作用，帮助隔离客户的租户。一旦用户完成身份验证，他们只能访问自己租户环境内的数据。

然后，用户许可证验证也随之而来。用户可以使用他们已获得许可证的 Power Platform 产品和组件。没有许可证，用户将无法访问并操作服务。

Power Platform 产品的数据存储的主要服务是 Microsoft Dataverse。 作为 Power Platform 产品的中央数据存储平台，Microsoft Dataverse 拥有三个不同的存储区域。 第一个是存储 数据，第二个是存储 日志，第三个是存储 文件。Dataverse 实现了数据静态加密和传输加密机制。 对于静态数据，Dataverse 数据库使用 SQL 透明数据加密 (TDE) 进行 在读/写操作期间对数据进行实时加密和解密。 此机制作为数据和日志文件的数据静态加密机制。 为了存储图像和文档等文件，Dataverse 在后台使用 Azure Blob 存储。 为了保护这些二进制数据，Azure 存储加密与 Azure Blob 存储一起使用。 这是一种自动加密/解密机制，采用 256 位 AES 加密。 这两种解决方案（SQL TDE 和 Azure 存储加密）都符合 FIPS 140-2 标准。

对于数据加密，使用的是 由微软管理的密钥，密钥由微软存储和管理。 那些希望获得更多数据保护控制或需要满足特定法规或合规要求的客户 可以使用 客户管理的加密密钥 (CMK) 功能。 这使得客户可以提供自己的加密密钥，该密钥由 他们的 硬件安全模块 (HSM) 生成并管理，并且该模块必须是 Azure 密钥保管库提供的受支持 HSM 之一。 另外，他们还可以使用 Azure 密钥保管库来生成和管理 加密密钥。

传输中的数据通过 行业标准传输协议进行保护，其中之一是 传输层安全协议 (TLS)。 为了加密客户端与服务器之间的消息，并确保符合安全策略以建立安全连接，使用最新的 TLS 1.2 协议，并结合一组称为加密套件的密码算法。 数据在用户客户端设备与服务之间、在 Microsoft 数据中心之间的通信中，以及在 Microsoft 数据中心内部，即使在使用 Microsoft 网络骨干时，也得到保护。 这样可以确保数据免受拦截，并确保 事务的完整性。

在用户身份验证并检查其许可证后，Power Platform 实现了一系列控制措施，这些控制措施可以进一步保护在应用程序或流程中使用的应用、数据或连接。 这些控制措施的例子包括共享应用程序、在 Dataverse 中使用安全角色来限制用户对其数据操作的访问，以及使用连接凭据来确定对 给定服务的访问权限。

我们将在 第十一章中更深入地讨论一些关于治理和安全的控制措施。

开始构建现实世界的业务解决方案

本节演示了 Power Platform 提供的一些选项和模板思路，帮助你快速入门，构建现实世界的业务解决方案。 我们将查看 Power Platform 产品中有哪些模板可用，以及有哪些其他选项可以从之前生成的设计或通过 自然语言描述的想法开始构建应用程序。

使用 Power Platform 模板创建解决方案

我们将从 模板开始。 Power Platform 产品，如 Power Apps、Power Pages、Power Automate 和 Copilot Studio，都提供了预定义的模板，帮助我们启动一个想法或业务流程。 Power Apps 拥有一份广泛的预构建应用模板列表，可以作为起点使用。 这些模板可以被采用，并对其进行额外的自定义。 在这里，我们可以找到支持业务场景的应用模板，如预定房间、提交费用报告、提交休假申请、通过帮助台助手将最终用户与支持专家连接，以及通过预算跟踪器保持项目预算。 这些都作为快速创建业务应用程序的方式。 应用模板可以通过访问 Power Apps 制作门户主页上的 从应用模板开始 来找到（https://make.powerapps.com/）。 使用这种方法有助于应用开发者快速开始构建应用程序。 由于所有这些模板都使用数据源来存储应用程序中使用的数据，一个非常重要的步骤是设置正确的数据源，并将其与应用程序正确连接。 然后，改变应用程序的图形外观可能是应用开发者的下一步操作——应用符合公司徽标和图形设计外观的图形。 图形设计。

图 2.11 – 使用应用模板创建应用程序

应用 模板还 提供了一种便捷的方式来学习如何构建 这样的应用程序，配置控件，构建业务逻辑，并在应用程序内连接和集成不同的组件。 应用程序。

类似的方法可以在 Power Automate、Power Pages 和 Copilot Studio 中找到。 在 Power Automate 中，你可以找到一组预定义的工作流，它们可以作为构建工作流的起点。 在 Power Pages 中，提供了包括网站图形设计和布局的布局模板。 拥有 Dynamics 365 许可证的用户可能会看到额外的 Dynamics 365 模板，其中包括客户自助服务、合作伙伴门户、员工自助服务和社区模板等示例。 在 Copilot Studio 中，我们可以找到构建 自定义助手的模板。

无论你选择哪个模板，都有很大概率需要实现与数据源的连接，因为许多应用程序会使用并存储数据用于 它们的操作。

企业模板

那些希望从更高级 模板入手的用户，应选择企业模板。 微软推出了一套免费的六个企业模板供使用。 企业模板可以在 Microsoft AppSource 上找到，并附有 Microsoft Learn 平台的文档，您可以在这里阅读更多关于每个模板场景的内容 以及如何实现 它（https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview）。

企业模板涵盖了六种案例，从员工认可计划、入职伙伴、奖励与认可等人力资源案例，到 IT 案例，如硬件请求和预约 预定流程。

与上一节中提到的模板一样，企业模板的目的是减少在组织中围绕某些案例构建应用所需的时间。 我们还可以使用它们来学习如何利用 Power 平台服务开发特定场景。

这些模板中的每一个都包含两个应用程序；一个是画布 应用程序 ，面向最终用户。 它是一个富含 UI 的应用程序，具有响应式布局或适配移动设备，因此也可以随时使用。 第二个应用程序是模型驱动 的，面向管理员。 它是一个数据密集型 应用程序，管理员可以在其中对数据进行管理操作，或者后台团队可以管理数据源中的所有条目。

应用程序也使用 Dataverse 作为数据源，其中创建并使用一个或多个表来 存储数据。

最重要的是，还会生成 Power Automate 流，根据 项目执行某些业务操作。

这是 Power Apps 中非常常见的应用开发方式，整个过程由 Power Automate 支持，同时数据保留在 Dataverse 中，安全角色可以应用于进一步保护数据访问 。

图 2.12 – 使用 Microsoft AppSource 获取企业模板

你可以通过访问 Microsoft AppSource，选择所需的模板，并点击 立即获取。首先，我们会被要求使用账户登录，并在继续安装前确认权限详情。 之后，我们将被重定向到 Power Platform 管理中心 | 资源 | Dynamics 365 应用，在这里我们选择要安装该模板的环境。 接受条款后，我们可以安装应用程序。 当我们想要更新或移除已部署的应用程序时，可以返回到 Power Platform 管理中心，选择环境，然后点击 Dynamics 365 应用 进行 操作：

图 2.13 – 安装企业模板

Power Platform 模式

Power Platform 项目 开发包括项目规划、设计、开发、测试和部署等阶段。 由于 Power Platform 项目的开发遵循敏捷方法论，它是一个迭代和可重复的过程。 这种方法意味着，一旦我们部署了解决方案，就可以轻松地回到项目开发的初始阶段，在那里我们设计和开发应用程序的新版本。 在接下来的章节中，我们将看看如何遵循我们的业务应用程序和解决方案的 ALM；然而，值得一提的是，许多基于 Power Platform 构建的项目遵循类似的模式。 这些模式包括审批、资产管理和检查应用程序。 微软将它们整合在一起，并创建了一个列出所有已识别 Power Platform 模式的清单，包括每种模式的模板解决方案及其安装文档。

这些模式 与模板可以在 此处找到： https://learn.microsoft.com/en-us/power-apps/guidance/patterns/overview。

每种模式都有其独特的目的；然而，从技术角度来看，它们通常由一个或多个 Power Apps 应用程序、中央数据存储（例如 Dataverse、SQL 数据库或 SharePoint Online）以及支持业务流程的 Power Automate 流程组成。 某些模式还包括 Power Pages，用于用户前端体验，而不是 Power Apps 应用程序。

构建业务解决方案的其他方式

让我们来看几种不同的方式来构建一个 业务解决方案。

从对话中创建

Power Platform 使你能够通过与 Copilot for Power Platform 的自然语言对话来创建业务解决方案。 Copilot 可在所有产品的主页上使用，例如 Power Apps、Power Automate、Power Pages 和 Copilot Studio。

描述我们想要创建的应用程序类型非常简单，AI 会尝试理解我们描述的上下文，并帮助我们构建应用程序。 它不仅帮助我们创建应用程序，还能帮助我们设计应用程序将使用的数据表模式。 将使用的数据表模式。

在 第十二章中，我们将深入探讨 Copilot for Power Platform 及其功能。 深入了解。

图 2.14 – 从对话中创建应用程序

从设计（图像或 Figma）创建

了解用户如何与数据交互有助于我们构建应用程序的概念设计。 概念设计帮助我们确定应用程序中将执行哪些任务。 这使我们能够绘制一个简单的画布应用程序屏幕或 Power Pages 表单的表示。 在画布应用程序中，Power Apps 允许我们将纸上绘制的应用程序屏幕草图转换为应用程序或表单。 这个 Power Apps 功能将我们的草图转换为功能性屏幕，并从草图中识别出组件。 我们还可以使用 Figma 和 Figma 中的画布应用程序 功能。

Figma 是一个 用于界面设计的协作网页应用程序。 它允许每个人创建应用程序的用户界面和原型。 Microsoft Power Platform 提供了一个 Figma UI 套件，允许我们直接从 Figma 创建 Power Apps 应用程序 ：

图 2.15 – 从图片或 Figma UI Kit 创建画布应用

客户故事

微软在他们的 Power Apps 客户案例网站（https://powerapps.microsoft.com/en-us/blog/power-platform-stories/）上有一 个汇总的真实客户故事列表，任何人都可以阅读，了解客户面临的挑战以及他们如何通过构建解决方案来解决问题，使用的正是微软 Power Platform。

2020 年，微软宣称 97% 的《财富》500 强公司以多种方式使用微软 Power Platform。 毫无疑问，我们可以看到该平台的受欢迎程度正在不断攀升，这也是我们相信越来越多的真实世界案例将被记录并与更广泛的社区分享的原因，从而让人们从中学习并应用这些案例来解决他们 自己的挑战。

尽管并非所有客户故事都对外公开，但公开的那些给我们提供了宝贵的洞察，了解客户为何决定使用这项技术，我们也可以了解到他们是如何 实施解决方案的。

摘要

本章介绍了 LCNC 开发方法的兴起以及它在近年来获得的关注。 我们希望本章能帮助你理解为何意识到这种开发方法如此重要，它的好处是什么，以及它与经典软件 开发方法的区别。

我们简要介绍了 Power Platform 的主要组件，并重点讲解了如何开设试用账户。 这应该有助于你了解如何开始使用该平台，因为接下来的章节将专注于实践活动，而准备一个测试环境以便 跟随操作是非常重要的。

接下来，我们介绍了管理 Power Platform 的工具，从管理中心到不同的 CLI 工具，PAC CLI 是首选工具，还有各种连接器可以帮助自动化管理任务。 无论你是 IT 管理员、DevOps 工程师还是专业开发人员，都很有可能在开发或管理 解决方案时，使用一个或多个这些工具与 Power Platform 配合。

本章节的最后两个部分专注于理解如何保持平台的安全性和符合不同标准及法规的要求，以及如何利用 Microsoft 公共网站发布的各种模板和模式。 这将帮助你建立对平台的信任，并加速你的初始项目设置，使用现有的模板（至少是前几个 项目）。

在下一章节，我们将运用 Power Platform 的知识，探讨为什么 ALM 和 DevOps 对 Power Platform 项目至关重要。 我们还将深入了解 Power Platform 采用成熟度模型，以及它如何帮助组织评估当前的成熟度水平并改善 DevOps 过程。

进一步阅读

• Microsoft Power Platform 博客： https://www.microsoft.com/en-us/power-platform/blog/

• Dynamics 365 和 Power Platform 发布 计划： https://releaseplans.microsoft.com/en-US/

• Power Platform 管理员 文档： https://learn.microsoft.com/en-us/power-platform/admin/

• Power Platform CLI： https://learn.microsoft.com/en-us/power-platform/developer/cli/introduction

• PowerShell 支持管理员和 开发者： https://learn.microsoft.com/en-us/power-platform/admin/powerapps-powershell

• 管理员和管理 连接器： https://learn.microsoft.com/en-us/connectors/powerplatformforadmins/

• Microsoft 信任 中心： https://www.microsoft.com/en-US/trust-center

• Microsoft 产品 条款： https://www.microsoft.com/licensing/docs/view/Product-Terms

• Microsoft 企业 模板： https://learn.microsoft.com/en-us/power-platform/enterprise-templates/

• Power Apps 模式： https://learn.microsoft.com/zh-cn/power-apps/guidance/patterns/overview

• Power Platform 故事： https://powerapps.microsoft.com/zh-cn/blog/power-platform-stories/

第三章：探索 Microsoft Power Platform 中的 ALM 和 DevOps

Microsoft Power Platform 使用户能够以更简单、更快捷的方式创建业务应用程序，这对于任何人来说都是具有吸引力的，无论其开发技能如何。 一旦我们超越了个人生产力应用程序的创建，并开始自动化具体的业务流程，我们就需要开始规划如何为这些新构建的应用程序设置最佳的生命周期模型，以便在 组织中进行管理。

客户案例帮助我们理解，一旦组织采用了 Power Platform，组织中生产的应用程序数量很可能会大幅增加。 组织应该有一个计划，来处理如何构建、部署、管理和维护这些应用程序。 这就是 应用生命周期 管理 (ALM) 的作用所在。 然而，这不仅仅是关于开发人员的事情。 IT 专业人员和安全工程师必须与开发人员沟通，确保他们参与到规划、创建、管理和监控应用程序运行环境的过程当中。 这就是为什么 将 ALM 与 DevOps 结合扩展对于 低代码/无代码 (LCNC) 开发方法来说也非常重要。

在本章中，我们将继续在前几章的基础上，解释为什么 LCNC 项目应该使用 ALM 和 DevOps，以提高整体协作和质量保证。 在探索 ALM 如何帮助我们构建应用程序后，我们将深入探讨应用现代化的话题，因为组织通常有许多现有的遗留应用程序，这些应用程序应该进行评估并决定其未来。 本章的最后，我们将了解 Power Platform 采用成熟度模型如何与 ALM/DevOps 和应用现代化相关联，以及为什么提高组织的成熟度水平至关重要。 在组织中。

在本章中，我们将涵盖以下 主要主题：

• 为什么在 Power Platform 中实施 ALM 和 DevOps？

• 通过 LCNC 方法进行应用现代化

• 构建 Power Platform 采用之旅

为什么在 Power Platform 中实施 ALM 和 DevOps？

本节 探讨了为什么像微软 Power Platform 这样的 LCNC 平台需要实施 ALM 流程，以及它将如何改善团队协作、提高质量保证并帮助减轻 潜在风险。

在采纳的初期阶段，我们可以看到组织将 Power Platform 服务提供给 他们的 公民开发者。公民开发者是指在组织内部不具备传统编程技能的个人或员工，他们通常来自业务部门，而非 IT 或开发团队。 他们使用 Power Platform 主要为自己构建业务应用程序，以提升个人生产力，并且不对 使用方式施加严格的指导。

随着组织的成熟，对 Power Platform 的认识和知识逐渐增加，开始构建更复杂的项目时，他们会寻求可扩展、一致、稳定且安全的构建和维护业务应用程序的方法。 这与理解 ALM 的重要性直接相关，ALM 为如何共同治理、开发和维护应用程序提供了实践。 采用 ALM 方法来构建应用程序可以对开发速度、可靠性和最终 用户体验产生积极影响。

在谈到 开发速度时，我们需要提到 ALM 提供了一个框架，旨在使用允许多个贡献者同时在应用程序上进行工作的平台。 这时版本控制工具就显得尤为重要。 由于如今许多工具，如 Azure DevOps 和 GitHub，提供了一个单一平台来覆盖 ALM/DevOps 生命周期，我们可以通过实施自动化构建、测试和部署管道，利用 CI/CD 流水线提高开发速度。 然而，我们也可以通过改进开发方式来提高交付时间。 构建可重用的代码组件可以让我们在不同项目中复用这些构建块，从而节省开发时间。 在可靠性方面，由于我们已经建立了版本控制系统，我们有可能将系统回滚到之前的版本，因为在开发过程中错误是难以避免的。 拥有这一能力可以增加我们维持系统稳定性的选择。 前面提到的 CI/CD 流水线将帮助我们确保应用程序在不同环境中持续部署，从而最大限度地减少配置漂移和 意外行为。

最后，拥有一个 无 bug 的应用程序在塑造用户体验中起着重要作用。 实施持续自动化测试将帮助我们在流程早期发现潜在问题。 通过自动化测试，我们还可以查看潜在的性能瓶颈。 这有助于我们去除或优化这些问题，从而提高性能，并最终改善 用户体验。

每当我们在考虑 Power Platform 中的应用生命周期管理时，我们会集中关注两个主要概念： 解决方案 和 环境。我们在项目中开发的所有内容，作为业务解决方案的一部分，无论是画布应用、流程、Dataverse 表格还是自定义组件，都作为一个 解决方案组件呈现。这些解决方案组件被添加到一个解决方案中，并且我们应用 ALM 过程，使得能够自动化地将解决方案导出和导入到不同的环境中。 环境充当一个容器，隔离我们租户中的内容，并允许目标受众的分离。 解决方案和环境这两个概念可能对于 IT 专业人士、专业开发人员和 DevOps 工程师来说是非常熟悉的。 这是因为在传统的软件开发中，也使用类似的方法，其中应用程序被打包成一个包（在 Power Platform 的上下文中是解决方案），并部署到不同的目标环境中，如开发环境、测试环境、预生产环境和 生产环境。

解决方案和环境的概念将在 第四章中详细描述。Power Platform 中的 ALM 只是故事的一部分。 许多人认为 ALM 仅仅是将解决方案部署到不同环境的过程，但实际情况远不止于此。 我们应该将其与 DevOps 结合，并考虑实施额外的步骤，例如构建环境管理策略、自动将 Power Platform 资源打包成解决方案、保障和管理环境，以及最后，在确保所生成的工作经过适当测试的情况下，一致地自动部署到不同环境。 Power Platform 上的 DevOps 不仅关注应用开发者和专业开发者，还着眼于帮助 IT 管理员构建强大的平台和 IT 运营（IT ops）流程，这些流程使我们能够自动化平台特定任务，如环境配置、平台管理、DLP 政策管理、审计等。 许多时候，商业应用扩展超出了 Power Platform，因此 IT 运营团队还需要负责网络管理，例如在配置 Power Platform 与 Azure 服务或其他本地后端系统的集成时。 后端系统。

正如在 第一章中提到的，ALM 是一个将软件开发多个阶段以循环方式连接起来的软件开发过程。 现在，让我们从一个更高的视角来看看这些阶段在 Power Platform 中的意义。

计划和跟踪

我们在开始开发项目之前，需要做的第一件事是进行充分的项目准备和规划， 我们可以通过进行一个 需求研讨会 流程来实现。 这有助于我们理解项目的目标和范围。 它让我们开始为这个阶段构建成果。 这个步骤需要提出有效的验证问题，帮助我们理解目标和项目范围。 理解项目范围有助于我们了解可用的时间表和资源，包括预算。 它还让我们可以进行可行性研究，以确定是否存在一些我们应当注意的重要障碍。 一旦我们理解了项目的范围，就可以继续收集所有的功能需求并优先排序。 然后使用 四象限法：

图 3.1 – 四象限法

接下来，我们将 识别与所选项目相关的所有团队成员，并为他们分配 各自的角色。 指定的敏捷方法论，如 Scrum，已经有预定义的角色及其相应的任务，当我们将角色分配给团队成员时，可以参考这些方法论。 这将帮助我们在项目规划工具中将团队成员分配到定义好的任务和用户故事中。 使用所选的项目规划工具，我们将把工作项类型与我们将在项目中使用的方法论对齐，并开始创建工作项，如用户故事和任务，并根据项目进度和责任人进行映射。 团队成员。

从项目规划的角度来看，这也是一个我们应当定义和构建环境设计、定义数据战略并开始进行数据建模的阶段。 在这里，我们正在进行项目架构设计。 安全团队还应该开始进行威胁建模，以识别潜在威胁，并通过调整架构设计（无论是物理的还是逻辑的）来减轻这些威胁。 最后，为了解决用户体验部分和功能请求，我们可以从应用程序故事板或线框图开始。 或线框图。

如我们所见，在 ALM 的第一阶段，我们甚至可能还没有接触到 Power Platform 服务。 相反，我们将专注于与项目规划相关的活动。 我们可以通过 项目规划工具来支持这个阶段，比如 Azure Boards （Azure DevOps），它内置了项目规划功能。 它允许我们通过工作项定义项目，并随着时间的推移计划和跟踪已完成的工作。 时间进展时。

在这里，我们还将决定我们的战略，这将影响下一阶段——我们的分支策略。 我们还将决定是使用单一仓库还是 多仓库方法。

开发

开发阶段是应用开发人员和专业开发者合作，按所使用的方法论和项目计划中的一系列冲刺实现已定义任务和用户故事的阶段。 根据项目的不同，在这一阶段我们将使用 Power Platform 服务来开发我们的业务应用程序、流程、定制协助工具和网站。 为了支持这一阶段，我们将启用并将项目与版本控制系统连接。 版本控制系统通过保存代码的快照来保护开发团队，让他们能够恢复到之前的版本。 它还通过为开发人员提供一种简单的方式来识别并系统地解决代码冲突，保护他们免受可能出现的并行开发冲突。 这种系统的一个例子是 Azure Repos，它是 Azure DevOps 的一部分，或者是 GitHub 仓库。

即使我们已经从规划和跟踪阶段转向开发阶段，但这一阶段以及生命周期中所有后续阶段仍然依赖于第一阶段，因为我们将继续使用选定的项目规划工具，如 Azure Boards。 这些工具将帮助我们跟踪工作项的状态并相应地更新它们。 我们还使用 Azure Boards 与其他项目成员合作，通过交换想法和评论来共同处理工作项。 工作项。

开发 任务是在 Power Platform 服务和 集成开发环境 (IDEs) 中完成的， 例如 Visual Studio Code。

作为 Power Platform 服务中协作的一个例子，我们可以提到 Power Apps 支持在模型驱动应用中进行协同创作，并且即将在画布应用中支持这一功能，这使得多个开发者能够同时在应用中进行更改，并且他们的更改实时反映给其他人。 然而，并不是所有服务目前都支持相同程度的协同创作体验；因此，为了缓解代码优先开发者与公民开发者之间的协作挑战，微软推出了 Power Platform Tools 扩展，这在 前一章中已提到。

与 DevOps 一样，我们努力自动化手动任务。 在这一阶段，我们将开始构建 CI/CD 流水线，帮助我们自动化构建、测试和部署过程，这将在 DevOps 的下一个阶段中完成。 自动化的 CI/CD 流水线是在 DevOps 工具中构建的，并配备有 Power Platform 中自动化任务的工具。 这些工具的例子包括 Power Platform Build Tools、 Power Platform CLI (PAC CLI)， PowerShell cmdlets。

构建和测试

一旦 必要的功能已开发完毕或问题已解决，且开发人员准备好进入下一个阶段，他们需要启动一系列任务，将完成的工作构建并打包成一个准备好部署到 目标环境的解决方案。

DevOps 中的最佳实践之一是 尽可能地实现自动化。 在 持续集成 (CI) 流水线中，我们定义了构建和测试解决方案所需的任务。 对于此任务，我们可以使用 CI/CD 工具，例如 Azure DevOps，它本身内置了 Azure Pipelines 功能。 或者，我们可以使用 GitHub Actions，它是 GitHub 产品的一部分。

每当工作提交到代码库时，CI 流水线可以自动触发。 这减少了启动过程时对人工干预的需求。 该过程由系统自动开始。

在我们的 CI 流水线中，我们已经放置了一系列使用 Power Platform Build Tools 或 PAC CLI 来执行 必要操作的任务。

我们不能不提测试。 在继续到下一个阶段之前，应该在这里进行一组适当的测试。 Azure DevOps Pipelines 或 GitHub Actions 使我们能够在 CI 流水线期间自动运行测试。 例如，使用管理员和开发人员的 Solution Checker 或 PowerShell cmdlets，特别是 Microsoft.PowerApps.Checker.PowerShell 模块，我们可以将解决方案检查器功能集成到 CI 流水线中。 这种方法允许开发人员在构建验证过程中实施静态分析检查，并在开发过程中识别出问题模式。 从这里开始，我们可以使用 Power Platform 中的其他测试工具，如 Power App Test Studio 或 Power Apps Test Engine，来构建 Power Apps 中的端到端测试。

作为 此阶段的结果，使用我们提到的工具，我们已经生成了一个构建工件。 工件是构建过程的副产品，在 Power Platform 的背景下，它将是一个打包的解决方案，其中包含已添加到解决方案中的所有组件。 这将在接下来的 部署阶段中使用。

部署

既然我们 在前一个阶段的结果中有了一个工件，我们可以专注于将其部署到必要的环境，并在那里运行额外的测试，如集成、性能、安全和 UI 测试。 与 前一个阶段一样，持续部署 (CD)**旨在自动将解决方案部署到各种环境，包括生产环境。 通过使用 DevOps 工具和 CD 流水线，再加上 Power Platform 构建工具，我们可以确保部署过程 得到自动化。

此过程中的一个重要步骤是为解决方案准备好环境。 这涉及遵循环境策略并按照组织定义的治理准则行事。

环境准备就绪后，我们可以遵循协商一致的部署策略。 此策略定义了我们如何向用户交付应用程序。 存在各种部署策略，如蓝绿部署流程、A/B 测试、金丝雀发布等。 所有这些部署策略的目的都是以受控的方式将更新的应用程序提供给一组用户，以便分析不同的指标，如性能、用户行为、功能影响等。 作为实际部署策略的示例，我们可以采用蓝绿部署策略，并使用应用程序共享选项向一组用户引入新功能。 向多个用户或组共享的过程可以通过 CLI/cmdlets 自动化 完成。

由于部署有时可能不如预期，我们应该准备好回滚策略，以防在部署或 测试阶段出现任何问题。

在此阶段，我们还可以执行与数据相关的任何活动，例如将测试数据导入 Dataverse 表格或为测试环境提供新表格，并从不同环境中复制数据 使用数据流。

操作

此阶段的 目的是确保系统的 可用性 以及部署解决方案的稳定和健康状态。 由于 Power Platform 是一项 SaaS 解决方案，IT 管理员无法控制运行服务的基础设施，这就是他们必须依赖 微软来保持系统正常运行的原因。 服务水平协议 (SLA) 描述了微软对正常运行时间和连接性的承诺。 然而，事情会发生，为了验证服务的状态，IT 管理员可以在 Power Platform 管理中心的 服务健康 仪表板中验证当前状态。 在这里，他们可以看到是否有任何正在进行的服务降级或未来的 计划中断。

一套工具，比如在 Power Platform 管理中心或 卓越中心 (CoE) 启动工具包，帮助 我们了解环境和部署解决方案的状态。 通过将我们的应用程序与应用程序性能监控解决方案，如 Azure Application Insights，连接，我们可以收集并分析健康、性能和使用数据， 覆盖应用程序。

此外，在此阶段，我们可以控制新开发的功能和应用程序对最终用户的暴露。 通过功能标志和商定的部署策略，我们可以验证开关的功能，并确保用户能够按设计访问特定 用户组的功能或服务。

监控和学习

连续 DevOps 生命周期的 最后阶段旨在确保监控工具到位，并为我们提供可以用来 分析使用情况和性能 的业务应用程序的遥测数据。 这些信息帮助我们学习并改进当前的 DevOps 流程。 它能为我们提供洞察，帮助判断是否需要构建更好、更具吸引力的 应用程序。

除了其他方面，DevOps 还关注特性功能的持续交付。 如果我们使用特性标志，允许对新功能的启用进行精细控制，那么必须有一个监控服务来捕获或收集新功能的使用信息。 这可以通过向 Azure 应用程序洞察发送自定义遥测数据来完成。 Azure 应用程序洞察是 Azure 监控的扩展，最初用于监控不同环境中的应用程序。 它允许我们了解性能和用户流，创建针对存储在日志分析中的日志的自定义查询等等。 通过创建警报，我们可以对性能或使用中的异常进行响应。 正如我们所看到的，通过收集用户遥测数据，我们可以了解应用程序的使用情况，以及我们是否根据 用户的需求投资构建正确的功能。

然而，需要注意的是，这一阶段并不仅仅关注理解来自用户的遥测数据。 在此阶段，我们的项目和开发团队还需要反思已完成的工作，诚实地回答 ALM 流程中哪些部分有效，哪些无效。 这种方法将帮助他们在过程中不断学习和成长，并在方向错误时进行修正。 所学的经验将反馈到 ALM 中，并用于下一个迭代周期。 持续学习和持续改进展示了我们对优化流程和为用户交付有价值产品的承诺。 考虑到这一点，让用户向开发团队提供反馈可以解锁有关如何使应用程序对用户更有意义的宝贵信息 。

从 工具的角度来看，团队将利用 Power Platform 内的分析功能以及 Azure 应用程序洞察。 团队还将使用项目规划工具，如 Azure Boards，来调查流程和团队表现中的瓶颈。 通过 Power BI 仪表板和报告，可以直观地展示 并进行调查。

我们已经提到了一些可以支持 ALM 和 DevOps 流程的工具。 在下一部分，我们将更深入地了解本书中将使用的两个工具的功能 以便进行动手操作。

ALM 和 DevOps 工具

市场上有许多不同的工具可用于管理 ALM/DevOps。 有些工具仅设计用于覆盖 CI/CD 过程，而另一些则构建成涵盖整个 DevOps 过程，包括项目规划、构建、管理测试场景等工具。 从生产力和集成的角度来看，拥有一个可以在整个应用程序生命周期管理过程中使用的工具总是一个不错的选择。 我们将深入了解微软提供的两个最重要的支持 ALM 和 DevOps 的工具：Azure DevOps 和 GitHub Enterprise。

Azure DevOps

Azure DevOps 有着与微软开发者密切相关的悠久传统。 这一切始于一款名为微软 Team Foundation Server (TFS)的产品，该产品于 2006 年初发布。 TFS 是一个用于管理开发项目配置工作流的协作工具。 顾名思义，它是一个客户必须部署到其本地环境中的服务器产品。 随着世界的发展以及云计算的兴起，微软开始寻找将 TFS 转变为 SaaS 产品的途径。 2011 年，TFS 作为 SaaS 解决方案在 Windows Azure 平台上推出。 它被命名为 TFS。 后来，它被 更名为 Visual Studio Team Services (VSTS)。 2018 年，微软将 VSTS 重新命名为 Azure DevOps 服务，同时也将 TFS 更名为 Azure DevOps Server。 Azure DevOps Server 2019 是首个重新命名后的本地版本。

由于一些组织尚未采用云战略，或者在受监管的行业中运营，Azure DevOps 仍然提供两种版本，以便客户可以根据自己的需求选择最适合的产品版本——Azure DevOps 服务或 Azure DevOps Server。 有时，客户可能会遇到需要混合配置的复杂环境。 在这种情况下， 构建代理 可以位于本地服务器上，用于 CI/CD 管道，同时仍然使用 Azure DevOps 服务在线的其他功能。 这是可能的，而且是一个非常常见的场景。 它解决了特定客户的需求，这些需求通常与法规有关，但也可以用于其他 技术原因。

Azure DevOps 包含 五个服务，支持 ALM/DevOps 流程：

• Azure Boards：用于项目规划和工作跟踪，提供看板、待办事项和 团队仪表板。

• Azure Repos：专注于提供私有 Git (以及较早的 Team Foundation 版本控制 (TFVC)) 仓库。 支持分支和 拉取请求机制。

• Azure Pipelines：专注于为任何项目构建 CI/CD 管道，支持任何语言，并可部署到任何平台。 由构建代理组成，构建代理是执行在 Azure Pipelines 中定义的操作的组件。 代理可以是微软托管的，当使用 Azure DevOps 服务时，或是自托管的，当在本地配置 Azure DevOps Server 时。 两者的组合，也可以作为混合设置。

• Azure Test Plans：旨在构建测试场景，以支持手动和 探索性测试。

• Azure Artifacts：作为一个包管理功能，允许用户从公共和 私有源创建和分享 NuGet、Maven、npm、Python 和通用包源。

Azure DevOps 非常可扩展。 通过扩展，管理员可以增强 Azure DevOps 的功能。 扩展可以通过 Visual Studio Marketplace（https://marketplace.visualstudio.com/azuredevops）找到并安装，那里有 Azure DevOps 服务和 Azure DevOps Server 的扩展。 Microsoft Power Platform 构建工具是这些扩展的一个例子，我们将使用它来支持 ALM 流程。

Azure DevOps 还支持 REST API 集成，用于自动化任务和与其他系统及应用程序的集成。 IT 管理员或 DevOps 工程师还可以利用 Power Platform 中的 Azure DevOps 连接器，这使他们能够对 Azure DevOps 中的项目执行操作，如创建新版本、创建新工作项或仅查看 项目状态。

GitHub Enterprise

GitHub 成立于 2007 年，GitHub 服务于 2008 年 2 月推出。 2018 年 6 月，微软宣布收购 GitHub。 这次收购也强调了微软对开源社区的承诺。

GitHub 提供不同的定价计划，根据计划解锁不同的产品功能。 GitHub 的计划旨在适应个人、小型团队，甚至更大的组织：个人或组织可以使用 GitHub Free，个人帐户可以使用 GitHub Pro，而大型公司则可以选择 GitHub Team 或 GitHub Enterprise。

GitHub Enterprise 是功能最丰富的选项，适用于大规模开发项目。 从功能角度来看，它与 Azure DevOps 类似，但也有一些区别。 与 Azure DevOps 一样，GitHub Enterprise 也有两种变体，分别是 作为云服务的 GitHub Enterprise Cloud，或者作为本地实例的 GitHub Enterprise Server。 这为客户提供了灵活性，选择如何部署和使用该工具。

与 Azure DevOps 类似，GitHub 产品旨在覆盖 DevOps 生命周期的所有阶段，具有以下功能：

• GitHub Issues 和 GitHub Projects：用于计划和跟踪项目中的工作。

• GitHub 仓库：专门用于提供私有或公共 Git 仓库，用于存储和协作项目中的源代码和文件。 支持分支和拉取请求机制。

• GitHub Actions：专注于提供支持 CI/CD 的平台，用于自动化构建、测试和部署流水线。 GitHub Actions 允许 DevOps 工程师扩展 CI/CD 流水线以外的任务，并根据仓库中的活动自动化项目中的其他任务。 GitHub Runners 是运行 CI/CD 流水线的关键组件。 它们执行 GitHub Actions 中定义的活动。 与 Azure DevOps 相比，它们类似于构建代理。 GitHub 还提供 GitHub 托管的运行器，或者可以在本地环境中部署的自托管运行器。

• npm、NuGet、Maven，等等。

GitHub 在其产品组合中拥有一套旨在增强开发者体验、改善 DevOps 过程中的协作，并实施 DevSecOps 的工具。 这些产品越来越受欢迎，值得一提的是： 这些工具包括：

• GitHub Codespaces：允许 开发人员快速提供一个安全的云开发环境，为选定项目配置。 这意味着它包含必要的开发工具，如 Visual Studio Code 和所有必需的扩展，帮助开发人员更快地开始项目开发。

• GitHub Copilot：这是 一个 AI 编码助手，通过提供基于 AI 的实时代码补全建议，帮助开发人员编写代码。 有关 Microsoft Copilot 的更多信息将在本书的最后一章中介绍。

• GitHub 高级安全：提供 额外的工具，进一步保护项目的安全。 通过代码扫描、密钥扫描和依赖项审查等功能，GitHub 高级安全使组织能够在开发周期中提前进行安全检查。 代码扫描让我们可以发现源代码中潜在的安全漏洞和编码错误。 密钥扫描会扫描我们的源代码，寻找任何可能被开发人员和 IT 工程师无意中提交到代码中的密钥和令牌等机密信息。 最后，依赖项审查使我们能够查看项目中使用了哪些依赖项，并检查项目所用版本是否存在已知漏洞。 GitHub 高级安全还可以与 Azure DevOps 一起使用。

现在我们已经 了解了 DevOps 生命周期阶段和支持 DevOps 生命周期的工具，我们准备深入探讨具体的现代化选项。 在决定将应用程序从现有技术栈迁移到 LCNC 平台时，我们将考虑可用的现代化策略。

LCNC 方法的应用程序现代化

在这一 部分，我们将重点讨论通过 Power Platform 进行的应用程序现代化。 我们将讨论不同的应用程序现代化策略选项，以及 LCNC 开发方法如何作为现代化应用程序的选项之一。

组织 现在，比以往任何时候都面临一个挑战，他们需要以快速的速度创新，以在市场上建立竞争优势。 拥有一堆构建在过时技术栈上的遗留应用程序，使其与现代系统集成的可能性变得更加复杂。 这类应用程序往往因为技术过时和难以 维护而存在潜在的安全威胁。

过时的技术也会在人员配备方面带来挑战，因为可能很难找到愿意继续使用旧编程语言和框架以及老旧开发工具进行开发的开发人员。 另一方面，维护现有的遗留应用程序可能会导致技术债务 显著增加。

因此，组织正在考虑现代化遗留应用程序的可能性。 Power 平台的 LCNC 开发方法允许组织加速交付新应用程序，减少开发成本，并通过允许公民开发人员参与流程来扩展资源池，并最小化对大量 定制编码的需求。

遗留应用通常没有我们可以连接的 API。 通过 Power Automate，Power 平台允许组织实施 机器人流程自动化 (RPA) 进程，这些进程 模拟用户与遗留应用程序的交互。 它允许他们将这些流程插入到新的现代业务流程和 云流中。

当现有应用程序公开 API 时，我们可以专注于为应用程序构建新的前端，并使用自定义连接器连接到后端 API。 这些用于执行特定操作，如数据库操作或功能逻辑。 这两种方法都允许我们以较小批次的迭代方式逐步现代化遗留应用程序，在进行现代化过程中启用功能。 这种 逐步现代化应用程序的方法 也有助于在不干扰 业务运营的情况下现代化组织高度依赖的应用程序。

Power Platform 可以与 Microsoft Azure 集成。 这使得已经采用 Microsoft Azure 云服务的组织能够以 LCNC 开发方式构建新应用或扩展现有应用，并简化 Power Platform 服务的采用。 由于 Power Platform 通过连接器支持与许多服务的集成，因此它也适用于现有应用的现代化。 第九章 将讨论 Power Platform 与 Microsoft Azure 之间的集成场景，希望能够为 应用现代化提供新思路。

已经采用融合开发方法的组织在进行应用现代化时将受益匪浅，因为这种方法允许专业开发人员、应用创建者和 IT 运维团队专注于他们在应用现代化过程中各自的角色。 我们将在 第九章 中进一步讨论 该方法。

应用现代化选项

在决定 现代化遗留应用的战略时，我们应该考虑应用现代化的不同选项，以便做出有根据的决策。 组织不应仅仅将遗留应用重写为使用更现代的框架和语言。 相反，他们还应该审查和更新使用的流程和数据库。 遗留应用是基于当时可用的技术开发的，同时也围绕适合当时的流程进行。 那个时候，同一个项目现在可能会与当时遗留应用开发时的方式完全不同。 现有的技术可能在当时并不存在，而我们今天能够交付的流程也可能与当时的完全不同。 现在我们正处于更广泛采用 AI 的时代，因此我们应该探索通过 AI 优化流程和创新的方式。 曾经手动完成的工作，现在有可能通过 AI 的帮助完全实现自动化。 因此，在处理应用现代化时，我们应该从流程优化和现代化的角度看待现代化——包括应用 和数据库。

流程现代化

我们应该首先 从 流程现代化 开始，以便能更多地从实际应用中受益 现代化和数据库现代化的过程。 流程现代化包括评估现有流程，以便了解我们可以在哪些方面进行改进。 然后我们可以继续优化和重新设计现有的业务流程，并利用现代技术的能力使其与现代时代相适应。 这个过程的结果是现代化和优化后的流程，在分析过程中识别出了瓶颈，并通过自动化在一定程度上或完全消除了这些瓶颈。 这使我们能够获得操作效率，从而降低现代化工作负载的总拥有成本。 现代化的工作负载。

Power Platform 有一个名为 Power Automate 流程挖掘的产品。 Power Automate 流程挖掘是一个可以帮助我们发现、监控和改进流程的产品。 在 2024 年 5 月，微软的流程挖掘解决方案被评为 2024 年 Gartner® 魔力象限™ 流程挖掘平台的领导者。 流程挖掘平台。

我们不应忘记提到，流程现代化的一个关键部分是组织文化和人员，而不仅仅是技术。 现代化不仅仅是关于技术，它是一种思维方式的转变，涉及到组织中每个人都参与到这一变化中，从领导层到一线员工。 接下来我们将探讨 Power Platform 采纳成熟度模型如何帮助我们实现这一目标。 下一部分将详细讲解。

应用现代化

应用程序现代化是一个 将软件应用程序更新以与技术进步对齐，满足当前业务需求，并改善用户体验的过程。 如今，在许多情况下，应用程序现代化与迁移到云端密切相关，但不仅仅是这样。 类似于流程现代化，它需要全面审视应用程序的状态，以改善用户体验，使应用程序更安全、更可靠、兼容更新的技术栈等。 应用程序现代化的一个好处是能够加速创新。 Power Platform 使我们能够做到这一点。 使用一个可以快速原型设计以及实际开发应用程序的平台意味着组织将有更多时间进行创新。 通过将 DevOps 或 DevSecOps 整合到整个过程中，我们还可以提高市场响应速度，同时保持我们的 应用程序安全。

在开始现代化应用程序之前，组织应该首先进行 应用程序合理化。这 将帮助他们了解他们的应用程序组合中有哪些应用，以及应该如何处理它们。 在识别了整个组织的所有应用程序之后，我们应该对这些应用程序进行评估。 这不仅将帮助我们建立一个应用程序清单，还能深入了解每个应用程序的情况。 这种评估可以通过手动或使用特定工具自动进行。 在这里，我们将查看应用程序的架构、应用程序依赖关系、基础设施架构、用户分析和使用模式，包括应用程序的使用频率，更重要的是，应用程序上次使用的时间。 许多时候，客户尝试现代化或迁移所有 应用程序，但实际上可能没有必要这样做，因为某些应用程序已经多年未使用。 在这种情况下，为审计目的保留数据可能就足够了，同时可以停用 这些应用程序。

一旦应用程序评估完成并且应用程序清单建立，我们应该决定应用程序的 现代化策略。

在 2011 年，Gartner 提出了 五个 R 迁移战略 five Rs migration strategy ，帮助我们将应用程序划分为迁移战略。 今天，我们可以看到市场上出现了更多的迁移战略选项，超越了五个 R 模型。 然而，它们或多或少建立在原始的五个 R 迁移战略基础上，具体如下： 如图所示：如下：

图 3.2 – 应用现代化战略

我们可以看到，我们 可以将每个应用程序分为三个 主要部分。

• 首先是通过完全停用现有应用程序，或用基于 Power Apps 或 Dynamics 365 的现成解决方案替换它，从而终结现有应用程序。

• 接下来是迁移过程，将应用程序按原样重新部署到云基础设施中，通常是在虚拟机等 IaaS 工作负载上。 在这里，我们从 Power Platform 的角度并没有做太多，只是意识到该应用程序存在于 Azure IaaS 上，并且在构建任何新应用程序时，我们可能会更轻松地连接到 Azure 云上的现有应用程序。 更容易。

• 最后一个部分涉及实际的现代化，其中部分代码得到现代化，或者整个应用程序从零开始构建。 这是我们回到项目规划阶段的部分，收集所有需求，构建架构设计，并开始利用 Power Platform 服务开展新项目。 当我们完成应用程序的现代化后，我们应在组织中安排团队负责培训和推广，鼓励用户开始使用 新应用程序。

目前，市面上有一些工具可以评估遗留应用程序，并根据评估结果将其映射到合适的迁移策略。 然而，使用工具只是实际评估的一小部分。 评估的大部分工作是通过分析工具的结果来完成的。 这一步骤是为了验证结果，并将其与手动评估过程中的发现进行对比，手动评估过程可能还包括与应用程序用户和管理员的访谈。 工具可能会根据评估的源代码或提供给工具的输入，决定采用一种迁移策略。 然而，在进行深入分析和访谈后，可能会选择另一种迁移策略。 所有这些输入对于我们在开始实际的应用开发工作之前，决定迁移策略至关重要。 开发工作。

数据库现代化

数据库现代化 不仅仅是更新现有的数据库系统，还涉及如何改进存储、处理和管理 应用程序数据的过程。

通常，我们会在进行应用评估的同时，也进行数据库评估，因为这两者是密切相关的。 许多时候，应用逻辑是以存储过程的形式写在数据库中的，因此在评估并决定应用现代化方法时，我们也应该考虑这部分内容，并决定如何将这部分逻辑从数据库系统中提取出来，并转移到处理该逻辑的服务上。 话虽如此，进行数据库评估仍然非常重要。 这将帮助我们创建数据库、表格及其关系的清单。 我们还应该关注性能指标，并了解 瓶颈所在。

与应用程序现代化战略类似，数据库现代化时，我们也必须决定不同的现代化战略。 这些策略可以与应用程序现代化的策略相同，只是适用于 数据库的上下文：

• 退休: 我们 决定淘汰该数据库。 如果我们要这么做，应该研究现有数据库的归档选项以及停用数据库对 其他系统的影响。

• 保留：有时，由于特定的限制或需求，我们可能无法迁移到更新的数据库系统，这时保留现有系统成为我们的选择。 在这种情况下，Power Platform 可以通过许多连接器和本地数据网关支持我们，通过这些方式，我们可以将应用程序与 数据库系统连接。

• 重新托管：我们可以在不改变数据结构的情况下，将数据库迁移到新平台。 这可以是运行在 IaaS 上的解决方案，比如 Azure 虚拟机上的 SQL Server，或者其他开源 SQL 和 NoSQL 数据库解决方案，例如运行在虚拟机上的 MySQL 或 PostgreSQL，具体取决于 所使用的解决方案。

• 重构：这 将涉及修改或扩展现有的数据结构，以通过性能、可扩展性和可靠性等方面改善与数据库系统的体验，或改善其他方面。 在这里，我们 旨在利用更新的技术，例如为某些部分使用云数据库服务，同时将其余部分保留在现有的基础数据库技术上。 在这种情况下，某些部分我们可能会使用 Microsoft Dataverse，或者切换到 PaaS 服务，如 Azure SQL 数据库。

• 替换与重建：这两个 选项放在一起，因为在支持 Power Platform 服务的情况下，Dataverse 可用作使用 Power Platform 服务开发的新应用程序的数据库。

无论我们选择哪种 现代化战略，我们都应该致力于实施和采纳支持组织内部 DevOps 的流程。 应用程序现代化不是一次性的过程，而是一个迭代过程。 组织应该在现代化过程中跟踪进展和经验教训，并在有需要时进行改进。 这为组织提供了灵活性，使其能够在必要时改变战略。 拥有敏捷开发团队，并配备 DevOps 工具，能够在一个中心位置共同工作并跟踪项目进度，这使我们在 执行时更加高效。

然而，这不仅仅是关于 DevOps 工具。 在一个对大多数组织来说可能是新的平台上构建的应用程序，将需要我们在内部进行工作，增加组织对新构建应用程序的采用度。 这就是 Power Platform 采纳成熟度模型可以 帮助我们的地方。

构建 Power Platform 采纳之旅

在前一节中，我们提到过，应用现代化不是一次性的过程，且它将需要对进展和潜在改进进行持续评估。 为了充分发挥 Power Platform 的潜力，组织应探索引入增加 Power Platform 采纳率的战略的方法。 这可能涉及授权新的应用程序开发者或提供全面的培训，以及实施有助于开发人员在受控环境中工作的防护措施、流程和工具。 本节将讨论 Power Platform 采纳成熟度模型，并强调其对组织的重要性。

Power Platform 采纳成熟度模型帮助组织了解它们在成熟度量表上的位置，并确保采纳与业务目标和关键绩效指标（KPI）对齐，同时推动数字化转型。 对于那些在 Power Platform 上较为成熟的组织来说，使用 Power Platform 构建新应用或现代化现有遗留应用会与刚刚接触 Power Platform 的组织不同。 公司应了解当前的成熟度水平，并实施有助于提高成熟度的战略，这将使公司成为更具弹性、更有经验和更具适应性的组织。 这样做还可能使应用现代化过程更加顺畅。

Power Platform 采纳成熟度模型

Power Platform 采纳成熟度模型的目的是帮助组织评估当前的成熟度水平，并利用一套最佳实践、模式和工具指导组织如何提升其能力。 通过持续改进的过程，组织可以不断评估并提升其在最关键领域的成熟度。

Power Platform 采纳成熟度模型与变更管理过程密切相关，这基本上是组织为实现从当前状态到期望状态的转变，通过实施控制变更的战略并帮助人们适应变化而采取的一种结构化方法。 正如我们所提到的，这也是采纳成熟度模型的目的——帮助定义 Power Platform 服务采纳的战略或计划。 该计划应与组织的业务部门对齐并获得批准，因为改进目标应基于 业务目标。

Power Platform 采用成熟度模型基于 能力成熟度模型 (CMM)。像 CMM 一样，在这个模型中，我们也遵循五个成熟度层级，从级别 100 到 级别 500：

图 3.3 – Power Platform 采用成熟度模型层级

每个层级 涵盖多个学科，这些学科为组织在各个领域的成熟度提供了见解。 这些学科如下：

• 战略 与愿景

• 业务价值

• 培育

• 管理 与治理

• 支持

• 自动化

• 融合团队

在 ALM 和 DevOps 方面，很多改进可以在自动化领域完成。 组织的自动化状态从级别 100 开始，ALM 流程大多是手动且非常个性化的，发展到级别 300，部署可能仍然是手动完成，但组织已经开始使用解决方案，一直到级别 500，ALM 流程已集中实施并由融合团队负责。 稍后，在 第六章中，我们还将看看 ALM 加速器，它帮助组织加速为 Power Platform 设置 ALM。

与 DevOps 和采用之旅紧密相关的，还有组织中融合团队的状态。 成熟度层级展示了融合开发团队在组织中的不同参与度。 级别 100 是融合团队尚未出现，专业开发人员没有参与 Power Platform 项目开发，工作主要由应用制作人员完成。 随着向级别 300 发展，我们可以看到团队开始形成。 融合团队成员了解并使用版本控制系统，甚至开始实施 ALM；然而，这些团队所做的工作仍然大多是分散的，尚未完全集中。 进入级别 500，形成了跨领域的融合团队，融入了跨职能的技能。 在级别 5，制定了统一的开发战略，拥有一个支持组织协作的集中式源代码管理系统。 第九章 详细解释了融合 开发方法。

各阶段的采纳成熟度模型

Power Platform 的采纳成熟度模型涵盖了五个成熟度级别。 接下来，我们将通过 一个示例来看每个级别。

级别 100 – 初始

在这个阶段，我们 可以看到，组织可能会有一些成功的案例，它们是通过使用 Power Platform 开发的。 用户可能会自行访问 Power Platform，通常通过 Microsoft 365，使用他们的预置许可证。 他们在 Office 365 服务上构建应用程序，通常使用 Excel 或 SharePoint 作为数据源。 由于这些应用程序是由个人开发的，个人也负责维护它们，而且这些应用程序大多不可重复使用。 没有集中式的治理或 ALM 策略。 用户主要在默认环境中工作；然而，由于没有保护措施，用户甚至可能会打开新的环境并使用任何连接器。 尽管通过这些成功的案例，组织可能会发现 Power Platform 的潜力，但尚未制定向组织范围推广的策略，也没有计划建立 一个 CoE。

为了达到下一个成熟度水平，在培养和提升未来应用开发者方面还有很多工作要做。 组织可以组织培训课程或黑客马拉松活动，在这些活动中，人们可以学习 并共同合作，构建解决特定业务问题的方案。 识别出在技术上早期采用的应用开发者对组织来说是有益的。 通过他们，我们可以将这些工作的经验 推广给其他人。

级别 200 – 可重复

组织 已经迈出了第一步，开始发现组织内用户所做的工作。 他们可能已经实施了 CoE 启动工具包，该工具包提供了一系列工具，帮助组织洞察 Power Platform 的采纳情况。 已开发的业务应用程序已经有一些文档，使其在需要时可以重复使用。 组织在 IT 和业务之间建立了共同的愿景，但新项目仍然是单独管理的。 一些政策已经开始实施，包括 DLP 政策，但仍然没有环境战略。 应用开发者可以组成团队或社区，通过这些团队和社区彼此支持，共同推进 开发过程。

为了晋升到下一个层级，组织可以在默认环境中实施 DLP（数据丢失防护）策略，访问 Power Platform 管理中心的分析功能，获得跨租户的洞察，改善与应用开发者的沟通，并继续建设内部培训资源。 后者可以通过集中式的内部 SharePoint 网站或其他 学习管理系统 (LMS) 工具来完成。

级别 300 – 已定义

在这个 层级，LCNC 开发方法成为标准业务流程的一部分。 组织通常会有一位代表或整个团队，担任 Power Platform 产品负责人。 应用程序可以由个人用户、业务单元或部门开发，因此创新既可以从下往上，也可以从上往下进行。 已经有更多使用 Power Platform 的成功案例，这些案例甚至可以进行量化。 已经建立了 CoE 团队，尝试自动化许多流程，如环境创建请求。 团队已经开始实施源代码控制系统，以便开始进行 ALM（应用生命周期管理）；然而，部署仍然主要是手动完成的。 应用开发者理解可重用性的重要性，并开始构建和 利用组件。

为了提升 成熟度，组织可以实施环境策略并配置 Power Platform 中的各种安全和治理控制。 我们应该继续通过他们开发的成功案例，培养和推广我们的应用开发者和团队。 这些案例是他们已经开发的。

级别 400 – 能力成熟

处于这个阶段的组织 已经非常先进。 他们已经建立了衡量 Power Platform 影响力的流程。 一个完善的 CoE 团队能够管理和监控 Power Platform 租户。 组织已经有了与融合团队合作的经验，这些团队具备跨职能的技能。 这使得开发过程中能够更好地合作。 ALM 流程已被定义，组织使用工具来集中管理 ALM 和 DevOps 流程。 部署流水线已实施并自动完成。 管理员能够通过分析识别未使用的应用，并采取自动化措施来管理环境。 在组织内，可能存在一个独立的支持团队，负责支持最终用户和 应用开发者。

为了推进到下一个成熟度水平，组织可以更加关注可重用性，实施应用程序目录，以确保可重用组件能够被访问，从而在应用程序之间提供一致性。 CoE 团队与 IT 运维团队之间的工作可以通过聊天机器人 实现自动化。

级别 500 – 高效

这是最 先进的阶段，在这个阶段，Power Platform 已成为数字化转型战略的一部分。 处于这个阶段的组织已经标准化和自动化了流程，能够快速开发项目以支持业务需求。 大型应用程序被构建以供整个组织使用。 在设计新项目的架构时，会包含 Power Platform 服务。 仪表板和报告已经实施，用于支持业务决策并验证 Power Platform 在每个项目中的影响。 组织内部对 Power Platform 的使用提供高层支持。 行政任务已实现自动化，尽可能利用自动化技术，包括带有审批流程的聊天机器人来执行租户管理操作。 融合团队已到位，并且拥有共同的开发战略，配备了完全自动化的 ALM 管道。 支持任务大多已自动化，包括用于内部支持的聊天机器人 或常见问题解答。

提升成熟度水平的方法

尽管 我们已经定义了每个级别，并提到组织应该努力提高成熟度水平，但常常会出现每个级别中的学科各自独立发展的情况。 这意味着，组织内部的级别提升并非在所有领域内系统地进行，而是专注于 特定领域。

我们可能会遇到刚刚开始采用 Power Platform 且处于初始阶段的公司，这些公司面临一个重要的应用程序现代化项目，这推动它们在非常具体的领域内适应并提升成熟度水平，以支持该项目。 这些公司会围绕它们希望在每个学科中达到的级别，制定自己的计划和战略，并创建一个有时间表的聚焦计划，帮助它们 实现目标。

为了更快地实现目标，他们可以遵循 Power Platform 采纳 最佳实践。

采纳最佳实践

提高 采用成熟度有助于组织更有效地使用技术，使他们能够建立支持数字化转型的流程。 为了支持这一采用过程，微软提供了一套最佳实践和指南，对任何人都有帮助：无论是刚开始使用 Power Platform 的人员，还是希望提高采用成熟度的人员，甚至是那些经验丰富但在推动组织服务采纳时遇到一些挑战的人。 组织中的人员。

采用最佳实践分为四个领域，涵盖了采用成熟度模型中的大多数学科：

• 战略 与愿景

• 管理员 与治理

• 培养 与教育

• 支持

Power Platform 着陆区

此 Power Platform 着陆区 参考文档作为一个模块化架构参考 指南，帮助组织按照设计原则和关键设计领域实施所需的 Power Platform 租户状态。 它帮助我们创建符合已达成治理政策的 Power Platform 环境。 正如我们所看到的，采用成熟度模型强调了自动化环境管理方法如何区分不同成熟度水平的组织。

Power Platform 架构良好的框架

该 Power Platform 架构良好的框架 (WAF) 是一个框架，它汇集了最佳实践和建议，帮助各类组织实现 Power Platform 应用工作负载的最优架构设计。 组织可以确保，通过遵循 Power Platform WAF，他们的环境将准备好应对未来的扩展，并设置必要的控制措施，确保环境和数据的合规性与安全性。 以及数据。

我们将在第十一章中深入探讨这些主题，届时将讨论更多关于 IT 操作的内容。 在那里，我们还将讨论这些最佳实践的安全方面以及可用于集中管理环境的工具 和自动化工具。

摘要

本章介绍了 为什么 以及 如何 使用 ALM 和 DevOps 与 Microsoft Power Platform 的相关内容。 理解 ALM 和 DevOps 对组织带来的价值非常重要，因为我们需要向组织展示，这不是一项不可能完成的任务，而是每个组织都可以并且应该实现的目标。 我们在本章中学习了这一点。 这就是为什么学习 ALM/DevOps 流程如何实现以及有哪些工具可用如此重要，正如我们在本章中所做的那样。 由于这是一个持续学习和改进的过程，组织不必担心第一次尝试时可能无法完全做到。 通过不断迭代改进和适应过程，使其量身定制以适应组织，是实现 卓越的正确方法。

我们讨论了应用现代化的话题，以及为什么组织需要审视其现有的遗留应用，并探讨了应用现代化战略的选项。 我们看到，DevOps 和采纳是数字化转型和应用现代化的核心。 这就是为什么我们要了解 Power Platform 采用成熟度模型是什么，以及组织如何确定自己在每个领域的成熟度水平。 很可能，组织在某些领域的成熟度较高，而在其他领域则较低，正如我们在本章中学到的那样。 我们还了解到，组织制定如何改善这些差距的战略、实现平台潜力，并看到 Power Platform 的投资回报是非常重要的。 下一章将深入探讨解决方案和环境。 我们将了解这些概念在 Power Platform 中的含义、可用的类型是什么，以及它们之间的差异。 这将帮助我们熟悉托管环境和解决方案，以及如何使用管道并开始构建我们的第一个 CD，使用 托管管道。

进一步阅读

• Azure DevOps： https://azure.microsoft.com/en-us/products/devops

• GitHub: https://github.com/

• Power Platform 采用成熟度 模型： https://learn.microsoft.com/en-us/power-platform/guidance/adoption/maturity-model

• Power Platform 采用 指南： https://learn.microsoft.com/en-us/power-platform/guidance/adoption/methodology

第二部分：在 Microsoft Power Platform 上实施 DevOps

在本部分中，我们将探讨 Microsoft Power Platform 的环境和解决方案，以及它们如何集成到 DevOps 相关流程中。 通过实际操作，我们将熟悉 PAC CLI、Git 版本控制系统、Azure DevOps Services 管道和 GitHub 工作流。 我们还将发现 Power Platform 管道和托管环境的最新功能。 此外，我们将深入了解 Power Platform 上的 DevSecOps，利用 GitHub 的高级安全功能，针对 GitHub 和 Azure DevOps 进行深入探讨。 最后，我们将把所学知识应用到一个实际案例中，进一步巩固对 这些概念的理解。

本部分包含以下章节：

• 第四章， 理解 Power Platform 环境和解决方案

• 第五章， 通过 DevOps 工具简化 Power Platform 开发

• 第六章， 深入了解持续集成/持续部署（CI/CD）管道

• 第七章， Power Platform 中的 DevSecOps 概述

• 第八章， 展示 ALM 和 DevOps 实施

第四章：了解 Power Platform 环境和解决方案

现在我们已经了解了 Power Platform 产品，以及 应用生命周期管理 (ALM) 和 DevOps 方法，在前几章中，接下来是探索成功的 ALM 基础构建模块，介绍 环境 和 解决方案的概念。我们将从解释 Power Platform 中构成解决方案的内容开始，然后讨论 Dataverse 以及在该框架下的数据建模。 我们还将涵盖平台中解决方案和包的版本控制，以了解如何管理不同版本的解决方案。 我们将学习 托管环境 和 托管管道的概念，还将发现如何使用它们来自动化和简化软件开发过程。 我们将以一个逐步指南结束本节，介绍我们在 Power Platform 中的第一个 持续集成和持续部署 (CI/CD) 管道，帮助我们实践理解在此特定环境下 CI/CD 过程的工作原理。 具体情况。

在本章结束时，我们将能够使用内置的 Power Platform 管道设置 CI/CD 管道，将解决方案部署到不同的环境，并使用 Copilot 生成部署说明 在管道中。

在本章中，我们将讨论以下 主要主题：

• 解决方案涉及的内容？

• 解决方案和包的版本控制 和包

• 数据相关内容——Dataverse 和数据 建模方面

• 环境——托管环境和 环境策略

• 托管管道——我们的 第一个 CI/CD

技术要求

为了能够使用 Power Platform 管道创建我们的第一个 CD 管道，我们需要拥有一个 Power Platform 订阅。 如果我们已经拥有 Microsoft Entra ID 工作账户，可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free）；或者我们也可以加入 Microsoft 365 开发者 计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。

此外，我们需要安装 PAC CLI 工具和 PowerShell 管理员模块。 请参见 第二章 以获取设置和 安装信息。

什么是解决方案？

正如我们在前几章中所学，Power Platform 包含多个产品，包括 Power Apps、Power Automate、Power Pages、Microsoft Copilot Studio、Dataverse、AI Builder 等。 我们通常将这些产品中可以创建的构建块称为资产或解决方案组件。 一个资产可以是一个画布应用、连接引用、云流、自定义 Copilot，甚至是为 Dataverse 或 Dataverse 表 架构定义而开发的插件。

解决方案 是 构建 Power Platform 应用程序的资产容器。 它们可以包含一个或多个应用程序，以及其他组件，如流、定制 Copilot、Power Pages 网站、站点地图、实体、流程、Web 资源、选项集、专业开发组件（如插件、PCF 组件等）。 一些组件嵌套在其他组件中；例如，Dataverse 表包含表单、视图、图表、列、表关系、消息和业务规则。 这些组件中的每一个都需要一个表才能存在，并且不能存在于表之外。 另一方面，解决方案需要安装了 Dataverse 的环境。

我们需要解决方案，因为 Power Platform 解决方案是将应用和组件从一个环境传输到另一个环境或将一组自定义应用于现有应用的方式。 这是 Power Platform 中 ALM 流程的关键基础之一。 要实现这些发布并且 让 持续部署 （CD）顺利工作，平台定义了两种类型 的解决方案：

• 托管解决方案 是 通过将一个非托管解决方案导出为托管解决方案包来创建的。 一旦将托管解决方案导入目标环境，解决方案中的组件将被锁定，并且只能由解决方案的发布者进行修改。 这使得 发布者能够控制如何在目标环境中使用和更新该解决方案。 托管解决方案就像生成的二进制文件；它们在 目标环境中是不可变的。

• 非托管解决方案 通常用于开发环境，其中会对应用程序进行更改和定制。 与托管解决方案不同，非托管解决方案中的组件没有被锁定，任何具有适当权限的人都可以进行修改。 这些解决方案类似于应用程序的源代码 在定制开发项目中。 非托管解决方案作为非托管解决方案包进行导出，并可以导入到其他环境中进行进一步的开发或测试。 然而，值得注意的是，非托管解决方案不应在生产环境中使用，因为任何有权限访问其定义组件的人都可以对其进行更改。

每个开发项目都从非托管解决方案开始，开发人员通过添加组件来扩展，以实现原始客户需求。 在完成开发并通过测试阶段后，非托管解决方案会转换为 托管解决方案。

我们还可以手动导出解决方案，这会生成 ZIP 文件。 对于托管解决方案，ZIP 文件只包含少数几个文件。 其中之一是一个 .msapp 文件。 另一方面，非托管解决方案的 ZIP 文件包含大量描述 Power Platform 资产配置的 JSON 和 XML 文件，这些资产包含在解决方案中。 如果需要，我们也可以编辑后者。 如果需要的话。

考虑到传统的开发术语和方法论，创建托管解决方案等同于生成二进制文件，因此它正是 一个 持续集成 (CI) 构建所做的。 将托管解决方案移至不同环境对应于 CD 步骤。

解决方案作为起点

强烈建议通过创建一个解决方案来开始对任何 Power Platform 组件或资产进行定制。 然后我们应当在解决方案内创建组件，而不是在相应的编辑器中创建。 当我们使用这种方法时，平台会立即将所有依赖项添加到 Power Platform 解决方案中。

解决方案分层 是 Power Platform 中的一项功能，允许我们管理解决方案内组件的依赖关系和行为。 当我们将一个解决方案导入到环境中时，解决方案内的组件会根据其依赖关系被组织成多个层。 每一层代表一个特定的解决方案，该解决方案扩展或更改了组件的行为。 解决方案层允许我们控制不同解决方案之间的交互方式，以及一个解决方案的更改如何影响其他解决方案。 当我们有多个解决方案修改同一组件时，这尤其有用，因为它允许我们管理冲突，并确保组件的行为在所有解决方案中保持一致。 下图展示了解决方案分层如何在实际中工作：

图 4.1 – 解决方案层

在 系统解决方案 和 系统层的基础上，每个 托管解决方案会创建自己的托管解决方案层。 如果多个解决方案更改同一底层组件（资产），则最后的自定义会生效（最后的更改有效）。 为了避免与其他解决方案的合并冲突，最佳做法是使用唯一的资产名称，例如在常见 Dataverse 表中使用唯一的表单和视图名称。 由于自动化部署管道在后台运行，我们也需要关注此类冲突 情况。

为了支持现代的 ALM 和 DevOps 流程，除了拥有不可变的二进制文件（解决方案）外，我们还 需要版本号。 版本号 帮助开发人员和运维团队识别生产环境中运行的软件。 Power Platform 解决方案也提供版本管理功能，我们将在 下一节中讨论。

解决方案和包的版本管理

每个 解决方案都有一个版本号，遵循以下 知名 模式：

 Major.Minor.Build.Revision

版本号的每个部分都有一个 特定的含义：

• 主要：当软件发生重大变化时，如添加新功能或不兼容的更改时，这个数字会增加。

• 小版本：当软件进行小幅更改时，例如添加新功能或改进现有功能，且这些更改 向后兼容时，版本号会增加。

• 构建：当软件发生变化但不影响其功能时，例如修复漏洞或 性能改进时，构建号会增加。

• 修订：当软件进行小幅更改时，例如修补程序或 安全更新时，修订号会增加。

Power Platform 解决方案的生命周期涉及多个阶段，包括创建、更新、升级、修补和升级准备。 以下是各个操作的适用时机概述： 这些操作：

• 更新：此选项用新版本替换我们的解决方案。 不属于新版本的资产不会被删除，仍然可以在环境中使用。 此选项通常比升级方法完成的时间更短，性能最好。 我们可以为托管解决方案创建更新，这些更新会部署到父托管解决方案下。 我们不能通过更新删除组件。

• 升级：升级将所有补丁合并到解决方案的新版本中。 在升级过程中，任何不再包含在新版本中的组件将被删除。 升级可以立即进行 或分阶段进行。

• 升级准备：此操作用于在部署解决方案之前准备目标环境。 升级准备不会删除解决方案的先前版本；旧版本和新版本会并排安装。 如果我们需要在完成解决方案升级之前进行数据迁移，可以使用此场景。 解决方案升级。

• 补丁：补丁仅包括对父托管解决方案所做的修改，例如添加或修改组件和资产。 补丁用于进行小的更新，如热修复。 导入补丁后，它将应用于父解决方案之上。 无法通过补丁删除组件。

下图显示了 Power Platform 解决方案的生命周期，突出了应用程序的主要阶段： 一个应用程序：

图 4.2 – 一个解决方案的生命周期

每个解决方案 都从 创建 阶段开始其生命周期。 在 开发和发布 阶段，多个更新、升级和补丁作为托管解决方案发布。 在应用程序生命周期结束时，托管解决方案将被删除，进而从 Dataverse 中移除所有自定义对象。

在托管解决方案的情况下， 升级 操作是默认选项，介于 更新、 升级、 升级阶段和 补丁 操作之间，而未托管解决方案只能进行 更新。

Power Platform 解决方案补丁是一种仅更新解决方案中已更改的组件，而不是重新部署整个解决方案的方法。 它们有助于减少部署时间并避免与其他解决方案的冲突。 补丁仅包含父级托管解决方案的更改，如添加或编辑组件和资源。 使用补丁的典型例子包括在画布应用上添加新按钮或扩展自定义或系统表的列定义。 补丁的版本号在 1 上递增，反映在 构建 号中：

 {major}.{minor}.{build+1}.{version}

只有未托管解决方案可以有一个或多个补丁，我们可以将它们导出为托管补丁，部署到其他环境中。 创建补丁的解决方案被锁定，直到补丁被合并并且新版本的解决方案被克隆。 这个版本将获得 {major}.{minor+1}.{build}.{version} 版本号，正如我们在 下图中所见：

图 4.3 – 补丁和版本

父级 解决方案是版本为 1.2.0.0 的未托管解决方案。 补丁分别获得递增的版本号 1.2.1.0 和 1.2.2.0。 在汇总补丁后，未托管解决方案的新版本将 为 1.3.0.0。

我们建议尽量少使用补丁，因为迟早我们需要将补丁汇总起来，并发布一个 解决方案更新。

如果我们的解决方案包含太多自定义内容，那么在同步导入过程中可能会遇到超时问题。 解决方案分阶段 将导入过程拆分成更可控的阶段，并异步执行这些步骤。 此选项在 Dataverse SDK for .NET 中、通过 Web API、在 Azure DevOps 和 GitHub 的构建工具中，以及在 PAC CLI 中均可使用。

有两个高级的专业开发工具，我们可以用来深入自定义解决方案的导入和导出过程：

• SolutionPackager 是用来解包解决方案 ZIP 文件到解决方案文件夹，或者将解决方案文件夹打包成解决方案 ZIP 文件的工具。 我们还可以配置 是否将生成的 ZIP 文件设置为托管解决方案或 非托管解决方案。

• Package Deployer 工具 是 Power Platform 中的一个强大工具，允许管理员在 Microsoft Dataverse 实例上部署包。 一个 Package Deployer 包可以包含以下任意内容： 或全部内容：

  • 一个或多个 Dataverse 解决方案文件

  • 纯文本文件或从配置迁移工具导出的配置数据文件 。

Package Deployer 是一个出色的工具，可以将多个解决方案打包为一个整体包，部署到我们的 Power Platform 环境中。 我们只需要在 Visual Studio 2019 或更高版本中创建一个 MSBuild 项目文件，或者使用 Visual Studio Code。 然后，我们可以将解决方案、附加的配置文件、HTML 内容，甚至自定义代码添加到该 MSBuild 项目中。 构建完包后，管理员可以将其安装到目标环境中。 我们的自定义代码会在导入过程中执行，而 HTML 内容会显示给管理员，以便他们了解我们的包究竟做了什么。 我们在 第二章 中学习的企业模板也是以这种方式创建的。

现在我们已经了解了 Power Platform 的解决方案概念，接下来让我们来看看 Dataverse，这些解决方案（以及其他内容） 就存储在这里。

那数据呢——Dataverse 和数据建模方面

我们都知道，没有数据，应用程序是无法正常工作的。 它们要么使用数据来改变自身行为（比如数据驱动的应用程序），要么通过众所周知的 创建-读取-更新-删除 (CRUD) 操作来处理数据。

Microsoft Dataverse 是一个 基于云的数据平台，是 Microsoft Power Platform 的一层强大的数据库服务，不仅存储关系数据（类似 SQL 表格），还存储文件、日志以及 NoSQL 物联网数据。 在其背后，Dataverse 无缝地使用了许多 Azure 服务，作为 多语言持久层。下图展示了 Dataverse 及其使用的 Microsoft Azure 服务的高级架构：

图 4.4 – Dataverse 多语言概念内部结构

正如我们在 图中所见，Azure 负载均衡器将请求分发到多个 计算服务：

• Web 用于处理 OData API 请求

• Azure 作业 用于处理 异步处理

• 用于运行客户 C# 代码的沙箱，代码将在 处理流水线中执行

• 报告服务器处理 分页报告

我们使用多种存储服务，以最有效和高性能的方式持久化我们的数据。 关系数据 存储在 Azure SQL 托管实例，文件和附件写入 Azure Blob 存储，由 DataFlows 生成的分析 数据存储在 Azure 数据湖存储。我们还使用 弹性表 ，一个用于存储 物联网 (IoT) 数据 的全新概念，支持数千万条记录 ，由 Azure Cosmos DB提供支持。

Dataverse 管理 所有这些 Azure 数据服务，提供 99.9% 的可用性、企业级可扩展性、备份、审计日志和灾难恢复管理。 Dataverse 也是 Dynamics 365 产品系列背后的主要数据存储解决方案。

数据库服务的一个关键特点是内置的安全解决方案，采用严格的基于角色的访问模型，以及行级和列级的安全配置。 Dataverse 安全性基于基于角色的安全模型，保护数据的完整性和隐私，同时支持高效的数据访问和协作。 可以访问 Dataverse 的用户是 Microsoft Entra ID 账户，也就是 Azure AD 用户。 每个用户可以被分配一组预定义的安全角色，这些角色决定了用户可以访问的记录类型、用户可以管理的数据范围以及他们可以执行的具体任务。 该模型被称为行级安全性，它仅提供用户进行工作所需的适当级别的信息访问。 例如，用户可以查看和编辑他们创建的记录。 他们的主管可以查看和编辑他们下属创建的所有记录。 常见的 安全角色 如下：

• 系统管理员：此 角色可以访问所有数据，并执行所有任务，包括定制 系统

• 系统定制员：此 角色可以定制系统，但无法访问 所有数据

• 环境管理员：此 角色可以访问环境中的所有资源 包括 Dataverse

• 环境创建者：此 角色可以创建新的环境资源，例如应用、流程和 API，但不能访问 环境中的数据（Dataverse）

• 基础用户：此 角色对数据的访问有限，并且只能执行 基本任务

Dataverse 还 提供 薪资 列，位于 这些记录中。

此外，Dataverse 提供 数据丢失预防 (DLP) 功能，以强制执行跨连接器的策略。 策略可以在租户或环境级别定义。 稍后我们将看到，每个环境可以创建一个或零个 Dataverse。 环境级别的策略适用于环境级别，仅在该级别适用，而租户级别的策略适用于整个租户，并优先于环境级别的策略。 DLP 的管理和治理涉及事件警报和报告，为管理员提供关于策略匹配的详细信息，使其能够有效监视和保护敏感数据。 这些报告帮助管理员了解随时间变化的 DLP 策略和规则匹配次数，通过动作和位置过滤这些匹配，并确定规则匹配是上升还是下降。

零信任安全原则 是 基于的理念，即信任是一种漏洞，安全必须设计为 从不信任，始终验证的策略。这意味着，与其假设企业防火墙后的所有内容都是安全的，零信任模型假定存在入侵，并像来自不受控网络的请求一样验证每个请求。 在 Dataverse 和 Power Platform 的背景下，可以通过使用基于角色的访问控制、字段级安全性和 DLP 功能来应用零信任安全原则，以强制执行策略和保护数据。 通过在设计安全角色时实施 最低特权策略，我们可以确保用户只能访问他们工作所需的资源。 此外，我们可以使用 Microsoft Entra ID 管理用户身份和访问，并实施 即时访问 (JIT) 和 仅够访问 (JEA) 策略，以确保用户只在需要时访问所需内容。 遵循零信任安全原则，我们可以最大限度地减少数据泄露风险，并保护组织的数据，同时仍能实现高效的数据访问和协作。

除了这些全面的功能外，Dataverse 还有一个通用的数据库架构。 该 通用数据模型 （CDM）是由微软及其合作伙伴发布给开源社区的，存储在 GitHub 上的一组共享、标准化的数据架构。 它将数据统一为已知的形式，并在多个应用程序和部署中应用结构化和语义一致性，使数据管理和应用开发更加简便。 CDM 受到 Dynamics 365 中数据架构的影响，涵盖了广泛的业务领域。 它带来了包括 账户， 客户， 产品， 机会， 销售， 采购订单，等等，通用数据表定义已加入 Dataverse。 CDM 定义是开放的，任何希望使用这些定义的服务或应用程序都可以访问。 通过使用 CDM，我们可以轻松地与 Dataverse 和其他服务集成，并可以构建使用我们可用的实体定义的自定义应用程序。 这可以节省我们的时间和精力，因为我们不需要从头开始构建新的数据模型 。

Dataverse 架构定义，如 表格， 列， 关系， 业务规则， 视图， 表单， 仪表盘， 图表， 消息， 键，和 命令，是解决方案定义的一部分，这意味着数据库级别的更改是开发人员可以包含在他们的解决方案中的资产之一。 另一方面，解决方案本身存储在 Dataverse 中。 当我们将解决方案导入到 Dataverse 时，它的元数据和依赖配置会被导入到各种系统表中，例如 解决方案， 解决方案组件属性配置， 解决方案历史， 解决方案组件历史，等等。 在元数据导入后，底层系统流会安装解决方案并应用 这些更改。

Dataverse 和解决方案中的数据

要向 Power Platform 解决方案中的 Dataverse 表添加数据，我们可以使用 导入数据 选项，该选项位于 Power Apps 的 表格 页面顶部的命令栏中。 （故意）没有方法将数据包含在 Power Platform 解决方案中。 但是，我们可以将数据导出，然后将其导入到新环境中。 另外，如果当前生产环境中没有内容，我们可以在 Power Platform 管理中心复制整个开发环境。 推荐的工具和方法包括使用配置迁移工具、包部署工具、Power Platform 数据流，或在 Dataverse SDK for .NET 中编写代码以在目标环境中创建实体，这些都是导入数据 到环境中的推荐工具和方法。

Dataverse 实例存在于环境中，这是一个用于在租户范围内组织我们的应用和解决方案的附加概念。 在下一部分中，我们将了解如何从 专业开发者的角度考虑这些环境。

环境、托管环境和环境策略

环境 是我们的应用、流程、连接和其他组件的容器，同时还具备安全性和数据访问管理功能。 借用云计算世界的类比，我们可以将 Microsoft Azure 订阅看作是环境，它们作为逻辑容器，能够托管一个或多个应用。 也许 工作负载 这个术语在这里更为合适，因为我们的 Power Platform 应用可能包括 Power Apps、Flows、自定义 Copilots、Power Pages 网站等。 强烈推荐使用解决方案将工作负载 部署到环境中。

Microsoft Power Platform 租户可以拥有数千个环境。 Microsoft Entra ID 是提供安全控制、治理和环绕 Power Platform 每个产品的保护框架的粘合剂。 如前所述，Power Platform 运行在 Microsoft Azure 之上。 环境是隔离的关键概念，用于在不同的地理位置定义系统边界。 我们可以创建没有 Dataverse 的环境，但这些环境仅提供非常 有限的功能。

没有 Dataverse 的环境

没有 Dataverse 的环境仅支持 Power Apps 画布应用和 Power Automate 云流。

如果我们使用 Dataverse 创建环境，我们将获得 Power Platform 安全功能的整个范围 。 这意味着我们可以在环境内部的不同层级上分配基于角色的安全角色来 划分安全性。

在 Power Platform 中， 业务单元 代表了一个组织中的单位，该单位执行一个或多个可以在管理层级中汇总的业务职能。 业务单元可以用于镜像公司的组织结构，并控制数据访问。 每个业务单元都有自己的安全角色，这些角色定义了业务单元内用户的访问权限。 有内置的安全角色，如基本用户、系统管理员等，我们也可以创建自己的安全角色。 例如，如果我们引入一个自定义表格来存储审核记录，我们可以创建一个自定义安全角色（例如审核员），使其成员可以读取自定义表格中的所有记录，而其他人只能看到自己的记录。 我们还可以将这些安全角色添加到 解决方案中。

团队 是 一群一起工作并共享共同访问权限的用户。 Power Platform 中有两种类型的团队： 所有者团队 和 访问团队。所有者团队 拥有记录，并且有安全角色分配给它们，而 访问团队用于授予记录访问权限，但不拥有它们。 一个团队可以由同一组织（在同一环境下）内的一个或多个业务单元的用户组成。 一个用户可以被分配到一个或 多个团队。

业务单元、团队和用户之间的关系对于控制数据访问和确保用户对记录具有适当的访问权限非常重要。 通过正确设置业务单元和团队，管理员可以确保用户能够有效地协作和共享信息，同时维护 数据安全。

Microsoft Entra ID 和 Power Platform 环境

由于 Microsoft Entra ID 和 Power Platform 之间的连接，通常的做法是使用 Microsoft Entra ID 组来授予对 Power Platform 环境以及其中的业务单元和团队的访问权限。 这些环境中的访问权限。

环境有不同类型 ：

• 生产环境：这是 创建和运行应用、流程及其他资源的默认环境类型。 它具有完整的功能，且可以连接到任何数据源。 只有生产环境才有服务级别协议（SLA）保障，所有生产数据都会备份到配对或辅助的 Azure 区域（启用了地理复制）。

• 试用环境：这是一个 临时环境，可以用于测试或学习目的。 它具有与生产环境相同的功能，但在 30 天后到期且无法延长或转换。

• 沙盒环境：这是一个 隔离的环境，可以用于开发、测试或培训目的。 它具有有限的功能，无法连接到生产数据源。 可以根据需要重置、复制或转换回生产环境。

• 开发者环境：这是一个 特别的环境类型，个人开发者可以使用它来创建和测试应用、流程以及其他资源。 它具有与沙盒环境相同的功能，但容量较小，只能由一个用户使用。 开发者环境不需要许可证，且每个开发者最多可以拥有三个不同的开发者环境。 管理员可以根据 组织的需求，允许或禁止创建开发者环境。

环境绑定 到一个 地理位置 ，该地理位置在环境创建后无法更改。 微软 Power Platform 保证数据将保留在选定的地区（数据驻留），且数据永远不会被转移到 其他位置。

环境还用于 分配 容量附加组件 ，这些是我们可以购买的，额外添加到我们的 Power Platform 订阅中的。 容量附加组件包括微软 Copilot Studio 消息、Power Pages 容量层级、AI Builder 积分、Power Automate 托管的 RPA、Power Automate 流程或流程挖掘的容量附加组件。 我们可以将其中一些或所有这些容量分配到 Power Platform 管理中心中的不同环境。

最后，环境可以与 Microsoft Azure 订阅绑定。 Power Platform 的 按需付费 (PAYGO) 服务 例如每个应用的 Power Apps 计量器、Power Pages 认证用户计量器、Power Pages 匿名用户计量器、Dataverse 数据库容量计量器、Dataverse 文件容量计量器以及 Dataverse 日志容量计量器，均通过现有的 Microsoft Azure 订阅进行交叉计费。

还有一个更加受控的环境，我们建议在生产中使用。 让我们来了解一下 托管环境。

托管环境

托管环境 是一套帮助管理员大规模管理 Power Platform 的功能。 它提供了多项好处，包括使用 Microsoft Defender 进行的风险评估和威胁警报、具有多年度历史的丰富分析、合规报告以及推荐。 它还允许你审计用户行为。 它通过根据我们组织的需求定制权限、政策和自动化，或仅需单击一下即可激活最佳的开箱即用设置，提供更多的控制。 以下列表详细介绍了 这些功能：

• 限制共享 允许管理员控制其组织内数据和资源的共享。 管理员可以阻止与安全组的共享，并限制可以共享的个人数量。

• 每周使用情况洞察 提供关于我们最热门应用、最具影响力的创建者以及可以安全清理的非活动资源的分析。 这些洞察每周发送到我们的邮箱。

• 数据策略：Power Platform 中的数据策略允许我们在 Power Apps 和 Power Automate 内使用数据连接器时控制数据流。 DLP 策略使管理员能够通过将 Power Platform 连接器分为业务和非业务组，来隔离业务数据和个人使用数据。 我们还可以选择阻止某些连接器的使用。

• Power Platform 中的管道 旨在为 Power Platform 客户普及应用生命周期管理（ALM）。 管道为所有创建者、管理员和开发者提供了一个简单易用的方法来进行 ALM 自动化、持续集成（CI）和持续交付（CD）工作流。 我们将在 接下来的章节中介绍这个话题。

• Maker 欢迎内容 允许管理员为新加入的 Maker 添加欢迎信息。 此信息可以包括经过验证的资源、公司特定的资源以及即将举行的内部活动链接，以帮助新 Maker 启动 Power Platform。 欢迎内容可以添加到托管环境中，并且可以包括纯文本 或 Markdown。

• 解决方案检查器 工具允许我们检查解决方案的最佳实践和常见问题。 它分析我们的代码和定制，并提供详细报告，包含问题信息以及如何修复。 这有助于提高我们在托管环境中的解决方案的性能、可维护性和可靠性。 管理员可以在部署过程中强制执行解决方案检查器的执行。

• IP 防火墙 允许我们根据来访请求的 IP 地址限制对我们的数据和资源的访问。 这有助于防止外部未经授权的访问我们组织的数据和资源。

• IP Cookie 绑定 是一项安全功能，将用户的会话 Cookie 绑定到其 IP 地址。 这有助于防止会话劫持攻击，其中攻击者窃取用户的会话 Cookie 并用它来 冒充用户身份。

• 客户管理密钥 （CMK）允许我们使用自己的加密密钥对静态数据进行加密。 这使我们对数据安全性有更多控制，并帮助我们满足 合规要求。

• Lockbox 为我们的数据提供额外的安全层。 它允许我们控制微软支持工程师是否可以访问我们的数据来解决支持案例。 我们可以批准或拒绝每一个访问请求，所有访问都将记录和审计 以确保合规。

• 扩展备份 允许我们保留更长时间的数据备份。 这可以帮助我们在数据意外删除 或损坏的情况下恢复数据。

• 桌面流 DLP 是 Power Platform 中的一项功能，允许我们对桌面流（机器人流程自动化流）应用 DLP 策略。 这有助于防止在不同系统 和应用程序之间意外或故意共享敏感数据。

• 将数据导出到 Azure Application Insights 使我们能够将应用和流程的遥测数据发送到 Azure Application Insights。 这使我们能够监控 应用和流程的性能和使用情况，并进行诊断和 故障排除。

• Power Platform 中的目录 是我们在组织中存储资产的中央仓库。 它是一个私有市场，我们可以通过它与 其他开发者共享自定义连接器、PAC 框架控件、Power Automate 流程、Canvas 应用和基于模型的应用，以及各种其他模板。

• 默认环境路由 允许我们控制哪个环境作为组织中新用户的默认环境。 这有助于确保新用户自动加入适合其角色 和职责的环境。

• 通过 Copilot 创建应用描述 是一个由 AI 驱动的功能，帮助我们创建应用描述。 它使用自然语言处理技术理解我们的需求以及我们所做的更改，从而为 我们的应用提供类似人类的描述（变更日志）。

托管环境

我们强烈建议在生产工作负载中使用托管环境。 一般来说，所有环境类型为 生产 的环境都应为托管环境。 微软在托管环境方面投入巨大，越来越多的功能正在发布。 我们可以通过发布计划跟踪即将发布的功能； 请见 https://releaseplans.microsoft.com。

在讨论环境之后，让我们探索一下为什么 环境策略 对在企业层面维护和管理成百上千的环境至关重要。

环境策略

这是我们需要决定的最关键问题之一，不仅在首次注册我们的 Power Platform 租户时需要考虑，每次启动新项目时也必须做出此决定。 环境策略定义了如何创建环境，针对每个工作负载和项目我们需要多少环境，如何应用我们组织的安全策略，如何建立基于角色的访问管理，以及环境如何与其他产品相关联，例如 Microsoft Azure 订阅、Azure DevOps 项目或 GitHub 企业存储库。

以下是最 常见的策略：

• 临时：顾名思义，这里完全没有策略。 环境是随机创建的；即使是默认环境也用于托管 生产工作负载。

• 部门级：组织中的每个部门都有自己的环境。 人力资源、财务、销售、运营及所有其他部门都有专用的生产环境，在其中托管和执行多个解决方案。 这些部门环境还可以有开发和测试环境，有时这些环境是与更多的 业务单元共享的。

• 基于项目：大型 工作负载有专用的开发、测试和生产环境。 这些项目会有开发、测试、生产环境，但较小的解决方案仍然存在于 部门环境中。

• 多租户：开发人员 在不同的租户中工作，以创建和开发 Power Platform 解决方案。 高级自动化的管道和工作流将解决方案部署到 生产租户的测试和生产环境。

下图展示了结合部门级和基于项目策略的典型部门环境策略，基于 项目需求：

图 4.5 – 一个业务单元的环境策略

这里有 共享的开发、共享的测试和共享的生产环境，用于在业务单元内部共享的工作负载。 小型工作负载和/或部门广泛使用的应用程序在这里托管。 复杂的解决方案将获得专用的基于项目的环境，包括开发、测试和生产环境类型（参见 Proj (n) Dev – Proj (n) Test 和 Proj (n) Prod，其中 n 表示唯一项目的数量）。

还有专门的环境用于培训和 Power Platform 的高级用户，他们会试验新功能。 例如，这是唯一一个启用了过程挖掘附加组件供测试的环境。 个人生产力为业务用户提供一个沙箱环境，供他们进行个人实验 用例的测试。

需要特别注意的是，这个概念为每个业务单元提供了隔离的环境，确保这些环境在部门内的治理、合规性和安全控制。 其他业务单元完全无法访问这些环境。

为了在全球拥有多个站点的全球组织中扩展这一概念，我们建议采用以下方法：

图 4.6 – 全球组织的环境策略

办公室 A/部门 A 代表 一个在区域/国家 A 内部的业务单元，使用一个共同的租户。 每个地区和办公室（业务单元或部门）都拥有相同的结构，并根据性能（靠近最终用户）和合规性要求（数据驻留要求）共享和专用环境。 解决方案的开发可以在这个租户中进行，但该概念允许我们使用更多租户进行开发。 自动化在这里是不可避免的。 ALM 和 DevOps 工具帮助我们根据项目需求自动创建环境，并将解决方案自动部署到不同的地理位置，甚至是 不同的租户。

Power Automate 流程

Power Automate 流程 与 Power Platform for Admins V2 连接器结合，在平台内提供类似 ALM 和 DevOps 的功能。 我们可以使用一些活动来创建环境、分配安全角色，并设置 DLP 策略。 这个连接器还支持跨租户集成，这是一种先前描述的多租户概念，属于 环境策略之一。

环境策略不仅仅关注 Power Platform 中的环境，它还描述了与其他周围服务的交互。 它定义了是否需要为任何新环境或新项目创建一个新的 Azure 订阅 ，或者仅在现有的 Azure 订阅中创建一个资源组。 它还为 ALM 过程提供了指导方针，例如 Proj (n) 应将其工件（托管和非托管解决方案）存储在 一个新的 Azure DevOps Services 项目中，或者存储在该 GitHub Enterprise 代码库中。 最后 但同样重要的是，该策略涵盖了安全性考虑因素，例如在环境创建过程中为管理员、开发者、制造者和用户创建 Microsoft Entra ID 安全组。 当我们完全 定义这些围绕环境策略的领域时，我们部分地解决了 DevSecOps 原则。

在熟悉环境策略的概念后，让我们深入了解第一个 Power Platform 管道，它可以在 一个部门内部部分管理这种方法。

托管管道 – 我们的第一个 CI/CD

现在我们已经 具备了一切 创建我们第一个 Power Platform CI/CD 管道的条件，借助平台内置的功能。

Power Platform 管道

Power Platform 管道 是由平台管理的 CI/CD 管道。 它们提供 ALM 功能，可以以完全自动化的方式构建和部署我们的解决方案，而无需深入了解 DevOps 工具，如 Azure DevOps Services 或 GitHub Enterprise。 当然，我们可以将这些工具集成到我们的托管管道中，将托管和非托管解决方案存储在 Git 仓库中，但这不是强制性的。 Power Platform 管道的理念是让构建和发布过程民主化，并为管理员 和开发者提供一个易于配置和使用的体验。

平台管道是一个 Dynamics 365 应用，我们需要在我们的环境之一中安装它。 对于内置的管道管理，我们只需拥有托管环境；无需 Dynamics 365 许可证。 强烈建议为安装此应用创建一个专用环境。 该环境被称为 主机环境 ，因为 它托管着管道定义、管道运行历史、安全设置以及部署工件历史，正如以下 图所示：

图 4.7 – Power Platform 管道中的环境

开发者环境 是开发者或创作者创建和修改解决方案的环境。 测试和生产环境代表 那些 目标环境 ，这些环境通过我们定义的管道部署已托管版本的解决方案。 测试和生产环境必须是托管环境，而开发者环境和主机环境可以是普通环境。 每个管道从一个开发者环境开始，并继续在一个或多个链式的 目标环境中运行。

Azure DevOps 服务管道

Power Platform 管道 Dynamics 365 应用 采用底层 Azure DevOps 服务管道和 Azure DevOps 服务部署组的完全托管方式。 这一切对我们是完全隐藏的，作为 Azure DevOps 服务上的一个 SaaS 功能提供。

作为托管环境的高级功能之一，名为 Power Platform 管道的 Dynamics 365 应用将以下 Dataverse 表带到 主机环境中：

图 4.8 – Power Platform 管道在主机环境中的 Dataverse 表

部署工件， 部署环境， 部署管道， 部署阶段， 部署阶段运行，和 部署阶段运行子操作 是标准的 Dataverse 表，我们也可以使用它们基于不同的触发条件创建审批流程。 该 部署工件 表格回溯存储了由管道创建的托管和非托管解决方案。 托管和非托管解决方案的最大大小为 128 MB。

除了这些表，Power Platform Pipeline 在 主机环境中引入了两个额外的安全角色：

• 部署管道管理员：此角色的所有者可以在 部署管道 配置中创建部署 配置。 这是一个由 Power Platform Pipelines D365 应用安装的模型驱动应用，帮助管理员配置存储在上述 Dataverse 表中的环境、阶段和管道。

• 部署管道用户：此角色的所有者可以在相应的环境中使用在部署管道配置应用中创建的管道。 如果该用户有权访问该环境，并且来自 部署管道 表格的管道记录与他们共享，那么他们有资格在该环境中的任何解决方案中使用该管道。

在解决方案视图中， Pipelines 选项卡的用户（开发者）体验如下：

图 4.9 – 解决方案中的 Pipelines 用户体验

我们处于一个解决方案中（编辑一个非托管解决方案），当配置了管道时，左侧将显示一个额外的 管道 选项卡。 在我们的示例中，下拉框中有一个管道，目标是两个环境：首先是测试环境，然后是生产环境。 由于该用户通过共享的 Dataverse 部署管道表的行访问更多的管道，下拉框提供了 更多选择。

为了能够从源环境执行在部署管道配置工具中配置的管道，必须满足以下条件：

• 我们需要与制造者共享管道记录（读取权限）。 我们应该使用适当的 Microsoft Entra 组来赋予他们这个权限。

• 我们需要具有从源环境导出解决方案的权限，并且需要具有将解决方案导入到目标环境的适当权限。 内置的 系统自定义者 和 环境制造者 安全角色具有 这些权限。

然后，管道默认会代表触发操作的用户部署管理解决方案。 如果我们希望使用服务帐户而不是用户，则支持使用服务主体。 在这种情况下，解决方案导入到目标环境是由分配的服务主体代表进行的，主要的安全优势是只有服务主体能够访问 生产环境。

部署管道的真正优势在于，我们可以在 CD 管道中引入那些额外的 质量门 ，正如我们在 第一章 中讨论的那样，通过在新版本解决方案部署到目标环境之前构建我们自己的部署审批逻辑（发布审批）。 这些质量门可以从非常简单的发布经理审批到高级自动化测试执行不等。 在每个 部署阶段 都有一个 预部署步骤要求 选项，我们可以使用该选项通过 Power Automate Cloud Flow 触发基于自定义逻辑的审批流程。 部署请求将处于待审批状态，直到获得批准。 下图显示了在部署管道配置工具中 预部署步骤要求 和 预导出步骤要求 选项：

图 4.10 – 在部署管道配置工具中创建新的部署

借助 导出前步骤要求，我们可以引入在解决方案首次从开发环境导出为托管和未托管解决方案之前执行的自定义验证逻辑。

质量门控中涉及的 云流应在主机环境中创建，其触发条件为 Dataverse 操作。 我们可以创建多个云流来响应同一个 管道事件。

目前，使用 托管管道存在一些限制：

• 多个开发者在专用的开发环境中协作同一解决方案时，需要更谨慎的流程以避免覆盖彼此的更改。 目前，管道只支持从开发环境到生产环境的单向流动。 这意味着将解决方案的最新版本拉取并部署到不同的开发环境中需要谨慎且 手动干预。

• 回滚功能部分支持。 我们已经可以在 Power Platform 管道中将解决方案的早期版本重新部署到目标环境，但我们无法像 一个步骤一样回滚整个多阶段管道。

逐步操作指南 – 创建我们的第一个 CI/CD 管道

让我们使用 Power Platform 管道创建我们的 第一个端到端的 CI/CD 管道 。 我们将做的是从 GitHub 仓库中选取一个环境模板和一个可用的解决方案。 我们将使用这些设置一个管道，将解决方案的托管版本从未托管版本中构建出来，并将其从开发环境部署到 生产环境：

1. 安装 PAC CLI（假设.NET 6.0 已安装在 我们的环境中）：

   dotnet tool install --global Microsoft.PowerApps.CLI.Tool
   

2. 安装 PowerShell 模块：

   Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
   

3. 为托管托管管道创建一个环境。 此环境将代表管道的主机环境。 我们应选择与我们开发、测试和生产环境相同的区域创建环境：

   #Authentication – in both tools
   Add-PowerAppsAccount
   pac auth create
   #Create Host Environment - Pipelinehost
   $result=New-AdminPowerAppEnvironment -Location europe -DisplayName 'Pipelinehost' -ProvisionDatabase -EnvironmentSku Production
   

4. 安装 Power Platform Pipelines Dynamics 365 应用。 PAC CLI 提供了一种简便的方式将 Dynamics 365 应用安装到环境中 （截至本书写作时没有 PowerShell cmdlet）：

   #Install Power Platform Pipelines to "Pipelinehost"
   #It takes approx. 5 minutes
   pac application install `
    --environment $resultNewEnvironment.EnvironmentName `
    --application-name "msdyn_AppDeploymentAnchor"
   

5. 创建一个 开发环境：

   pac admin create `
    --name "DevelopmentEnvironment" `
    --currency EUR `
    --region europe `
    --type Sandbox
   

6. 创建目标环境（托管 和生产）：

   #Create a production environment
   $resultProductionEnvironment=New-AdminPowerAppEnvironment -DisplayName 'Production' `
    -ProvisionDatabase `
    -Location europe `
    -EnvironmentSku Production
   #Turn on Managed Environment
   pac admin set-governance-config `
    --environment $resultProductionEnvironment.EnvironmentName `
   Pipelinehost environment:1.  Start the application.2.  Go to **Environments** under **Pipeline Setup**, open it, and click on the **New** button at the top.3.  Fill out it with the data of your developer environment as the following figure shows:
   

图 4.11 – 创建新的部署环境

1. 创建 另一个 部署环境 ，并使用您最近创建的生产环境的配置数据 以及 环境类型 目标环境，请参阅之前的图示以获取详细信息。

提示

使用 pac admin list 命令获取您最近创建的环境的环境 ID。

1. 前往 PipelineToProd 名称并保存表单，以便能够完全配置它。 如果我们希望获取 AI 部署笔记，可以在这里启用： 同样：

图 4.12 – 新的部署管道详细信息

1. 添加 开发环境（开发环境）到 已链接的开发 环境 部分。

2. 点击 新建部署 阶段 按钮，创建一个新的部署阶段。

3. 设置 名称 和 目标部署环境 ID 字段。

4. 保存 记录。

5. 设置 安全性：

   1. 将此新的部署管道 Dataverse 记录共享给开发环境中将使用此管道的用户或用户组，即 开发环境 ，在我们的例子中。

   2. 将 系统定制器 或 环境创建者 内建安全角色添加到这两个成员的 生产 和 开发环境 环境中。

   3. 将 部署管道用户 安全角色添加到 管道主机 环境中的这些成员。

6. 前往 开发者环境并导入 未管理的解决方案 从 Power Platform 企业模板中导入 IT 基础包。 你可以在 以下位置找到它： https://github.com/microsoft/Templates-for-Power-Platform/blob/main/Solution%20Packages%20For%20Manual%20Install/IT/IT%20Base%20Pack/mpa_ITBase_managed.zip。

7. 打开解决方案并寻找左侧的流水线图标（看起来像火箭）。 打开流水线并选择 PipelineToProd 流水线：

图 4.13 – 选择 PipelineToProd

1. 点击 pac pipeline deploy 命令。

2. 检查 生产环境中的部署结果。

恭喜，我们已经创建了我们的第一个 CI/CD Power 平台流水线。

为了让这个 流水线更加专业和安全，我们 可以在 Microsoft Entra ID （在 Microsoft Azure 门户内）创建一个服务主体和企业应用，并将其分配给部署阶段，如下图所示： 。

图 4.14 – 在流水线中使用服务主体

这就是 委托部署 过程 ，我们通过它将 我们的 服务主体名称 （SPN）客户端 ID 分配给流水线引擎，以便它在解决方案导入阶段使用。 创建此分配后，我们需要做最后一件事。 这就是创建一个委托的审批流程，通过使用服务主体及其客户端密钥连接到 Power Platform 流水线 Dataverse 表格，以批准部署。 下一个图将展示最简单的审批流程，通过响应 OnApprovalStarted Dataverse 动作，等待五秒钟，然后将审批状态设置为 20（20 表示已批准；30 表示 拒绝状态）：

图 4.15 – 使用服务主体的委托部署

底层 Power Platform 流水线引擎使用 此流程代表定义的服务主体而非用户执行。 通过这些额外的步骤，我们显著提高了 我们流水线的弹性和安全性。

总结

在本章中，我们了解了 Power Platform 解决方案，这些现代可执行文件可以在环境之间移动，了解了它们的升级选项，以及如何实现解决方案分层和版本管理的不同方法。 之后，我们讨论了 Dataverse，这是一款具备高级安全性和治理能力的企业级数据平台。 我们还了解了 CDM，这是一个行业广泛接受的用于建模数据的数据库模式。 我们还花时间了解了环境，它是我们解决方案的执行主机，了解了托管环境的高级功能，并详细阐述了大规模全球企业的环境策略。 在本章的最后，我们学习了 Power Platform 流水线——作为托管环境的最大特色之一——如何在幕后工作。 我们还成功创建了我们的第一个 CI/CD 流水线。

在下一章中，我们将探索用于创建这些 CI/CD 流水线和其他 ALM 自动化的专业开发者工具，部分内容我们已经在 Power Platform 流水线中看到过。

进一步阅读

• 解决方案 层： https://learn.microsoft.com/en-us/power-apps/maker/data-platform/solution-layers

• 常见数据 模型 (CDM):

  • https://learn.microsoft.com/en-us/common-data-model/use

  • https://github.com/microsoft/CDM

• 解决方案 修补： https://learn.microsoft.com/en-us/power-platform/alm/create-patches-simplify-solution-updates

• 托管 环境： https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-overview

• 环境 策略： https://learn.microsoft.com/en-us/power-platform/guidance/adoption/environment-strategy

• 企业 模板： https://github.com/microsoft/Templates-for-Power-Platform

• Power Platform 管道： https://learn.microsoft.com/en-us/power-platform/alm/pipelines

• Microsoft Entra ID 服务 主体： https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals

• 管道中的 服务主体： https://learn.microsoft.com/en-us/power-platform/alm/delegated-deployments-setup

第五章：通过 DevOps 工具简化 Power Platform 开发

在上一章中，我们使用服务主体创建了第一个 Power Platform 管道，将我们的解决方案从一个环境部署到另一个环境。 本章介绍了可以帮助我们简化 Power Platform 开发过程的专业开发 DevOps 工具。 第一个工具是 clone， push， pull， checkout等。 我们还将探索如何在 Git 仓库中管理 Power Platform 解决方案的纯文件和文件夹，以及如何通过命令行进行拉取请求和合并。 然后，我们将学习如何将 Power Platform 管道连接到这些 Git 仓库。 我们将花时间介绍 Power Platform CLI (PAC CLI)，它 允许我们在任何脚本语言中与 Power Platform 解决方案进行交互。 我们还将学习如何在 YAML (即 Yet Another Markup Language) 格式中创建 Azure DevOps 服务管道，并 理解 YAML 规范及相关方法，如变量、参数和任务。 我们还将了解 Microsoft 为 Power Platform 解决方案提供的构建任务。 最后，我们将学习 如何使用 GitHub Copilot，一个 AI 驱动的代码补全工具，可以帮助我们更高效地编写代码 。

本章结束时，我们将深入理解并掌握如何通过专业开发的 DevOps 工具（如 Azure DevOps pipelines 和 GitHub Actions）来设置端到端的 CI/CD 管道，这些工具将我们的解决方案交付到不同的 Power Platform 环境中。

在本章中，我们将涵盖以下 主要内容：

• Git – 单一的真实来源 真理之源

• Power Platform CLI

• Power Platform 构建工具用于 Azure DevOps

• GitHub Actions for Power Platform

• 托管管道 – 源 控制集成

• Power Platform 中的 Copilot 管道开发

技术要求

要使用专业开发的 DevOps 工具创建我们的第一个 CI/CD 管道，我们需要具备 以下条件：

• 一个 Power Platform 订阅。 如果我们已经拥有 Microsoft Entra ID 工作帐户，我们可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free）。 或者，我们可以加入 Microsoft 365 开发者 计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。。

• 一个 Azure DevOps Services 组织：我们可以随时创建一个 DevOps 组织 免费 （https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates）。 如果我们在 Azure DevOps 中创建一个公共项目，我们将获得多个免费管道并免费访问该服务的所有功能 – 请参见 Azure DevOps for Open Source 优惠。

• GitHub 用户名和公共仓库（https://github.com/signup），该仓库也 免费 提供给 公共仓库。

• GitHub Copilot 免费试用（https://github.com/login?return_to=%2Fgithub-copilot%2Fsignup）或访问 Microsoft Copilot（https://copilot.microsoft.com）。

• Visual Studio Code – 强烈建议使用这个免费的代码编辑器来创建、编辑和更新本章节中的 YAML 文件。 我们可以通过 https://code.visualstudio.com/download在任何平台上下载 Visual Studio Code，并借助 Power Platform、Git、Azure DevOps 管道和 GitHub 工作流的 VS Code 插件，我们可以对更改进行语法高亮和语义检查。 通过 Git 插件，我们还可以管理 Git 仓库。 有关更多信息，请参见 进一步阅读 部分，了解 Visual Studio Code 的更多内容。 另外，我们可以直接访问 https://vscode.dev 在我们喜欢的浏览器中在线使用 Visual Studio Code 编辑器，编辑任何文件并打开一个 远程仓库。

• 本章节的代码文件可以从我们的 GitHub 仓库下载 ，链接为 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter05。

Git——单一的真理来源

在定制开发项目中，源代码保存在 版本控制系统中。这些 系统允许开发人员在同一个代码库上协作工作，以便他们可以不断引入新功能和/或修复 bug，而不会与他人的更改冲突。 我们使用此类代码库（版本控制系统）的原因之一是提供生产环境中的代码（运行中的应用程序）与在推送版本到生产环境之前所做的源代码更改之间的端到端前后追溯性。 在现代的 DevOps 工具中，项目管理部分，开发工作项直接与开发人员所做的代码更改相链接。 版本控制系统提供了项的历史，并支持跨多个文件和文件夹的事务性更改，这些更改存在于代码库中。 这些更改 通常以 作为 版本或 历史树的形式表示。

为了让开发人员以最有效和高效的方式工作 并行，版本控制系统提供了分支功能。 一个 分支，顾名思义，是代码行的快照——一个分支，它随后 管理自己的历史。 我们提交（回放）到此分支的更改在我们创建分支时的原始分支中不可见。 主线或根——主分支本身——在这种方法中也被表示为一个分支。 在子分支中完成待办事项后，我们 合并 这些更改回父分支。 分支可以在任何深度上创建，但一般来说，我们建议保持分支层次结构的深度尽可能平坦，以避免后续的集成债务。 分支将进行中的工作与稳定且 已测试的代码分开。

为了维护和控制一个健康的开发环境，我们需要定义我们的分支策略。 一个 分支策略 是管理版本控制系统中分支的一组指南和最佳实践。 它帮助团队组织代码库、简化开发流程，并在合并代码时尽量减少冲突。 有几种流行的分支策略。 团队需要选择适合他们开发流程的分支策略，并且要始终如一地遵循它，以确保顺畅的协作和高效的代码管理。 让我们来看一下最流行的两种 分支策略：

• 基于主干的开发 是一种 版本控制管理实践，开发人员将小的、频繁的更新合并到一个核心分支 叫做 主干 或 主分支。这种方法的主要特点是，唯一长期存在的分支是主分支，且始终可部署。 开发人员不能直接将更改提交到主分支，而是他们在短期分支上工作，并将更改频繁地合并到主分支。

• Git Flow / GitHub flow 最初是 Git Flow 定义了几个长期存在的分支，比如 发布、热修复和补丁分支，旁边还有主分支。 在过去十年里，软件行业发生了很大的变化，软件开发团队通常只维护一个版本的软件——即最新版本。 这意味着不再需要维护这么复杂的分支层次结构，这也是从 Git Flow 转向 GitHub flow 的原因。 GitHub flow 是一种 轻量级、基于分支的工作流，支持定期进行部署的团队和项目。 这个工作流在开发人员中非常受欢迎，因为它允许他们在不影响主代码库的情况下，进行新特性的开发、修复 bug 或进行实验。 一旦某个分支上的工作完成，就可以通过拉取请求将其合并回主代码库。 GitHub flow 与基于主干的开发非常相似，但它包含了 GitHub 特有的功能，如 拉取请求。

Git 是 最广泛使用的版本控制系统。 它是一个 分布式版本控制系统，这意味着我们可以将一个代码库下载到自己的开发机器上，并且在没有互联网连接的情况下，我们可以通过分支和修改来工作。 当然，如果我们想要将我们的更改传播回团队，我们需要连接互联网并 上传 我们的更改。 市场上也有 集中式版本控制系统。 这些系统需要持续的互联网连接，这通常会减慢与此类代码库的交互速度。 一般来说。

Git 是一个 快速、可扩展、分布式的版本控制系统，并且是开源的。 有很多 DevOps 工具提供了开源 Git 引擎，比如 GitHub Enterprise、Azure DevOps Services 和 GitLab。 当然，这些引擎是经过定制的，服务提供商可以实现 他们自己的操作方式，并将 Git 提供为 软件即服务 （SaaS）产品，但客户端 API 与任何这些分发版本兼容。 这些分发版。

通常，版本控制系统 管理纯文本文件，因为这些文件在发生冲突时可以被开发者合并（冲突是可读的）。 随着软件历史的发展，越来越多的二进制文件，如图像、视频、音频文件、3D 对象和媒体文件，已成为软件解决方案的一部分。 在软件开发的早期，这些文件与代码库并行维护，尽管它们也是由开发者修改/分支的版本的一部分。 Git 已经支持大文件 （Git 大文件存储）和大规模单体代码库，简化了从其他版本控制系统的迁移。 控制系统的迁移。

单体大规模代码库

例如，Microsoft Windows 的代码库，大小为 250 GB，维护在一个大型的 Git 单体代码库中，并托管在 Azure DevOps 服务项目中。

Git 命令行界面 (CLI) 是一个 强大的工具，允许开发人员使用命令行终端与 Git 仓库进行交互。 Git CLI 可在所有主要操作系统上使用，包括 Windows、macOS 和 Linux。 一些常用的 Git 命令有： 以下是一些：

• git clone: 这个 命令 用于在你的 本地机器上创建远程仓库的副本。

• git pull: 这个 命令用于从远程仓库获取并合并更改到你的 本地仓库。

• git push: 这个 命令用于将本地仓库的更改（提交和分支）上传到 远程仓库。

• git commit: 这个 命令用于将更改保存到本地仓库。 它会在仓库历史中创建一个新的 提交 对象，记录仓库的当前状态。

• git branch: 这个 命令用于管理 Git 仓库中的分支。 它可以用于列出、创建、删除以及 重命名分支。

• git checkout: 这个 命令用于在分支之间切换，或者从 版本库中恢复工作目录中的文件。

• git merge: 这个 命令用于将一个分支的更改合并到另一个分支。 它将指定提交的更改集成到 当前分支。

通常，我们克隆一个仓库，创建一个本地分支，提交更改，将分支推送回远程源，最后将更改合并回主分支。 这个最后的操作是一个特殊操作，根据不同的 Git 发行版，可能被称为拉取请求，如 GitHub 或 GitLab。 我们也可以在没有拉取请求的情况下合并分支。

拉取请求 是一个 开发人员通知团队成员他们已完成一个功能的机制。 一旦他们的功能分支准备好，开发人员就会通过在线代码库提交拉取请求。 然后，其他团队成员会审查代码并提出意见和建议。 一旦团队达成一致，认为代码已经准备好，就可以将其合并到主代码库中。 拉取请求是一个促进代码审查 和团队协作的方式 在 开发团队中。

拉取请求

拉取请求 不仅仅是一个 git merge 操作。 像 GitHub 或 Azure DevOps 服务这样的 DevOps 工具提供了网页 UI 支持以及自己的 CLI 工具来发起拉取请求 在分支上。

理解了 Git 的关键概念后，我们来看一下它是如何与我们的 Power Platform 解决方案结合的。 正如我们之前讨论过的，在 第四章中，Power Platform 解决方案 有托管和非托管两种格式。 根据解决方案的内容，托管和非托管解决方案之间的区别可能会有很大差异。 例如，如果一个解决方案包含 PowerApps 应用程序，那么托管的解决方案会包含几个文件，其中一个是 msapp 文档，其中包括 PowerApps 画布应用的所有资产，以压缩格式保存。 另一方面，非托管解决方案将由 XML 和 JSON 文件组成，按照一个定义明确的文件夹结构来描述解决方案及其所有资产，如应用程序、流程、机器人、连接引用等，以纯文本 格式表示。

而这正是版本控制系统发挥重要作用的地方，正如下图所示：

图 5.1 – 开发者环境及其相应的子分支

应用开发者和开发人员（DevA 和 DevB 在我们的案例中）使用专门的开发环境来构建解决方案。 当他们创建应用程序的第一个版本时，他们将托管和非托管的 Power Platform 解决方案——后者作为解包形式——提交到自己从主分支创建的子分支中。 之后，他们在这些分支上工作，并在相应的环境中进行工作，通过不断同步环境与分支之间的变化。 当他们准备好时，他们提交拉取请求，将子分支中的更改合并回主分支。 理想情况下，没有合并冲突，变更会顺利地集成到主分支中。 合并冲突 是 冲突的更改——即在父分支和子分支中相同位置的文件发生了变更。 如果发生合并冲突，拉取请求将被拒绝，开发人员需要将主分支的更改合并回开发分支，并在那里解决冲突。 在 Power Platform 中，这不仅仅意味着解决代码层面的冲突，还需要将非托管解决方案加载回开发环境，检查一切是否按预期工作，然后发布更改。 之后，我们需要将解决方案导出回开发分支，并重新提交 拉取请求。

总体而言，分支和子分支使得开发人员即使在同一个 Power Platform 解决方案中也能并行工作，但我们需要特别注意，让开发人员处理不同的资产 在解决方案中。

了解了 Git 的功能后，让我们来了解一下我们可以用来导出和导入解决方案的工具 Power Platform。

Power Platform CLI

我们在前几章中已经见过一些 PAC CLI 命令，例如登录到不同的环境或将 Power Platform 管道作为 Dynamics 365 应用程序安装到我们的环境中。 除了这些命令，PAC CLI 还支持许多其他命令和功能，我们可以代表服务主体进行身份验证，并管理我们的解决方案、环境、部署、管道等。 PAC CLI 的最大优势之一是它可以在任何平台上运行，并可以与任何 DevOps 工具集成。

PAC CLI 最常用的命令之一是 以下这些：

• The pac admin 命令 组提供一组命令，用于与您的 Power Platform 管理员帐户一起工作，例如创建环境、创建服务 主体、将 Microsoft Entra ID 组分配给环境等。

• The pac application 命令 组用于列出并安装来自 AppSource 的可用 Dataverse 应用程序。 我们使用了 pac application install 将 Power Platform 管道作为 Dynamics 365 应用程序部署到我们的生产环境中， 第四章。

• The pac auth 命令 组提供一组命令，用于在不同的服务中进行身份验证，例如环境或整个租户。 我们可以使用服务帐户以及服务主体。 我们的凭证会被本地存储 （如有需要）。

• The pac canvas 命令 与 Power Apps .msapp 文件 一起使用。这些文件是在我们直接从 Power Apps Studio 导出画布应用程序时创建的，或者作为我们 Power 平台解决方案。

• The pac catalog 命令 组提供用于管理 pac catalog 命令组的命令，包括 pac catalog install ，它将在目标环境中安装目录项，以及 pac catalog list ，它列出当前 Dataverse 组织中的所有已发布目录项。

• The pac copilot 命令 组提供用于管理聊天机器人和 AI Builder 模型的命令（包括新型大语言模型等）。 一些可用的命令包括 pac copilot predict ，该命令将文本或提示发送到 AI 模型， pac copilot create 用于使用现有模板文件作为参考创建新机器人， pac copilot list 用于列出当前或目标 Dataverse 环境中的虚拟代理。

• The pac package 命令组是一组用于管理包的工具和实用程序。它包括一些命令，比如pac package add-external-package用于将一个外部的包添加到 Dataverse 解决方案系统中，pac package add-reference用于向 Dataverse 解决方案项目中添加引用，以及pac package add-solution用于将一个预构建的 Dataverse 解决方案文件添加到 Package Deployer 项目中。请注意，我们在第四章中也讨论了 Power Platform 企业模板中的 Package Deployer。

• The pac pcf 命令组用于与pac pcf init一起初始化当前目录中的新 Power Apps 组件框架项目，并且与pac pcf push一起将组件推送到 Power Apps 组件框架开发环境中。

• The pac pipeline 命令组用于与 Power Platform 管道一起工作。举例来说，pac pipeline deploy 用于启动管道部署，而pac pipeline list 用于列出给定环境中的管道。此命令组为管理员和操作团队提供了以完全自动化的方式启动部署的选项，正如我们在第四章中讨论的那样。

• The pac plugin 命令组用于与pac plugin init一起初始化一个新的 Dataverse 插件类库目录，而pac plugin push则用于将插件导入到 Dataverse 中。我们可以使用基于.NET Framework 的插件，在 Dataverse 引擎的上下文中响应服务器端的 Dataverse 事件。

• pac powerpages 命令组 用于 管理 pac powerpages list 用于列出当前 Dataverse 环境中的所有 Power Pages 网站，而 pac powerpages download 用于从当前 Dataverse 环境下载 Power Pages 网站内容，以便将其迁移到另一个环境，配合 pac powerpages upload。

• pac solution 命令组 用于操作 与 pac solution 命令组包括 pac solution init，用于初始化一个基于 MSBuild 的 cdsproj 文件，适用于组件框架组件； pac solution add-reference，用于将当前目录中的项目引用添加到指定路径下的项目；以及 pac solution add-solution-component，用于将一个或多个解决方案组件添加到 Dataverse 中的目标非托管解决方案。 解决方案的导入和导出也通过相应的 pac solution 命令进行支持。

PAC CLI 和 Power Platform PowerShell 模块

PAC CLI 是 Power Platform 的下一代命令行工具，能够在任何操作系统平台上运行。 PowerShell 管理功能正在不断迁移到 PAC CLI，以便在未来达到功能上的一致性。 PAC CLI 和 PowerShell 模块是对 Power Platform 的底层 REST API 端点的封装。

要安装 PAC CLI，我们需要先确保机器上已部署 .NET Core 3.1 或更高版本（推荐使用 .NET 6）。 然后，我们可以在喜爱的终端（Windows 上使用 CMD，Linux 上使用 Bash，macOS 上使用 Terminal）中执行以下命令：

 dotnet tool install --global Microsoft.PowerApps.CLI.Tool

现在我们已经了解了 PAC CLI 中命令的广度和深度，在接下来的章节中，我们将了解该 CLI 工具如何被 Azure DevOps Services 和 GitHub Enterprise 使用。

Power Platform 构建工具用于 Azure DevOps

Azure Pipelines 作为 Azure DevOps Services 中的一个强大功能脱颖而出，提供 全面的 持续集成 （CI）和 持续交付 （CD）服务。 它兼容您选择的 Git 提供商（GitHub 或 Azure DevOps），并支持跨多个主要云提供商进行部署，包括微软 Azure。 此服务简化了构建、测试和部署代码库的过程。 它支持广泛的编程 语言和平台，例如 .NET、Java、Node.js、Android、Xcode 和 C++，并支持使用各种测试框架和服务。 此外，Azure Pipelines 还支持在命令行、PowerShell、Bash 或 Shell 中执行脚本，作为自动化工作流的一部分。

Azure Pipelines 还提供了运行脚本和流水线任务所需的基础设施。 Azure Pipelines 代理 是 容器（虚拟机规模集中的虚拟机），执行我们的作业（流水线任务）。 代理被安装在这些机器中，并通过 HTTP 出站连接到 Azure DevOps 端点，拉取它们需要执行的活动。

代理有不同类型，包括微软托管代理、自托管代理和 Azure 虚拟机规模集 代理：

• 微软托管代理 提供了一个 无忧的解决方案，用于执行您的作业。 这些代理由微软全面管理，确保始终使用您 YAML 流水线中指定的最新虚拟机映像，而无需我们进行任何维护或升级。

• 自托管代理 是 我们在自己的虚拟机上设置并维护的代理。 此选项使我们能够更好地控制代理使用的机器规格和操作系统映像。

• Azure 虚拟机规模集代理 是 一种自托管代理，充分利用虚拟机规模集的自动扩展功能。 Azure DevOps 根据 流水线队列的大小扩展或缩减虚拟机。

在 Azure Pipelines 中， 作业 是一系列按顺序运行的步骤，作为一个单元执行。 每个管道至少有一个作业，作业是可以调度运行的最小工作单元。 作业可以组织成阶段，并且你可以指定条件和依赖关系来控制作业的运行时机。 作业可以在 Microsoft 托管的代理、自托管的代理或 Azure 虚拟机规模集代理上运行，并且可以直接在代理的主机机器上或在容器中运行。 Azure Pipelines 支持在 Linux、macOS 和 Windows 上并行运行作业。 你可以在 Azure DevOps Web 门户中创建和配置管道，使用经典的用户界面编辑器，也可以使用最新的基于 YAML 的脚本编辑器。 我们更倾向于后者，因为这种情况下，YAML 文件的版本控制管理也是可用的。

Azure Pipelines 的高级功能，如 Microsoft 托管和自托管构建代理的基础设施和 拓扑，超出了本书的范围，但你可以在 进一步 阅读 部分找到更多信息和学习模块。

在 Azure Pipelines 之上， Microsoft Power Platform Build Tools（Microsoft Power Platform Build Tools for Azure DevOps） 提供了 Azure DevOps 中的附加任务，可用于自动化与 Microsoft Power Platform 上构建的解决方案相关的常见构建和部署任务。 其中一些可用任务包括 Power Platform 工具安装程序，该程序安装 Power Platform 工具（包括 PAC CLI 在代理中的安装）。 这是每个构建和发布管道开始时的必选步骤，尤其是当我们希望使用其他 Power Platform 构建任务时。 这些构建工具适用于画布应用、模型驱动应用、Microsoft Copilot Studio、云端和桌面流程、Power Pages 网站、AI Builder 模型、自定义连接器以及数据流，适用于所有可以添加到 解决方案中的内容。

每个构建任务都在后台使用 PAC CLI，Power Platform 包装器为 Azure DevOps Pipelines 和 GitHub Actions 提供了一个通用接口：

图 5.2 – Power Platform 构建工具和 GitHub Actions 架构

这意味着，当我们 使用类似 PowerPlatformExportSolution@2 的任务时， 该管道任务会通过包装器执行相应的 PAC CLI 命令， 并使用适当的参数。 让我们来看一个导出受管解决方案的管道，它解压并发布到构建工件中（请参见 .pipelines/powerlatform-exportsolution.yml 文件，位于 Chapter05 文件夹中， GitHub 仓库中）：

 trigger:
- none
pool:
  vmImage: ubuntu-latest
steps: - task: PowerPlatformToolInstaller@2 inputs:
    DefaultVersion: true - task: PowerPlatformExportSolution@2 inputs:
    authenticationType: 'PowerPlatformSPN' PowerPlatformSPN: '[Service_Connection_Name]' SolutionName: '[Our_Solution_Name]'
    SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/Solution/[Our_Solution_Name].zip'
    Managed: true
    AsyncOperation: false
    MaxAsyncWaitTime: '60' - task: PowerPlatformUnpackSolution@2 inputs:
    SolutionInputFile: '$(Build.ArtifactStagingDirectory)/Solution/TranslatorSolution.zip'
    SolutionTargetFolder: '$(Build.ArtifactStagingDirectory)/Solution/out'
    SolutionType: 'Managed'
- task: PowerPlatformChecker@2
  inputs: PowerPlatformSPN: [Service_Connection_Name]' FilesToAnalyze: '$(Build.ArtifactStagingDirectory)/Solution/*.zip'
    RuleSet: '0ad12346-e108-40b8-a956-9a8f95ea18c9'
- task: PublishBuildArtifacts@1
  enabled: true
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'Translator'
    publishLocation: 'Container'

The PowerPlatformExportSolution@2 使用服务连接（ PowerPlatformSPN: 'PowerPlatformE5-Default' ）连接到 Dataverse。 服务连接 允许 您连接到外部和远程服务，以在 您的管道中执行任务。 它们提供了一种方法，能够使用外部服务对 Azure DevOps 进行身份验证和授权， 使 Azure DevOps 能够代表您或代表服务主体访问资源并执行操作。 为 Power Platform 提供了专用的服务连接。

我们刚刚发现，如何使用熟悉的 Azure Pipelines 基于 YAML 的方法来进行 Power Platform CI/CD， 就像我们为其他自定义开发项目所做的那样。

GitHub Actions for Power Platform

GitHub Actions 最初由与创建 Azure Pipelines 相同的工程团队设计和开发， 这是在微软收购 GitHub 后的事情。 在收购时，GitHub 甚至没有支持 Azure Pipelines 提供的任何自动化功能。

因此，GitHub Actions 引擎、基础设施、代理（在 GitHub 中是 runners）和概念与 Azure DevOps 的几乎相同，也不奇怪。 在某些情况下，GitHub Actions 甚至更好。 它可以提供比 Azure Pipelines 更多的触发条件。 例如，GitHub Actions 可以响应 GitHub 问题中的变化——包括拉取请求评论、Wiki 页面上的变化，以及 GitHub 项目相关资产的其他变化。 这些操作是轻量级函数，触发框架可以通过 webhook 轻松扩展。

GitHub 有自己的构建代理，这些代理被称为 GitHub runners。

在幕后，托管 GitHub Actions 的代理运行时、Windows 服务和 Linux/macOS 守护进程与 Azure DevOps 服务中使用的运行时几乎相同。GitHub 运行器是运行 GitHub Actions 工作流的虚拟机。它们有两种类型：GitHub 托管和自托管。对于专业人员，GitHub 提供了一系列托管虚拟机，这些虚拟机具有更多的内存、CPU 和磁盘空间，供 GitHub Team 和 GitHub Enterprise Cloud 计划的客户使用。这些较大的运行器由 GitHub 托管，预装了运行器应用程序和其他工具。GitHub 托管的运行器使 GitHub Enterprise 计划的客户能够轻松、安全地将其 CI/CD 机器连接到云端或本地的其他 DevOps 服务，例如Artifactory、Nexus或任何其他服务，利用保留的静态 IP 范围或通过使用 Azure 虚拟网络来实现。在公共 GitHub 仓库的情况下，每个月前 2,000 分钟的 GitHub 托管运行器执行是免费的。

为了获得更细粒度的控制，您还可以将运行器组与标签结合使用。运行器组只能包含大型运行器或自托管运行器作为成员。这样，专业人员可以灵活选择最适合其特定需求的运行器。GitHub 运行器也可以在 Docker 容器中运行。通过这样做，我们甚至可以轻松地构建基于 Kubernetes 的构建/部署集群。

GitHub 运行器和 Azure DevOps 代理都是开源项目，欢迎来自世界各地的贡献者（请参阅“进一步阅读”下的 GitHub 仓库链接）。

关于工作流定义：YAML 标签和关键字也存在一些差异，但主要设计原则是相同的。

Azure DevOps 服务与 GitHub

在行业中，一个常见的问题是 Azure DevOps Services 还是 GitHub 是未来的趋势。 在撰写本文时，微软的策略是建议绿色场景组织（即刚开始 DevOps 之旅的组织）使用 GitHub。 如果一个组织已经使用了 Azure DevOps，那么微软建议只在能带来显著优势的领域引入 GitHub。 这种显著优势现在体现在 GitHub Copilot。在过去几年中，我们看到对 GitHub 功能的投资比 Azure DevOps Services 大了 5-10 倍。

在下一节中，我们将仔细研究 GitHub 工作流和操作 的实际应用。

管理管道 – 与 Git 的源代码控制集成

在 第四章中，我们创建了第一个 Power Platform 管理的管道，该管道通过服务主体将我们的 mpa_ITBase 解决方案从开发环境部署到生产环境。 在本节中，我们将继续我们的旅程，并基于关于 PAC CLI 的经验，构建针对 Azure DevOps Services 和 GitHub Actions 的工具，为 Power Platform 提供支持，我们将借助 GitHub Actions for Power Platform 和 Power Platform 管道上下文中的 Dataverse 触发事件，将我们的解决方案构件提交到 GitHub 仓库。

让我们来看看在我们的 Power Automate 云流中，可以在 Pipelinehost 环境中使用的事件，以响应部署管道中的某些变化：

• OnApprovalStarted – OnApprovalCompleted：当部署阶段配置了审批流程时，这些事件会在部署解决方案之前触发。 我们通常使用这一步骤通知发布经理或环境拥有者关于 计划部署的情况。

• OnPredeploymentStarted – OnPredeploymentCompleted：这些事件在将我们的解决方案发布到部署阶段之前发生。 我们可以利用这些事件在目标环境中做一些配置，比如在解决方案部署前更新环境变量和导入（静态）数据。

• OnDeploymentRequested – OnDeploymentStarted – OnDeploymentCompleted：这些事件发生在将解决方案部署到 部署阶段的过程中。

Dataverse 管道事件

Dataverse Power Platform 管道相关事件在每个部署阶段触发，无论阶段和管道的数量如何。 管道触发器提供额外的属性来过滤出我们感兴趣的管道和阶段。

借助这些 构建模块，我们可以制定不同的策略，来管理我们的管道以及如何在 Power Platform 环境之外维护我们的解决方案。 我们应该决定 以下事项：

• 我们是否为每个解决方案使用单独的 Git 仓库？ 或者，我们是否计划将多个解决方案存储在同一个 Git 仓库中？ 我们是否计划引入管道模板化以便于 重用？

• 我们是否为每个环境引入一个 Git 仓库？

• 我们是否计划将部署到不同部署阶段的解决方案工件存储在不同的 子分支中？

• 我们是否使用拉取请求将子分支中的最新更改合并回主分支？ 我们是否在管道中使用拉取请求触发器以完成生产环境中的部署？ 这也意味着受管管道不会到达生产环境，仅到达 预生产/测试环境。

• 我们是否计划只存储已经成功部署到生产环境的部署工件在主分支上？ 我们是否应该考虑分支策略 呢？

没有万灵药来回答这些问题，因为所选的策略真正取决于组织的成熟度、项目的复杂性以及内部定义的整体 DevOps 流程。 。

下图展示了一种可能的方法，通过 Power Platform 管道在部署到生产环境后将解决方案提交到主分支：

图 5.3 – Git 与 Power Platform 管道的集成

我们通过 Power Platform 管道启动的部署过程中， 生成了托管和非托管解决方案。 当托管管道运行时，其他开发人员无法排队执行此管道，从而保证了互斥性。 生成的工件存储在 Dataverse DeploymentArtifacts 表格中，位于 Pipelinehost 环境中。 随着包（托管解决方案）通过管道阶段（测试 和 生产 环境，以我们为例），前述事件会被触发。 我们使用 OnDeploymentCompleted 事件来执行我们的云流，它将通过 HTTP POST调度我们的 GitHub 工作流，并下载部署工件，解压并提交到 主分支。

为了能够从 Dataverse 下载工件，我们创建一个服务主体，并在 GitHub 流程中使用 Bash 脚本直接调用 Dataverse Web API，通过 OData 协议 下载我们的部署工件。

让我们使用 PAC CLI 创建一个服务主体，供我们在 GitHub 工作流中使用：

 # First we need to authenticate
pac auth create
# List our environments to find the URL of the environment hosting our Power Platform pipelines (HOST)
pac admin list
# Create the service principal
pac admin create-service-principal -env <<URL>> -n VersionControlSPN --role "System Administrator"

最后的调用 不仅需要在 Power Platform 租户中具有管理员权限，还需要在 Microsoft Entra ID 中具有管理员权限（ Application.ReadWrite.Allpermission 角色）。 该调用的输出包含应用注册的客户端密钥、应用 ID（客户端）和租户 ID，以及相应的企业应用。 此命令还通过将其作为应用用户添加到环境中，将该服务主体注册到 Dataverse。 我们需要保存最后一个命令的输出，以便以后在我们的 GitHub 工作流中使用客户端 ID、客户端密钥和租户 ID：

 pac admin create-service-principal -env https://org48448b9d.crm4.dynamics.com -n VersionControlSPN
Connected as XXXXXX@YYYYYYY.onmicrosoft.com
Creating Entra ID Application 'VersionControlSPN'... Done
Creating Entra ID Service Principal... Done
Connected to... pipelinehost
Registering Application '7be14619-8224-4235-9c6b-2701fb98f203' with Dataverse... Done
Creating Dataverse system user and assigning role... Done
Application Name         VersionControlSPN
Tenant Id                XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Application Id           XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Service Principal Id     XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Client Secret            YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Client Secret Expiration 2025\. 02\. 24\. 16:03:31 +00:00
System User Id           XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

创建了带有客户端 ID 和客户端密钥的服务主体后，让我们继续进行使用它们的 GitHub 工作流。

GitHub 工作流

现在是时候在我们的一个 GitHub 仓库中设置 GitHub 流程了。 我们将在接下来的步骤中使用 Visual Studio Code 来创建我们的 YAML 文件。 另外，我们也可以使用 GitHub UI 来创建 我们的工作流：

1. 在选定的 GitHub 仓库中创建名称为 TENANT_ID、CLIENT_ID 和 CLIENT_SECRET 的仓库密钥。

2. 创建一个名为 downloadunpackcommitbash.yml 的 GitHub 流并设置其触发条件为 workflow_dispatch：

    name: DownloadUnpackCommitBash
   run-name: VersionControlIntegration-Bash
   on:
     workflow_dispatch:
   

3. 引入由 Power Automate 云流调用的输入参数：

    inputs: artifact_url:
           description: "The URL of the Dataverse record ID for the artifact created by the pipelines." required: true
         solution_name:
           description: "Name of the solution in Dataverse"
           required: true
         user_name:
           description: "User name for the commit"
           required: true
         user_email:
           description: "User name email address"
           required: true
         source_branch:
           description: "Branch for the solution commit"
           default: "main"
           required: true
         target_branch:
           description: "Branch to create for the solution"
           required: false
         commit_message:
           description: "Message to provide for the commit"
           default: "test without Dataverse trigger"
           required: true
   

4. 配置标准权限和 GitHub 托管构建代理的操作系统：

    permissions:
     contents: write
   jobs:
     export-unpack-commit:
       runs-on: ubuntu-latest
   

5. 在构建代理中检出源分支：

    steps:
         - uses: actions/checkout@v3
           with:
               ref: ${{ github.event.inputs.source_branch }}
   

6. 如果指定了目标分支，则创建新分支：

    # Commit changes to the existing or new branch
        - name: create new branch if specified
          shell: bash
          run: |
           if [ -n "${{ github.event.inputs.target_branch }}" ]; then
                 git checkout -b ${{ github.event.inputs.target_branch }} ${{ github.event.inputs.source_branch }}
            fi
   

7. 执行一个 Bash 脚本，从 Microsoft Entra ID 请求具有 Dataverse 范围的访问令牌，使用由 PAC CLI 生成的租户 ID、客户端 ID 和客户端密钥。获取令牌后，我们访问 Dataverse Web API 端点的表（DeploymentArtifacts），并使用 curl 下载由 GUID 标识的工件：

    # Export the solution from the artifact created by pipelines
        - name: download solution from artifact
          env:
              CLIENT_ID: ${{secrets.CLIENT_ID}}
              TENANT_ID: ${{secrets.TENANT_ID}}
              CLIENT_SECRET: ${{secrets.CLIENT_SECRET}}
          shell: bash
          run: |
              aadHost="login.microsoftonline.com"
              #adding $value to the end of the artifact url to download binary content
              url="${{ github.event.inputs.artifact_url }}/\$value"
              dataverseHost=$(echo $url | cut -d'/' -f3)
   body="client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}&grant_type=client_credentials&scope=https://$dataverseHost/.default"
              OAuthReq=$(curl -s -X POST "https://$aadHost/${TENANT_ID}/oauth2/v2.0/token" -d $body)
               spnToken=$(echo $OAuthReq | jq -r .access_token)
               # Download the managed solution
               response=$(curl -H "Authorization: Bearer $spnToken" \
                 -X GET $url \
                 -o "${{ github.event.inputs.solution_name }}_managed.zip")
               # Download the unmanaged solution (for now we will need to use string manipulation to get the unmanaged solution URL, until the API provides this value)
               unmanaged_artifact_url=$(echo "$url" | sed 's/artifactfile/artifactfileunmanaged/g')
               response=$(curl -H "Authorization: Bearer $spnToken" \
                 -X GET $unmanaged_artifact_url \
                 -o "${{ github.event.inputs.solution_name }}.zip")
   

8. 使用 GitHub Power Platform 操作（unpack-solution），我们将解决方案的托管版和非托管版解压到构建代理上的仓库：

    # Unpack the solution to a folder named as the solution
         - name: unpack solution uses: microsoft/powerplatform-actions/unpack-solution@v0 with:
             solution-file: "${{ github.event.inputs.solution_name }}.zip"
             solution-folder: "${{ github.event.inputs.solution_name }}"
             solution-type: 'Both'
             process-canvas-apps: false
             overwrite-files: true
   

9. 在构建代理中将更改提交到目标分支或源分支：

    # Commit changes to the existing or new branch
        - name: commit changes
          shell: bash
          run: |
            rm -rf ${{ github.event.inputs.solution_name }}.zip
            rm -rf ${{ github.event.inputs.solution_name }}_managed.zip
            git config user.name ${{ github.event.inputs.user_name }}
            git config user.email ${{ github.event.inputs.user_email }}
            git pull
            git add --all
            git commit -am "${{ github.event.inputs.commit_message }}" --allow-empty
   

10. 将更改推送到远程源：

     # Push the committed changes to the source branch
         - name: push to branch
           shell: bash
           run: |
             if [ -n "${{ github.event.inputs.target_branch }}" ]; then
               git push origin "${{ github.event.inputs.target_branch }}"
             else
               git push origin "${{ github.event.inputs.source_branch }}"
             fi
    

Dataverse Web API – OData 协议

我们使用 Dataverse Web API，通过 OData 协议的 REST API 查询 Dataverse 表和记录。我们 GitHub 工作流的输入参数，artifact_url，期望以下字符串以获取通过其唯一标识符和列 ArtifactFile 标识的记录，https://.$Value，指向二进制内容。由于我们使用的是 Bash，而 Bash 将 $ 符号视为特殊字符，因此我们需要使用转义字符（反斜杠）来将 $value 添加到工件 URL 的末尾。

为了测试我们的 GitHub 流，我们可以通过在 GitHub UI 中提供输入手动使用 run workflow 命令：

![图 5.4 – GitHub – 手动运行工作流

图 5.4 – GitHub – 手动运行工作流

现在，我们有一个 GitHub 工作流，它可以下载部署工件并将其提交到子分支或主分支，具体取决于输入的参数。 查看 .github/downloadunpackcommitbash.yml 文件，它位于书籍 GitHub 仓库的 Chapter05 文件夹中，包含整个 GitHub 工作流。 同样的工作流也可以通过 PowerShell 命令实现。 查看 .github/ downloadunpackcommit.yml 文件，它位于 Chapter05 文件夹中，了解更多细节。

良好的做法是先将更改提交到功能分支，然后再提交拉取请求，因为我们从不直接在主分支上工作。 通常还会有分支策略，禁止开发人员直接在主分支上工作。 另一方面，GitHub 工作流可以在创建并提交更改到 功能分支后立即启动拉取请求。

我们可以使用完全相同的方法，结合 Azure DevOps 服务 的仓库、管道以及 Power Platform 管理管道 同时 考虑以下几点 ：

• 机密作为变量或在 YAML 管道中的变量组中存储。

• GitHub 输入映射到 Azure DevOps 管道变量（而不是参数）。

• 我们可以使用与 GitHub 工作流相同的 Bash 脚本。 无需更改任何内容。 微软托管的构建代理支持 Ubuntu Linux 发行版。

• 我们需要通过 Power Platform构建工具任务（PowerPlatformToolInstaller@2）在构建代理中安装 PowerPlatform 工具。

• 我们需要使用PowerPlatformUnpackSolution@2任务来解包解决方案。

Dataverse 与 Power Automate 云流

在创建了 DevOps 部分后，让我们介绍一个 Power Automate 云流程，它将响应 OnDeploymentCompleted 事件，在 适当的部署阶段。 我们将在 Pipelinehost 环境中创建此云流程：

1. 访问 https://make.powerautomate.com 并选择我们的 Power Platform 管道所在的环境。

2. 然后我们进入 我的流程 面板，打开 新建流程 下拉菜单，并点击 自动化 云流程。

3. 我们可以将流程命名为 ManagedPipelineOnDeploymentCompletedFlow 并选择 当执行某个操作时 作为 Dataverse 的触发条件。

4. 创建流程后，我们需要提供以下值作为触发器操作的参数：

图 5.5 – Dataverse – 当执行某个操作时

请注意，在这里，我们使用服务主体连接到底层的 Dataverse，这不是 不是 我们在 GitHub 工作流中使用的服务主体。 这是我们在 第四章中创建的服务主体，用于 代表 管道部署。

1. 我们可以使用触发器操作的输出数据（ActionOutputs ArtifactName, ActionOutputs DeploymentPipeIineName, ActionOutputs DeploymentStageName）来引入多个条件，只对我们的管道（PipelineToProd）以及最终部署阶段（Production）做出反应。

2. 在 引入这些条件来限制我们的云流执行仅限于此受管管道后，我们需要从 DeploymentStageRun Dataverse 表中获取一些额外的数据，这些数据与本次运行相关（通过 StageRunId来标识）。 我们使用 按 ID 获取一行数据 操作，并结合触发器活动中的 行 ID 参数来获取 这些信息：

图 5.6 – 按 ID 获取一行数据操作

1. 最后，我们需要调用 GitHub 工作流的 REST API 端点。 由于这些端点是 受保护的，我们需要创建一个 https://api.github.com/repos/[org-name]/[repository]/actions/workflows/downloadunpackcommitbash.yml/dispatches

2. HTTP 方法：POST

3. 头部

我们仅 定义 Authorization 头部，使用与我们的 GitHub 个人访问令牌完全相同的承载令牌，如下图所示： 图所示：

图 5.7 – 带 GitHub 访问令牌的授权头

请注意，我们应该将承载令牌存储在一个由 Azure Key Vault 服务支持的环境变量中。

HTTP 负载（正文）包含 GitHub 工作流的 输入参数：

 {
 "ref": "main",
 "inputs": {
   "artifact_url": "https://[your-env-id].api.crm4.dynamics.com/api/data/v9.0/deploymentartifacts(@{body('Get_a_row_by_ID')?['_artifactid_value']})/artifactfile",
   "solution_name": "mpa_ITBase",
   "user_name": "jovadker",
   "user_email": "jozsef.vadkerti@hotmail.com",
   "source_branch": "main",
   "commit_message": "new version deployed to prod"
 }
}

下图显示了我们如何在 HTTP 操作中应用这些参数：

图 5.8 – 用于调度 GitHub 工作流的 HTTP 操作

当一切 整合在一起时，我们的 Power Automate 云流应该包含以下操作和 条件情况：

图 5.9 – 端到端云流

通过最后一步，我们已经完成了最初的计划，将我们的 Power Platform 管道的部署工件保存到 GitHub 仓库。

为了完成循环，我们可以引入另一个 Power Automate 云流程，该流程由 提交到主分支 或 拉取请求提交 的 GitHub 事件触发，通过 webhooks 跟踪 GitHub 工作流调度 REST API 的结果，回传到我们的 Power Platform Pipelinehost 环境。 Webhooks 提供了一种机制，用于在 其他服务上注册 HTTP 端点作为事件处理程序。 在我们的案例中，我们可以在 GitHub 侧将 Power Automate 云流程注册为 webhook。 如果 GitHub 中发生了一个定义良好的事件，GitHub 将执行所有已注册的 webhook。 已经有可用的 GitHub 连接器，用于这些类型的触发器，比如 Power Automate 中的 当拉取请求被创建或修改时 webhook。

最后但同样重要的是，值得看一下当我们在 Dataverse 触发的 云流程中使用 Azure DevOps Services 而非 GitHub 时的差异：

• 我们需要启用 通过 OAuth 的第三方应用程序访问 复选框，位于组织级别的 组织设置 | 安全 | 策略 | 应用程序访问策略 在 Azure DevOps Services 中，以便能够在我们的 Power Automate 云流程中使用可用的 Azure DevOps Services 操作。

• 然后，我们使用 排队一个新的构建 操作，通过 Azure DevOps 连接器执行 该管道

• 如前所述，我们的 Azure DevOps 管道期望输入参数作为在 变量 面板中定义的变量

• 排队一个新的构建 操作将参数传递为以下格式：

   {
  "artifact_url": "https://[your-env-id].api.crm4.dynamics.com/api/data/v9.0/deploymentartifacts(@{body('Get_a_row_by_ID')?['_artifactid_value']})/artifactfile",
  "solution_name": "mpa_ITBase",
  "user_name": "jovadker",
  "user_email": "jozsef.vadkerti@hotmail.com",
  "source_branch": "main",
  "commit_message": "new version deployed to prod"
  }
  

做得好！ 我们刚刚学会了如何让两个工作流引擎协作，以便使用我们在自定义软件 开发项目中每天应用的相同 DevOps 原则。

Power Platform 管道开发中的协同工作者

为了显著减少在 GitHub 或 Azure DevOps Services 中开发管道的工作量，我们可以利用 大型语言模型（LLMs） 的能力 （例如 GPT-4） 以及基于这些模型构建的产品，以支持开发者和 DevOps 工程师。 其中一款产品是 GitHub Copilot，它 作为一名配对程序员助手，通过自然语言提示合成代码。 GitHub Copilot 集成到 Visual Studio Code、Visual Studio、Neovim 和 JetBrains IDE（甚至在 Azure Data Studio 中）中，并且也可以直接在 GitHub 网站上使用。

使用 GitHub Copilot 内联编辑器或 GitHub Copilot Chat 窗口，我们可以提示基础模型创建管道，这些管道使用构建工具与我们的 Power Platform 环境进行交互。 我们的提示越精确，GitHub Copilot 合成 YAML 文件的准确性就越高。 这一概念也被称为 提示工程。以下是我们在本章中执行的活动的一些真实世界提示：

• “通过使用 Microsoft Power Platform 构建工具，任务创建一个 Azure DevOps 管道，导出一个 Power Platform 环境中的解决方案，解包它，并在一个新分支中提交更改 在 main 下。”

• “创建一个 Bash 脚本，从 Dataverse 获取访问令牌，使用 AAD 应用注册并查询一个 Dataverse 表 DeploymentArtifacts 行，提供其 GUID。”名为“artifactfile”的列应当 随后下载。”

• “通过使用 Power Platform GitHub actions，创建一个 GitHub 工作流，其中包含触发条件调度，导出一个 Power Platform 环境中的解决方案，解包它，并在一个新分支中提交更改 在 main 下。”

如果我们无法访问 GitHub Copilot，我们可以 使用 Microsoft Copilot (https://copilot.microsoft.com)，使用我们的个人账户或其他 LLM 来获取一些模板和逐步说明，帮助我们了解如何构建 YAML 管道。

Copilot 也可在 Power Platform 中使用，通过自然语言帮助我们更直观地创建应用、流程、网站、聊天机器人和报告。 在之前 Dataverse 触发的工作流示例中，我们可以在 Power Automate UI 中使用以下提示 在 Copilot for Power Automate中：

“创建一个由 Power Platform 管道中的“When an action is performed”Dataverse 操作触发的工作流，并通过 OnDeploymentCompleted 事件进行触发。 如果管道是“PipelineToProd”且部署阶段为生产，则调用 HTTP 操作。”

Copilot 将很快成为我们日常工作不可或缺的一部分。 我们需要发展这些技能，获得新能力，才能保持在技术的前沿 。

总结

在本章中，我们探索了分布式版本控制系统 Git 的世界，并发现如何使用 PAC CLI 在 Git 仓库中导出/导入和解压 Power Platform 解决方案。 我们还深入了解了专业 DevOps 管道的内部工作原理，了解了 Azure DevOps 任务和 GitHub actions 等构建工具如何使用底层的 PAC CLI 在提供商托管或 自托管代理中执行操作。

在本章的下半部分，我们将 Power Platform 托管管道的结果与 第四章 中的专业 DevOps 工具结合，实现了直接从托管管道进行版本控制集成。 更重要的是，我们还使用了 GitHub Copilot 和 Power Automate 的 Copilot 来生成我们之前 手动创建的 YAML 管道和 Power Automate 云流。

但请准备好，因为在下一章中，我们将更进一步，深入探讨 YAML 技术，通过管道模板做一些真正的魔法，GitHub 工作流模板和 ALM 加速器 为 Power Platform。

进一步阅读

• 了解 Visual Studio 代码： https://code.visualstudio.com/learn

• Git 开源项目 – Git 的代码库： https://github.com/git/git

• GitHub 流程： https://docs.github.com/en/get-started/using-github/github-flow

• PAC CLI 参考： https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/

• Azure Pipelines 学习 模块： https://learn.microsoft.com/en-us/training/modules/explore-azure-pipelines/

• 集成 Azure 管道： https://learn.microsoft.com/en-us/training/modules/integrate-azure-pipelines/

• Azure DevOps 演示 生成器： https://azuredevopsdemogenerator.azurewebsites.net

• GitHub Actions 学习 模块： https://learn.microsoft.com/en-us/training/modules/introduction-to-github-actions/

• 使用 Azure DevOps 和 GitHub 实现 CI 管道 Actions： https://learn.microsoft.com/en-us/training/paths/az-400-implement-ci-azure-pipelines-github-actions/

• 使用 GitHub 构建持续集成（CI）工作流 Actions： https://learn.microsoft.com/en-us/training/modules/github-actions-ci/

• Microsoft Power Platform 构建工具 for Azure DevOps 服务： https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tools

• GitHub Actions for Microsoft Power Platform： https://learn.microsoft.com/en-us/power-platform/alm/devops-github-actions

• Power Platform 构建工具的 GitHub 仓库 工具： https://github.com/microsoft/powerplatform-build-tools

• Azure Pipelines 代理源代码 代码： https://github.com/microsoft/azure-pipelines-agent

• GitHub 运行器源代码 代码： https://github.com/actions/runner/tree/main/src

• 与 GitHub 的管道集成： https://learn.microsoft.com/zh-cn/power-platform/alm/extend-pipelines-github-export

• Dataverse Web API： https://learn.microsoft.com/zh-cn/power-apps/developer/data-platform/webapi/overview

• GitHub 调用 REST API： https://docs.github.com/zh-cn/rest/actions/workflows?apiVersion=2022-11-28#create-a-workflow-dispatch-event

• GitHub 秘密 管理： https://docs.github.com/zh-cn/actions/security-guides/using-secrets-in-github-actions

• GitHub 个人访问 令牌： https://docs.github.com/zh-cn/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

• Power Platform GitHub 连接器： https://learn.microsoft.com/zh-cn/connectors/github/

• Azure DevOps 服务中的应用连接策略： https://learn.microsoft.com/zh-cn/azure/devops/organizations/accounts/change-application-access-policies?view=azure-devops

• 使用 GitHub Copilot 进行提示工程： https://learn.microsoft.com/zh-cn/training/modules/introduction-prompt-engineering-with-github-copilot/

• OpenAI 提示 工程： https://platform.openai.com/docs/guides/prompt-engineering

第六章：深入了解持续集成/持续部署（CI/CD）管道

在本章中，我们将 亲身体验设计 应用生命周期 C ycle Management (ALM) 过程，适用于具有代码优先和低代码/无代码组件的应用程序。 此外，我们还将讨论 DevOps 工程师如何标准化管道 并为它们注入活力 在任何其他 新的 Power Platform 项目中，使用 管道模板 和 可重用工作流 在 Azure DevOps 和 GitHub 作为可重用的构建模块。 我们将深入了解 并对 Power Platform 的 ALM 加速器 包有一个扎实的理解，这个包是 Power Platform 卓越中心启动工具包的一部分，以及我们如何在自己的 DevOps 环境中重用该包中的内容。 我们还将学习 Power Platform 管道 、托管管道，以及它们如何利用专业 DevOps 工具的功能，比如自动化测试。 最后，本章 还将教我们如何 使用开源框架进行自动化测试 及其在 持续集成与持续部署 (CI/CD)管道中的集成。

在本章中，我们将涵盖以下 主要主题：

• 当所有内容汇聚在一起——分支、环境和 Power Platform 目录

• Azure 管道模板和可重用 GitHub 工作流

• Power Platform 的 ALM 加速器

• DevOps 和 Power Platform 管道中的自动化测试

技术要求

要通过使用专业开发 DevOps 工具深入了解我们的 CI/CD 管道，我们需要具备 以下内容：

• Power Platform 订阅：如果我们已经有了 Microsoft Entra ID 工作账户，我们可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free），或者我们也可以加入 Microsoft 365 开发者计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。

• Azure DevOps Services 组织：我们可以随时创建一个 DevOps 组织 免费 (https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates)。 如果我们在 Azure DevOps 中创建一个公共项目，我们将获得多个免费的流水线，并免费访问服务的所有功能（请参阅 Azure DevOps for Open Source 提供）。

• 一个 GitHub 账号 和公共代码库（https://github.com/signup），这也 是免费的 ，适用于公共代码库。

• 本章讨论的示例和教程位于 在 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter06。

当一切都合而为一时

在上一章中，我们看到 Azure DevOps Services 流水线和 GitHub 流程如何与我们的 Dataverse 环境和 Power Platform 解决方案互动，以实现 DevOps CI/CD 能力。

分支和环境

如果我们遵循 基于主干的分支策略 或非常相似的 GitHub flow，我们将经常创建短生命周期的分支用于开发目的。 这些分支就是 所谓的 功能分支 ，我们可以用它们来实现新的用户需求或修复客户或内部质量保证过程中发现的漏洞。 。

我们可以使用 Power Platform 构建工具 以及相应的底层 Pac CLI 来创建 开发者 环境。 一个特定解决方案的典型分支 结构可能如下所示：

 main
    test
        devA
        devB
        devZ

在 分支策略的帮助下，我们可以强制开发者 使用拉取请求将更改合并回测试和/或主分支。 在 Azure DevOps Services 中，如果我们为某个分支配置了任何分支策略（要求 最低审阅者数量， 检查链接的工作项， 检查评论解决，或者 限制合并类型），该分支 将无法删除，并且要求 拉取请求 (PRs) 用于所有更改。 因此，我们可以避免将意外更改直接提交到这些 专用分支：

图 6.1 – 分支策略

检查链接的工作项

我们强烈建议在您的专用主分支和测试分支上强制执行此设置。 它仅仅确保，在没有明确定义的用户故事或 待办事项的情况下，不会有任何更改。

我们也可以在 GitHub 上实现类似的配置。 这被称为 分支保护规则，它提供了更多 选项。 例如，我们可以要求在合并之前进行 PR 审核，要求在合并之前通过状态检查，并限制谁可以推送到该分支。 我们还可以强制 签名提交 通过附加加密签名来验证 提交的真实性。 这个签名是使用提交者的私钥创建的，其他人可以使用提交者的公钥进行验证。 签名提交提供了代码更改来自可信且 授权源的保证。

下图显示了所有可用的保护规则 适用于 GitHub 分支：

图 6.2 – 分支保护规则

无论我们使用哪个 DevOps 工具，我们的目标是创建一个 DevOps 框架，使得专业开发人员不仅能够相互协作，还能与每一个开发人员（公民开发者）合作。 为了在开发过程中设置正确的 质量门控 ，建议 在专用和临时/开发人员 Power 平台环境中映射我们的分支结构：

图 6.3 – 分支与环境

在前面的图中，Power Platform 环境和 Git 分支之间的箭头表示代码 和部署流程。 生产环境 和测试环境只能处理 PR（即解决方案仅被导入到这些环境中），而开发环境应当是双向的，因为这些环境中的更改将被导出回 Git 仓库，并分别更新到开发分支。 在我们的案例中， US_XXX_Y 分支表示 一个短期的功能分支，包含了用户故事的实现。 具有不同触发条件的 CI/CD 流水线管理着这两个世界之间的互动，从解决方案生命周期的开始开始。 流水线/工作流甚至可以用于在整个 开发者旅程中创建这些自动化。

让我们详细看看如何 使用 Azure Pipelines 自动化一些最常见的步骤： 步骤：

1. 创建开发者分支：我们可以使用以下 Bash 脚本来创建 一个分支：

   git config user.name $(Build.RequestedFor)
   git config user.email $(Build.RequestedForEmail)
   #creating the branch under "dev" folder
   newbranch=dev/${{ parameters.devbranch }}
   git checkout -b $newbranch
   git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" push origin $newbranch
   

2. 为 Power Platform 开发者环境提供服务：首先，我们需要通过使用 Microsoft 托管的 Windows 机器上的服务主体登录到 Power Platform 环境，因为 Pac CLI 将身份验证凭证以纯文本形式存储在 Linux 机器上：

   pac auth create --applicationId 862e5a17-d38b-43ff-b24f-88a77f59623f \
    --clientSecret $(ClientSecret) \
    --tenant 4ae51f31-033a-48fa-be48-5ece14d2c081
   

   我们还需要使用相同的服务主体登录到我们的 Azure 租户，以查明是谁触发了此 Azure Pipeline：

   az login --service-principal \
    -u 862e5a17-d38b-43ff-b24f-88a77f59623f \
    -p $(ClientSecret) \
    --tenant 4ae51f31-033a-48fa-be48-5ece14d2c081
   AADObjectID=$(az ad user show \
    --id $(Build.RequestedForEmail) \
    --query id \
    --output tsv)
   $(Build.RequestedForEmail) system variable contains the email address of the user who started the pipeline. We use the Microsoft Entra ID’s user object ID to create a Power Platform developer environment on behalf of this user (the command, per se, runs under the name of the service principal and not on behalf of our users):
   
   

   pac admin create --name "dev-US_XXX_Y" \

   --type Developer \

   --user $AADObjectID

   
   After creating the Power Platform environment, we need to assign the developer (who has started the pipeline) to it as the System Administrator:
   
   

   获取环境 ID（倒数第二行包含此信息）

   rawOutput=$(pac admin list --name dev-us_XXX_Y | tail -n 2)

   environmentId=$(echo $rawOutput | cut -d ' ' -f 2)

   为创建开发者环境的用户添加系统管理员角色

   pac admin assign-user --environment $environmentId --user $AADObjectID --role "系统管理员"

开发者环境

Power Platform 中的每个用户最多可以免费创建三个开发者环境 。

1. 导出解决方案, 导入解决方案, 复制环境, 和 备份，针对该环境。 如果我们希望自动化服务连接创建过程，也是可行的。 我们需要创建一个 JSON 文件，将其作为有效载荷发布到 REST 端点上，供 Azure DevOps 服务使用（参见 AzDO/.pipelines/config-tokenizer.yml 在 第六章 文件夹中的 GitHub 仓库）：

    {
      "authorization": {
         "parameters": {
            "tenantId": "GUID",
            "applicationId": "GUID",
            "clientSecret": "secret"
         },
         "scheme": "None"
      },
      "createdBy": {},
      "data": {},
      "isShared": false,
      "isOutdated": false,
      "name": "ConnenctionName",
      "owner": "library",
      "type": "powerplatform-spn",
      "url": "DataverseURL",
      "administratorsGroup": null,
      "description": "",
      "groupScopeId": null,
      "operationStatus": null,
      "readersGroup": null,
      "serviceEndpointProjectReferences": [
       {
            "description": "",
            "name": "ProjectName",
            "projectReference": {
               "id": "ProjectID",
               "name": "ProjectName"
            }
        }
      ]
   }
   

   我们可以使用以下 Bash 脚本来标记这个 JSON 文件（参见 AzDO/.pipelines/create-service-connection.yml 在 第六章 文件夹中的 GitHub 仓库）：

   # Set the filename
   filename="config_tokenizer.json"
   # Read the JSON file
   json_string=$(cat .pipelines/$filename)
   # Replace the value
   new_json_string=$(jq '.authorization.parameters.clientSecret = "$(ClientSecret)"' <<< "$json_string")
   new_json_string=$(jq '.authorization.parameters.tenantId = "$(tenantId)"' <<< "$new_json_string")
   new_json_string=$(jq '.authorization.parameters.applicationId = "$(applicationId)"' <<< "$new_json_string")
   new_json_string=$(jq '.url = "${{ parameters.ppdevenvironmentURL }}"' <<< "$new_json_string")
   new_json_string=$(jq '.name = "${{ parameters.ppdevenvironment }}"' <<< "$new_json_string")
   new_json_string=$(jq '.serviceEndpointProjectReferences[0].projectReference.id = "$(System.TeamProjectId)"' <<< "$new_json_string")
   new_json_string=$(jq '.serviceEndpointProjectReferences[0].projectReference.name = "$(System.TeamProject)"' <<< "$new_json_string")
   new_json_string=$(jq '.serviceEndpointProjectReferences[0].name = "${{ parameters.ppdevenvironment }}"' <<< "$new_json_string")
   # Write the modified JSON data back to the file
   echo $new_json_string > config.json
   

   如果我们想要在本地执行 这个脚本，那么我们可以使用 az devops CLI 命令来自动创建我们的 服务连接：

   echo $(PatToken) | az devops login --organization $(System.CollectionUri)
   az devops service-endpoint create \
    --organization $(System.CollectionUri) \
   AzDO/.pipelines/import-solution.yml in the Chapter06 folder of the GitHub repo):
   
   

   steps:

   • checkout: git://PowerPlatform/Copilot@${{parameters.sourceBranch}}

   displayName: '检出源分支'

   persistCredentials: true

   • task: PowerPlatformToolInstaller@2

   inputs:

   DefaultVersion: true

   • task: PowerPlatformPackSolution@2

   inputs:

   SolutionSourceFolder: '$(System.DefaultWorkingDirectory)/src/$(solutionName)'
   
   SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip'
   
   SolutionType: 'Unmanaged'
   

   • task: PublishBuildArtifacts@1

   inputs:

   PathtoPublish: '$(Build.ArtifactStagingDirectory)/Solution'
   
   ArtifactName: 'Solution'
   
   publishLocation: '容器'
   

   • task: PowerPlatformImportSolution@2

   inputs:

   authenticationType: 'PowerPlatformSPN'
   
   PowerPlatformSPN: ${{parameters.serviceconnection}}
   
   SolutionInputFile: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip'
   
   AsyncOperation: true
   
   MaxAsyncWaitTime: '60'
   

   • task: PowerPlatformPublishCustomizations@2

   inputs:

   authenticationType: 'PowerPlatformSPN'
   
   PowerPlatformSPN: ${{parameters.serviceconnection}}
   

   
   We use `${{parameters.serviceconnection}}` as a string parameter of the pipeline, which represents the name of the service connection previously created.We can put these steps together into one pipeline or keep them separately. We can also chain these pipelines by using other trigger conditions, such as `branch created`. For instance, a new dev branch is created under the `dev/*` condition looks, as follows:
   
   

   trigger:

   • dev/*

经过这些自动化步骤之后，我们最终得到了一个开发分支，可以在上面开始我们的工作。 建议使用 Azure DevOps 中的可用工具将一个或多个工作项分配给该分支；否则，后续提交的 PR 将会被自动拒绝（如果配置了推荐的分支策略）。

下图显示了如何分配 分支到 Issue 工作项：

图 6.4 – 将分支链接到工作项

在 Power 平台环境中进行更改 应该在开发分支上反映出版本控制系统中的更改。 为了实现这一点，我们需要创建另一个管道（Export-to-Git），导出我们的托管和非托管解决方案，解包并提交更改到我们的开发分支。 我们在 第五章 中看到了这些构建模块。除了该管道外，我们还需要添加一个步骤来导出未托管的解决方案，并以 Both 类型解包解决方案。要将更改提交回分支，我们可以在 PowerPlatformExportSolution@2 和 PowerPlatformUnpackSolution@2 构建任务完成后，执行以下 Git 命令作为 Bash 脚本：

 -  checkout:  git://$(System.TeamProject)/$(Build.Repository.Name)@${{parameters.targetBranch}}
    displayName:  'Checkout  Source  Branch'
    persistCredentials:  true
#  Configure  email/name  and  checkout  git  branch
-  script:  |
      git  config  user.name  $(Build.RequestedFor)
      git  config  user.email  $(Build.RequestedForEmail)
      git  checkout  origin/${{parameters.targetBranch}}  --track
[[Adding here those PowerPlatformExportSolution@2 and PowerPlatformUnpackSolution@2 steps discussed earlier.]]
-  script:  |
        #!/bin/bash
        set  -e
        #  Set  the  path  to  the  directory  containing  the  solution
        solution_dir="$(Build.SourcesDirectory)/src/$(solutionName)"
        #  Find  all  Solution.xml  files  in  the  solution  directory  and  its  subdirectories
        find  "$solution_dir"  -type  f  -name  "Solution.xml"  |  while  read  -r  file;  do
                #  Replace  the  content  of  the  <Version>  tag  with  0.0.0.0
                sed  -i  's|<Version>.*</Version>|<Version>0.0.0.0</Version>|g'  "$file"
        done
    displayName:  "Set  version  number  to  0.0.0.0"
-  script:  |
        rm  -rf  ./out/$(solutionName).zip
        rm  -rf  ./out/$(solutionName)_managed.zip
        git  add  --all
        git  commit  -am  "Solution  is  committed"  --allow-empty
        git  -c  httpO.extraheader="AUTHORIZATION:  bearer  $(System.AccessToken)"  push  origin  ${{parameters.targetBranch}}

通过这个管道的帮助，我们的开发人员可以不断地将他们的更改提交回他们自己的 专用开发分支，进行特性开发。 我们有意将解决方案的版本号设置为 0.0.0.0 ，以避免冲突的合并，并通过 Azure 管道管理版本号。 当开发人员准备好时，他们可以提交 PR 回到 父分支。

让我们讨论一些额外的 DevOps 设计原则和建议 与我们的 DevOps 过程相结合：

• PowerPlatformPackSolution@2 构建任务可以随时从源代码控制中打包我们的解决方案。 这是一个压缩步骤，实际上是将我们的文件夹打包成 ZIP 文件，因此不需要长时间的编译时间。 当然，如果我们有 需要构建的代码组件，例如 PowerApps 组件框架 (PCF) 控件或 Dataverse 插件，或者我们针对同一清单（解决方案）目标多个环境，则值得创建专门的 CI 管道。

• Export-to-Git 管道，我们可以提交 PR 来将我们的更改合并到测试分支，然后再合并到生产分支。 我们可以引入 CD 管道，该管道在目标分支上的 PR 完成后执行。 分支触发：

  trigger:
  SolutionChecker or performing automated tests. We can introduce approval processes for staging environments (test and production) to control when changes are approved by release managers or environment administrators, with the help of Azure DevOps Services environments.
  

• 解决方案的版本号 - 何时需要设置它们？ 如前所述，随着 DevOps 的兴起，我们希望只维护一个版本，即我们应用程序在生产中的最新版本。 我们使用版本控制和版本号来追踪更改到 源代码：

   #  Solution  version  in  source  control  is  not  used. Instead,  create  version  at  build  time  from  the  current  build  number. -  pwsh:  |
        Get-ChildItem  -Path  "$(Build.SourcesDirectory)\$(RepoName)\${{parameters.solutionName}}\SolutionPackage\**\Solution.xml"  |
        ForEach-Object  {
                  (Get-Content  $_.FullName)  `
                          -replace  '<Version>0.0.0.0<\/Version>',  '<Version>$(Build.BuildNumber)</Version>'  |
                  Out-File  $_.FullName
        }
      displayName:  'Update  Solution  XML  with  Build  Number'
  name:  1.0.$(Date:yyyyMMdd)$(Rev:.r)
  

  这意味着在构建/部署过程中，版本 是实时计算的，使用 Azure 管道的构建名称。 这提供了解决方案版本与生成该版本的管道之间的一对一关系。 该版本。

• 导出到 Git 管道中，我们可以引入一个参数，该参数期望部署父分支当前版本的分支名称。 如果我们不想以这种方式覆盖我们的工作，我们可以使用诸如 git rebase 等 Git 命令将我们的开发分支恢复到父分支的最新版本。 之后，我们需要使用另一个管道将解决方案导入到我们的 开发环境。

总的来说，我们可以通过以下方式管理我们的开发工作 四个管道：

图 6.5 - 管理解决方案的管道

我们可以以同样的方式创建 GitHub 工作流。 那些 Bash 和 PowerShell 脚本可以轻松迁移到 GitHub 工作流，还可以建立与 Azure 类似的分支和仓库结构，并分配 Power Platform 环境。 DevOps 服务。

Power Platform 目录

除了这种 CI/CD 交付到 Power Platform 环境之外，Power Platform 还提供了一个新的概念，用于管理我们可重用的软件包。 该 Power Platform 目录 是一个软件包管理器，包含解决方案模板、PCF 组件、端到端解决方案以及其他可重用资产。 它基于我们在专业开发场景中发布软件包到不同的包管理库时使用的相同概念，例如 NuGet、npm、Maven 和 Pip。 Power Platform 中的目录是一个功能，允许开发者和创建者轻松发现并使用组织内的 Power Platform 模板和代码组件。 它提供了一个私有的中央位置，用于查找和安装最新且最可靠的组件版本，提供能够立即产生价值的模板。 对于管理员和业务审批人而言，目录作为一个唯一的权威来源，用于存储和维护 Power Platform 工件，允许他们策划和控制内容，加速创作者和开发者的价值。 它还为在敏感的监管和法定场景中使用批准的组件和模板启用了审批工作流，提供具有设置 和元数据的管理功能。

为了将目录带入一个专用环境（建议提供一个单独的环境，例如 目录），我们需要将其作为 Dynamics 365 应用从 AppSource 安装： https://appsource.microsoft.com/product/dynamics-365/powerappssvc.catalogmanager-preview?flightCodes=dde212e5c66047c59bf2b346c419cef6。

安装此 D365 应用后，我们可以提交并部署以下资产 到其中：

• Dataverse 解决方案 (已管理或未管理) 或 软件包部署器软件包 （企业模板也可以 发布到 目录中）

• 模板 用于 Power App 或 Power Automate 流程

• Power Platform 代码优先组件 如自定义连接器 或 Power Apps 组件框架 (PCF) 控件

Power Platform 目录 引入了额外的安全角色来管理目录项的生命周期—— 目录提交者 用来提交项目到目录， 目录只读成员 用来发现和安装 目录中的项目， 目录批准者 用来批准提交到 目录的项目， 以及 目录管理员 用来管理目录。 我们也从目录中获得了这种企业级的安全性。

我们的 Azure 管道和 GitHub 工作流不仅可以面向环境，还可以面向目录。 Pac CLI 提供了适当的命令，将我们的解决方案、自定义连接器和 PCF 组件提交到目录。 以下脚本创建一个提交到我们的 mpa_ITBase_managed 解决方案（我们在 第四章 用于管理的管道），并从企业模板提交一个新的 目录项：

 # Power Platform Catalog Manager application's GUID
pac admin list --application 83a35943-cb41-4266-b7d2-81d60f383695
# environment is the "Catalog" environment
pac catalog list --environment 0b90d036-e017-e840-9287-b1de3d95e252
# create a submission json file
pac catalog create-submission
# update the generated json file
pac catalog submit --environment 0b90d036-e017-e840-9287-b1de3d95e252 --path .\submission.json --solution-zip .\mpa_ITBase_managed.zip

这些脚本也可以代表服务 主体运行。 默认情况下，提交需要由目录管理员批准，但我们可以更改配置，使某些发布者，例如在 Azure 管道或 GitHub 工作流中运行的服务主体，获得 自动批准。

下图展示了 mpa_ITBase_managed 解决方案：

图 6.6 – Power Platform 目录管理器

Power Platform 目录

Power Platform 目录 将在它们变为 管理环境的一部分 后， 正式 发布。

现在让我们继续讨论管道模板和可重用的工作流，它们可以在大规模上提供我们的 Azure 管道和 GitHub 工作流的可重用性。

Azure 管道模板和可重用的 GitHub 工作流

回顾我们前一节中的 Azure 流水线 ，我们可以说，这其实是一个非常好的起点，可以让所有工作自动化。 然而，如果我们需要支持数百甚至数千个应用程序，那么在每个包含这些解决方案的存储库中保留三到四个流水线的方法将变得更加复杂。 随着我们开发的应用程序越来越多，这些 Azure 流水线的不同版本将会并行存在。 如果能有一个集中式存储库，包含这些流水线的业务逻辑，且只在调用它们之前定制一些参数，那就太好了。 这就是 Azure 流水线模板和可重用 GitHub 工作流背后的理念。

Azure 流水线模板 使我们能够创建可重用的业务逻辑，这些逻辑可以在我们的 YAML 流水线实例中使用。 这些模板还可以用来控制流水线中允许的内容，通过定义调用者应遵循的策略。 例如，我们可以通过使用一个充当保护措施的模板来强制执行任务执行约束，确保执行的任何任务都符合我们组织的 安全指南。

例如，以下 AzDO/.pipelines/template/include-paccli-steps.yml 位于 Chapter06 文件夹中的 GitHub 仓库）：

 # File: templates/include-paccli-steps.yml
steps:
-  bash:  |
        echo  "Installing  Pac  CLI"
        dotnet  tool  install  --global  Microsoft.PowerApps.CLI.Tool
    displayName:  "Installing  Pac  CLI"

使用此模板的流水线文件会在 Linux 上执行，然后在 Windows 代理上执行（参见 AzDO/.pipelines/azure-pipeline-template.yml）：

 # File: azure-pipelines.yml
jobs:
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: templates/include-paccli-steps.yml
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: templates/include-paccli-steps.yml

我们还可以对 Azure 流水线模板 文件进行参数化，调用者流水线可以根据其 定制需求设置这些参数。

相同的 概念，称为 workflow_call。以下可重用的工作流将在目标平台上安装 Pac CLI。 该工具的版本号和目标平台是此流程的参数（参见 GitHub/.github/workflows/install-paccli.yml）：

 on:
  workflow_call:
    inputs:
      version:
        required: true
        type: number
      platform:
       required: true
       type: string
       description: "platform"
jobs:
  installpac:
    runs-on: ${{inputs.platform}}
    steps:
     - name: install pac cli
       shell: bash
       run: |
          echo "version number: ${{inputs.version}}"
          dotnet tool install --global Microsoft.PowerApps.CLI.Tool

要从其他工作流中调用我们的工作流 ，我们需要在我们的 调用者 GitHub 工作流中创建一个专门的任务（参见 GitHub/.github/workflows/Deploy.yml）：

 name: Call a reusable workflow
on:
  workflow_dispatch:
jobs:
  call-paccli-workflow:
    uses: jovadker/ppmanaged/.github/workflows/install-paccli.yml@main
    with:
      version: 8
      platform: ubuntu-latest
  call-workflow-windows:
    uses: jovadker/ppmanaged/.github/workflows/install-paccli.yml@main
    with:
      version: 8
      platform: windows-latest

这个概念在 Azure DevOps 和 GitHub 中的真正力量在于，我们可以将模板 和可复用的工作流放置在同一代码库中的不同位置，甚至放在不同的 Git 代码库中。 如果我们查看为启动开发人员环境、创建服务连接、以及分别从/向环境导出/导入解决方案而创建的管道，我们现在可以将这些模板或可复用的工作流放置在专用的 Git 代码库中。 不同的项目和解决方案可以通过使用这个可复用的概念来调用我们的模板。 相反，我们可以通过减少管理大量项目的整体工作量来集中改进和维护这些工作流。 项目。

除了可复用的 工作流，GitHub 还提供了所谓的 GitHub 启动工作流。GitHub 启动工作流也是存储在组织的 GitHub 代码库中的模板。 当我们在 GitHub 用户界面中创建新工作流时，这些模板会显示出来。 创建工作流后，模板会被复制到我们的代码库中，至此，我们将实例与模板解耦。 我们可以使用 GitHub 启动工作流帮助项目基于我们的 可复用工作流来设置它们的工作流。

现在我们已经了解了管道模板和可复用工作流，接下来让我们学习一下 Power Platform 的 ALM 加速器，它在背后大量使用了这个概念。

Power Platform 的 ALM 加速器

Power Platform 的 ALM 加速器 是一个帮助开发人员自动化 Power Platform 软件开发工作流的工具。 尽管 它是 卓越中心 (CoE) 启动工具包的一部分，该工具包是帮助组织开始采用 Power Platform 的组件和工具的集合，但它也可以作为独立的解决方案安装在我们的 Dataverse 环境中。

ALM Accelerator 包括 Azure 管道模板、Azure 管道和 Power Platform 应用程序，帮助专业开发人员在项目中实现 DevOps 和 ALM。这个加速器包被称为ALM Accelerator for Advanced Makers（AA4AM）解决方案，包含了最初由微软 CoE Starter Kit 工程团队开发的参考实现。成功实现后，团队决定将其开源，并使每个组织都能使用，证明了如何在 Power Platform 中实现健康的应用生命周期管理。我们可以直接使用这些管道和应用程序，或者根据我们的组织需求对其进行自定义，当然，我们也可以从这个团队几年前设计的基本概念中学到很多东西。

我们可以找到关于加速器的全面文档，了解如何安装它，如何基于可用的管道模板创建管道，以及如何在 Azure DevOps 仓库中管理我们的 Power Platform 解决方案。

本章前面讨论过的分支、环境和管道模板，对于理解 ALM Accelerator 如何在后台工作至关重要。加速器的主要功能如下：

• 有一个模型驱动的应用程序，ALM Accelerator for Power Platform Administration，用于创建和管理部署配置文件。部署配置文件描述了解决方案在我们环境中的 CD 流程。它在概念上与我们如何定义 Power Platform 管理管道相同。建议为每个 Power Platform 解决方案创建一个部署配置文件，因为该配置文件还包含有关 Azure DevOps 项目、Git 仓库和目标分支的信息，以及相应的 Power Platform 环境。

• 另有一个画布应用程序，ALM Accelerator for Power Platform，为开发人员提供了一个 UI，并在给定的 Power Platform 环境中可视化解决方案和分配的部署配置文件。

• 通过 ALM Accelerator for Power Platform 画布应用程序，我们可以轻松创建一个分支，并将我们的解决方案版本（更改）多次提交到该分支。

• Canvas 应用程序提供了一种通过定义的环境移动我们更改的方式。 每次部署（发布）都是对父分支的 PR。 在 Azure DevOps 中完成 PR 后，管道将解决方案导入到部署配置文件中定义的分配环境。

• 建议为每个解决方案创建一个仓库。 该仓库包含我们的管道，利用了加速器提供的管道模板。

• 我们可以添加更多环境，并创建我们在本章开头讨论的相同分支结构。

• Canvas 应用程序使用自定义连接器，并调用 Azure DevOps Services 的 REST API 端点与 定义的管道进行交互。

• 该 coe-alm-accelerator-templates GitHub 仓库包含了 ALM 加速器使用的管道模板。 我们需要将此仓库分叉到我们的 Azure DevOps 项目中，作为一个额外的 Git 仓库。

• 我们可以根据我们 组织的需求自定义管道模板。

• Power Platform 的 ALM 加速器 仅适用于 Azure DevOps Services。

下图展示了 Power Platform 的 ALM 加速器 的工作原理：

图 6.7 – Power Platform 的 ALM 加速器

我们可以看到所选环境中可用的未管理解决方案（开发者环境）。 我们可以使用 提交解决方案、 部署解决方案和 删除解决方案 按钮来触发我们的管道，提交我们的更改，或 启动 PR。

Power Platform 的 ALM 加速器

通过观察本章中前面展示的广泛灵活性 以及管道在托管环境中的有效性，我们应该考虑将 Power Platform 的 ALM 加速器作为一个工具，以帮助我们熟悉各种设计模式和概念。 然后，这些可以被纳入我们自定义的 Azure DevOps 管道，并随后集成到我们的 GitHub 工作流中。

现在，我们已经准备好在组织中操作和管理大量的项目和解决方案。 确保我们应用程序质量的最后一件事是 自动化测试。

DevOps 和 Power Platform 管道中的自动化测试

测试自动化和自动化测试 是 ALM 和 DevOps 流程的核心部分。 没有自动化 测试，我们无法 与其他开发人员共享解决方案，无法作为独立的 SCRUM 团队共同合作解决方案，而且每次修改解决方案时都是一项巨大的挑战，因为我们无法知道我们的应用程序会在回归测试中跌落多远。 为了避免回归并实现高测试覆盖率，我们需要建立与定制开发项目相同的质量保证流程。 Power Platform 提供了多种工具和框架来为 我们的解决方案创建功能测试。

选择, 设置属性, 断言, 和 追踪. 测试表达式构建测试用例。 真 或 假 在测试中。 如果断言返回 假, 测试 用例失败。

使用 Power Apps 测试工作室创建的测试可以通过 Azure 管道执行。 在 进一步阅读 部分提供的逐步指南（使用 Azure DevOps Pipelines 自动化测试）使用测试的回放 URL 作为自动化测试执行的输入。 在 https://github.com/microsoft/PowerAppsTestAutomation 下提供的仓库 MSTest 测试方法使用 AppMagic.TestStudio.GetTestExecutionInfo() MSTest 测试方法然后根据这些结果决定成功或失败。 测试方法的结果还会写回我们的 Azure 管道，我们可以直接在 Azure DevOps 服务的 构建结果中查看测试结果。

Power Apps 测试引擎 是测试 PowerApps 画布应用的最新方法，使用基于 Playwright 的引擎。 Playwright 因其稳定性 和性能、简便的设置、对 Chromium、Firefox 和 WebKit 的统一 API 支持，以及 JavaScript、Python 和 C# 的官方绑定而广受欢迎。 Playwright 最初由微软开发，现已开源并发布供 社区贡献。

PowerApps 测试引擎允许我们使用直观的 Power Fx 语言以 YAML 格式编写测试， 文档对象模型 (DOM) 抽象化使得我们可以使用在设计阶段建立的控件名称引用来编写测试。 这种方法意味着测试作者不需要具备 JS 知识 或对与应用程序视觉输出相关的浏览器 DOM 的了解。 以下 YAML 文件 展示了一个这样的例子：

 testSuite:
   testSuiteName: Regression test suite
   testSuiteDescription: ''
   persona: User1
   appLogicalName: vadkerti_contentgenerator_48e05
   appId: ''
   onTestCaseStart: ""
   onTestCaseComplete: ""
   onTestSuiteComplete: ""
   networkRequestMocks:
   testCases:
   - testCaseName: Test with empty input
      testCaseDescription: ''
      testSteps: |
         =
         SetProperty(Prompt.Text, "Writing some test");
         Select(SystemPrompt);
         SetProperty(Prompt.Text, "");
         Select(SystemPrompt);
         Select(Prompt);
         Select(Button4);
         Assert(IsMatch(TextInput4.Text, "I'm sorry, I'm not sure what you are asking. Can you please provide more context or clarify your question?<|im_end|>"), "Different output");
testSettings:
   filePath:
   browserConfigurations:
   - browser: Chromium
      device:
      screenWidth: 0
      screenHeight: 0
   locale: en-US
   recordVideo: true
   headless: true
   enablePowerFxOverlay: false
   timeout: 30000
environmentVariables:
   filePath:
   users:
   - personaName: User1
      emailKey: user1Email
      passwordKey: user1Password

我们可以从 Power Apps 测试工作室 下载这个 YAML 文件 并导入 到我们的 PowerApps 测试引擎。

测试引擎还支持 连接器模拟，允许我们在应用程序中围绕连接器和连接创建模拟。 因此，我们可以将应用程序与第三方生产服务隔离进行测试。 此外，测试引擎支持截图和视频录制，允许我们在测试执行的任何时候截屏，并通过视频记录文档化测试序列，这对于故障排除未通过的测试和分析实际用户体验非常有帮助。 未通过的测试场景。

其他我们可以在管道执行期间调用的知名工具，借助 Pac CLI 和 PowerShell 模块， 是 AppChecker (pac solution check) 用于 画布应用程序。

在测试 Microsoft Copilot Studio时，我们可以使用 PVA 测试框架，一个可以在 GitHub 上找到的示例解决方案。 它演示了如何使用 API 和 Direct Line 通道对 Microsoft Copilot Studio 聊天机器人进行测试。 该框架确认机器人在多种情况下按预期运行，包括 以下情况：

• 测试自然语言理解模型以触发 正确的话题。

• 验证多个匹配话题的选项（“您是指...”如果用户意图 模糊不清，副驾驶助手会提出此问题）

• 进行负载测试 的大规模测试

• 完整的 端到端对话测试

• 测试 自适应卡片的功能

• 在 CI/CD 部署管道中添加一个测试步骤，以防测试失败时防止部署 测试失败

我们可以手动创建 对话脚本 ，或者我们可以使用 PVA 测试框架 从 Dataverse 导出现有对话 ，并以 CHAT 格式进行转换。然后，我们可以借助 PVA 测试框架将这些 CHAT 文件转换为 JSON，并让它们通过 Direct Line REST API 端点执行。 该框架可以轻松集成到我们的 Azure 管道和 GitHub 工作流中，因为它是一个.NET 6 控制台应用程序，可以在基于 Windows 的 托管代理上运行。

要测试 基于模型的 Power Apps 和 Power Pages 网站，我们可以使用其他 网页测试 框架，例如： 以下内容：

• Selenium 测试框架 是一个自动化测试工具集，允许开发人员创建强大的基于浏览器的回归自动化套件和测试。 它可以扩展并分配脚本到多个环境，并支持广泛的编程语言。

• Playwright 是一个跨浏览器、跨平台、跨语言的 可靠的端到端网页应用测试工具。 它支持所有现代渲染引擎、本地移动模拟、自动等待、网页优先的断言、追踪和完全隔离。 Playwright 使用其 自有 API 与浏览器进行交互。

• Appium.io 用于移动应用程序测试：Appium 是一个免费开放源代码的软件套件和生态系统，旨在促进跨各种应用平台的用户界面自动化。 这包括移动操作系统（iOS、Android 和 Tizen）、网页浏览器（Chrome、Firefox 和 Safari）、桌面环境（macOS 和 Windows）以及电视操作系统（Roku、tvOS、Android TV 和 Samsung）。 其目标是使任何移动应用程序的自动化成为可能，无论使用什么编程语言或测试框架，完全访问后端 应用程序编程接口 (APIs)和 数据库 (DBs)都可以在 测试脚本中进行访问。

• Cypress 是一个基于 JavaScript 的端到端测试 框架，建立在 Mocha 上。 它旨在简化为 Web 应用程序设置、编写、运行和调试测试的过程。 Cypress 可以测试任何在 Web 浏览器中运行的内容，并特别擅长处理现代 JavaScript 框架。 Cypress 的一些关键优势包括更快且更可靠的测试、减少的故障率、支持详细报告的仪表盘、并行 测试 执行，以及支持 行为驱动开发 (BDD) 和 测试驱动开发 (TDD) 测试。

• JMeter 是由 Apache 软件基金会开发的开源工具，用于负载测试和分析各种服务的性能。 JMeter 是用 Java 编写的，可以用于测试各种应用程序和协议的性能和功能行为，例如 HTTP (超文本传输协议)， SOAP (简单对象访问协议)， FTP (文件传输协议)，以及 LDAP (轻量级目录访问协议)。 它 提供了一个功能齐全的 IDE、动态 HTML 报告、多线程框架以及一个高度可扩展的核心，支持可插拔的采样器 和插件。

测试 Power Automate 云流和桌面流是比在浏览器或移动设备上执行 UI 自动化测试更复杂的工程挑战。 截至写作时，没有推荐的框架来实现针对我们的云流和桌面流的集成和系统测试。 由于这些组件被视为业务逻辑层的一部分，我们可以通过它们前面的 UI 组件进行测试，作为 端到端测试。

相反，我们可以通过调用其相应的 REST API 端点并将其结果与我们 期望的结果进行比较，提供部分解决方案来测试 HTTP 触发和 Webhook 触发的云流。

正如我们在 第五章中学习到的， OnDeploymentCompleted 事件可以用于测试我们在部署到目标环境后 的解决方案，该环境被表示为一个部署 阶段。 我们的 Power Automate 云流作为该事件的事件处理程序，可以调用 Azure 管道或 GitHub 工作流执行代码优先的专业开发测试自动化脚本（类似于我们在 第五章中如何调用 GitHub 工作流）来将我们的解决方案提交到 Git 仓库。 下一个部署阶段的预审批门（OnApprovalStarted 或 OnPredeploymentStarted）可以检查前一个环境中测试执行的结果。 如果测试通过，部署到下一个环境 可以继续进行。

最后，我们可以使用其他 Microsoft Azure 服务，如 Azure 负载测试 服务，来对我们的 JMeter 进行测试 Power Platform 解决方案。 JMeter 还提供录制功能，而 Azure 负载测试服务可以模拟数百个并行用户同时与 我们的应用进行交互。

根据解决方案的类型，我们需要选择具有适当深度和广度的测试工具。 我们需要设计和交付的业务或任务关键应用越多，我们就应该在这一 DevOps 领域投入更多的时间和精力。

总结

在本章中，我们探讨了 DevOps CI/CD 流程的高级模式，并学习了如何建立一个强大的分支策略，反映我们解决方案的开发、测试和生产环境。 我们检查了许多自动化创建分支、使用服务连接启动 Power Platform 环境、以及使用各种 Pac CLI 脚本导入和导出解决方案的示例。

我们还深入了解了 Power Platform 目录，作为 Power Platform 的包管理解决方案。 此外，我们还了解了 Power Platform 的 ALM 加速器，以及该解决方案如何使用管道模板、分支策略和环境管理。 最后，我们熟悉了可以与 Power Platform 解决方案一起使用的测试自动化框架。

在下一章中，我们将更进一步，学习在 Power Platform 上实现 DevSecOps 流程。

进一步阅读

• az devops CLI： https://learn.microsoft.com/en-us/cli/azure/devops?view=azure-cli-latest

• Windows Subsystem for Linux： https://learn.microsoft.com/en-us/training/modules/wsl-introduction/

• Azure DevOps 批准 流程： https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass

• Power Platform 目录： https://learn.microsoft.com/en-us/power-platform/developer/catalog

• Azure DevOps 管道 模板： https://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops&pivots=templates-includes

• GitHub 启动 工作流： https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization

• GitHub 可重用 工作流： https://docs.github.com/en/actions/using-workflows/reusing-workflows

• Power Platform 的 ALM 加速器： https://learn.microsoft.com/en-us/power-platform/guidance/alm-accelerator/overview

• ALM 的源代码 加速器： https://github.com/microsoft/coe-starter-kit/tree/main/CenterofExcellenceALMAccelerator

• ALM 加速器管道 模板： https://github.com/microsoft/coe-alm-accelerator-templates/tree/main

• Power Apps 测试工作室: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/test-studio

• Visual Studio 单元测试: https://learn.microsoft.com/en-us/visualstudio/test/getting-started-with-unit-testing?view=vs-2022&tabs=dotnet%2Cmstest

• 使用 Azure DevOps 自动化测试的管道: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/test-studio-classic-pipeline-editor

• PowerApps 测试引擎: https://learn.microsoft.com/en-us/power-apps/developer/test-engine/overview

• Azure 负载测试服务: https://learn.microsoft.com/en-us/azure/load-testing/overview-what-is-azure-load-testing

• Microsoft Copilot Studio 测试框架: https://powervirtualagents.microsoft.com/en-us/blog/automate-testing-of-your-power-virtual-agents-chatbots-with-the-pva-test-framework-sample-solution/

• Microsoft Copilot Studio 实施指南: https://aka.ms/CopilotStudioImplementationGuide

第七章：Power Platform 中的 DevSecOps 概述

DevSecOps 是一种将安全实践融入整个 软件开发生命周期 (SDLC)的软件开发方法论，包括需求分析、规划与设计、开发、测试和质量保证，直到部署和维护。 Power Platform 是一个现代化的应用程序运行平台，使开发者能够构建自定义应用程序、自动化工作流、创建聊天机器人、设计和发布网站等。 该平台拥有强大的安全模型，确保数据保护并遵守行业标准（超过 90 个合规证书）；由 Azure DevOps 或 GitHub 建立的应用程序生命周期管理和 DevOps 流程，在处理任何类型的 开发项目时，默认部分考虑到这种安全整合。

本章将介绍设置安全的 DevOps 开发项目所需的步骤和行动，涵盖多个环境以及 Microsoft Entra ID支持的身份和访问管理。 我们还将学习如何使用 DevOps 工具大规模启动基于 Power Platform 的开发项目，使开发人员和贡献者能够快速构建和部署应用程序，同时保持安全性和合规性标准。 该平台还提供静态分析工具和报告，用于监控某些类型的安全威胁。 这有助于我们在减少网络风险的同时实现高效的生产力。 我们还将讨论使用开源库的自定义代码的安全影响，并将从 安全的角度检查我们的 DevOps 工具。

本章我们将涵盖以下 主要主题：

• 什么是 DevSecOps？

• Power Platform 的 安全模型

• 机密扫描和静态代码 分析工具

• 解决方案检查器

• 大规模启动 DevSecOps 项目 的实施

• DevOps 流程的 安全性

技术要求

要深入了解 DevSecOps 方法和工具，我们需要具备 以下内容：

• Power Platform 订阅：我们可以注册 Power Apps 开发者计划（ https://www.microsoft.com/en-us/power-platform/products/power-apps/free），如果我们已经有 Microsoft Entra ID 工作帐户，或者我们可以加入 Microsoft 365 开发者 计划（ https://developer.microsoft.com/en-us/microsoft-365/dev-program）

• Azure DevOps 服务组织：我们可以随时创建一个免费的 DevOps 组织（ https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates）。

• GitHub 账户和公共 仓库： https://github.com/signup

• GitHub 高级安全：此功能对公共仓库免费开放； 参见 https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security#about-advanced-security-features。

• 示例和演练 本章讨论的内容可以在以下位置找到 ： https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter07

什么是 DevSecOps？

DevSecOps 代表 的是 开发、安全和运维 以及这些领域的协作，以交付安全的应用程序。 它的原则是在定义 DevOps 过程和方法论后不久建立的。 这个理念相同，就是将 左移 的思维方式应用于安全领域，这与我们在质量保证和后来的运维中应用左移思维方式类似。 它是一个框架，将安全性整合到 SDLC 的所有阶段，从这个角度看，它是软件开发组织在处理安全问题时的一次演进，旨在通过引入“安全第一”的思维文化，并在软件开发生命周期的每个阶段（从设计到交付）自动化安全。 组织广泛采用这种方法，减少发布含有安全漏洞的代码的风险，不仅避免了声誉损失，还避免了因 此类失败而造成的高额财务损失。

如果我们回顾在 第一章 中学习到的 SDLC 的主要阶段（需求分析、规划与设计、开发、测试与质量保证、部署和维护），那么我们可以将安全活动和自动化映射到这些阶段，如下图所示：

图 7.1 – SDLC 中的安全性

这些步骤和活动 以及它们的持续改进构成了 安全开发生命周期 (SDL)。 SDL 是一种 软件开发过程，帮助开发人员构建和设计更安全的软件，满足安全合规要求，同时降低开发成本。 它在各项服务中标准化了安全最佳实践，并最终交付更 安全的产品。

让我们详细查看这些活动，并通过 SDLC 分析相应的 安全范围。

设置

在项目的 初始阶段，我们重点关注两个主要的 安全话题：

• 库存管理 是 安全性的重要元素之一，因为它 catalogizes 我们为客户提供的应用程序和服务。 这是我们的 应用目录 ，其中包含 我们的应用程序（产品）和 服务（服务树）在生产中的资产（源代码位置、发布的二进制文件、版本号、Azure DevOps 项目、Azure 管道、GitHub 项目、GitHub 工作流等）在我们组织内部。 借助库存管理，我们可以轻松找到受安全漏洞影响的组件的应用程序所有者。 在具有成熟 DevSecOps 流程的组织中，库存管理是完全自动化的，这意味着每当启动一个新项目时，就会创建一个新的目录项，并触发工作流来启动 Azure DevOps 或 GitHub 项目、Git 仓库、Microsoft Entra ID 组、服务主体、自托管代理、管道等。

• 访问控制管理 指的是 从工程角度访问应用程序工件，以及相应的底层 DevOps 工具。 我们需要定义框架 和 身份与访问管理 (IAM) 解决方案，用于授予产品所有者、工程师、测试人员、架构师、发布经理和运营团队在与开发项目交互时的访问权限。 我们还需要定义如何处理条件访问策略，例如 强制 多因素认证 (MFA) 以访问生产环境，以及我们在与特权身份管理 （PIM）合作时的程度， 例如，向高特权用户或全局管理员提供“即时”特权访问 Microsoft Entra ID 和 Azure 资源。 启用 PIM 后，这些高度特权的活动会被监控并 审计。 值得注意的是，这种访问控制并非我们要开发的应用程序或服务用于身份验证和授权的控制方式。

计划和设计

在设置好项目的适当访问权限和库存管理后，我们从安全角度深入探讨计划与设计阶段：

• 威胁建模 被用来识别我们系统的潜在威胁，通过潜在攻击者的视角，以及他们对我们的应用程序的可能性和影响，在实施任何缓解措施之前进行评估。它是一个典型的风险管理过程，专注于安全。 市场上有多种工具可用于建模威胁，例如 微软威胁建模工具（请参见进一步阅读部分）。作为冲刺计划过程的一部分，我们可以进行威胁建模演练，并根据风险分析来决定是否应缓解某些威胁，并将这些活动作为产品待办事项，标记为安全类别。

• SecureString 类型用于处理我们代码中的凭证。

• 同行评审指南 用于制定同行评审过程：评审将何时执行，执行的频率以及是否会涉及安全专家。 如今，DevOps 流程已经规定了在有拉取请求时必须进行代码审查，DevOps 工具也会详细记录和支持这些发现。

• 预提交钩子 定义了在提交代码更改到代码库之前，我们执行哪些安全检查，例如，在提交之前检查提交内容是否包含敏感信息。 由于时间限制，预提交钩子只能执行静态代码分析规则集的一小部分，但它们是 防止安全漏洞的必要部分，能立即阻止不安全的提交。 我们可以 使用 IDE 安全插件 来执行本地的轻量级安全分析。

提交（CI）

在通过了预提交钩子和代码审查结果后，下一阶段是执行 CI 构建和相关的安全活动，作为拉取请求验证过程的一部分：

• 依赖管理：如今，定制开发的应用程序在很大程度上依赖于 开源软件包。 目前应用程序中，平均 90%的代码包含基于外部软件包或 库的组件。 术语 软件供应链管理 非常常见，因为我们在应用中使用的这些软件包也使用其他第三方组件，而这些组件又使用其他包，依此类推，形成了一个链条。 如果不刷新我们的供应链，识别和暴露这些第三方包中的漏洞将使我们的应用变得脆弱。 像 GitHub Dependabot 这样的工具可以 识别我们供应链中的漏洞（继承的漏洞），并自动创建 Dependabot 警报，发起拉取请求，将更改提交回我们的主分支。 Dependabot 检查可以在 CI 构建过程中执行。

• 静态应用安全测试 (SAST)：这是对代码进行静态分析和安全扫描 以确保安全性。 市场上有几种工具可以用来对我们的代码库进行这种分析，例如 SonarCloud、Fortify 或带有 CodeQL 的 GitHub 高级安全。 这些工具可以集成到我们的 CI 管道中，以便进一步自定义。 静态代码分析结果的输出为 静态分析结果交换格式 (SARIF)开放标准数据。 基于 SARIF 结果，系统会自动创建代码扫描警报， 并且它们可以作为待办事项进行跟踪。 在使用 GitHub 企业版高级安全功能的情况下，我们还可以使用 GitHub Copilot 来自动修复我们的安全问题， 实现完全自动化。

• 安全单元和功能测试：这些是维护我们代码库高质量的其他方式，旨在避免实现 安全漏洞。

• 安全管道：我们需要谨慎关注自动化管道的安全性：谁可以访问哪些管道，管道机密信息存储在哪里（Azure Key Vault），以及我们是否可以使用托管标识来执行工作流程。 在 CI 构建期间，所谓的 软件材料清单 (SBOMs)会被创建，以跟踪构建管道中使用的组件。 SBOM 是软件组件的列表，包括它们的层次关系、版本号、依赖关系和许可要求，通常以 JSON 格式呈现。 SBOM 有助于透明度和供应链的可追溯性声明，并帮助符合要求的启用。 托管池可以用于构建和签署代码，确保构建的完整性和组件治理。 构建成功后，代码会存储在安全的 构件存储中。

• 凭证扫描：我们 可以使用工具扫描我们的代码库，以减少凭证泄露的风险。

部署（CD）

在这个阶段，我们 查看代码库的整体健康状况，除了在提交阶段检查的内容（这些内容也可以在部署阶段重复检查）。 我们在发布过程中引入了额外的安全检查：

• 动态应用安全测试 (DAST)是一种评估软件应用安全性的技术，它在应用程序运行时进行。 它涉及使用 DAST 工具对 Web 应用程序进行模拟的网络攻击，以识别 SQL 注入、跨站脚本攻击和不安全配置等漏洞。 这种安全测试模拟恶意攻击者的行为，以发现实时应用程序中的安全弱点，使开发人员能够在应用发布之前解决这些问题。 安全管道 是为了避免凭证泄露或在生产环境中执行恶意代码。

• 云配置验证 是验证云资源配置是否正确、安全，并符合最佳实践和政策的过程。 这可以通过自动化工具完成，这些工具扫描云资源的配置文件和设置，并报告任何问题或违规行为（例如生产环境中的配置更改，或 IaC 脚本与实际运行配置之间的不一致）。 验证有助于防止配置错误、安全漏洞和合规问题，确保云资源的正确设置和 管理。

• 基础设施即代码 (IaC) 扫描 是分析 IaC 文件以查找 安全漏洞、配置错误以及是否符合最佳实践和政策的过程。 IaC 扫描工具可以检测政策违规并提出修复建议。 甚至可以使用基于 LLM 的工具提示 GPT-4 模型，检测 IaC 文件中的政策违规，并为任何违规行为提供修复建议。 违规和修复会以 SARIF 文件形式报告。

• 安全验收测试 是验证系统在发布或部署前是否满足已定义的 安全要求和标准的过程。 这种测试通常在新系统、升级或部署时进行，包括对信息安全要求的测试以及遵循安全系统开发实践的测试。 验收测试活动可以在单个组件或集成系统上进行，验证活动可以在测试环境中进行，以确保系统不会引入漏洞。 在选择测试数据或来自运营中信息系统的数据时，必须小心，确保没有捕获任何个人身份信息、密码等机密数据或哈希值。 该数据集。

在成功部署到测试环境并随后部署到生产环境后，SBOM 和证据存储用于跟踪 版本发布。

操作与监控

在这个阶段，成功将我们的应用程序发布到生产环境后，我们需要关注以下 安全相关的活动：

• 持续监控 是 持续跟踪、评估和审查信息系统的安全控制和风险的过程。 这一过程有助于确保安全控制随时间保持有效，并确保系统或其环境的任何变化不会引入新的漏洞。 持续监控可以通过自动化工具和过程来实现，这些工具和过程收集并分析来自各种来源的数据，如日志、网络流量和系统配置。 然后，这些数据被用来识别潜在的安全问题，并生成可以用来提高系统安全性的警报或报告。 该系统的安全性。

• 审计日志 是 用于安全检测的监控对象。 进行管理员监控和扫描，以确保系统的安全性。 我们可以考虑我们解决方案的审计日志，就像我们的 DevOps 工具一样。 审计日志对于理解和检测可能来自可疑来源的变化至关重要。 可疑来源。

• 威胁情报 是 收集、分析和传播当前及潜在网络安全威胁信息的实践。 它帮助组织主动检测和应对安全威胁。 Microsoft 威胁情报是一个云服务，利用全球收集的信号上的机器学习算法来检测和缓解安全风险。 该基础设施用于支持 Azure 服务、传统产品、端点（设备）以及其他企业资产。 其目的是保护全球基础设施，支持如 Microsoft Azure 和 Power Platform 等服务。 安全事件和事件管理 (SIEM)工具，如 Microsoft Sentinel 或 Microsoft Defender for Cloud，利用审计日志通过不同的机器学习算法来检测异常和不寻常的模式。 学习算法。

• 无责事后分析 是一种以非惩罚性的方式分析事件或故障的过程，目的是识别根本原因并改进系统和流程，以防止类似事件再次发生。重点在于学习和改进，而不是指责或惩罚。无责事后分析鼓励开放和诚实的沟通，允许团队成员分享他们的错误并从中学习，而不必担心遭受报复。这种方法培养了持续改进的文化，帮助团队构建更具弹性的系统。

在接下来的部分中，我们将看到我们可以为 Power Platform 解决方案应用哪些活动，以及哪些任务由 Power Platform 的运维团队提供。

现在让我们继续了解 Power Platform 的安全模型，学习其安全设计和原则。

Power Platform 的安全模型

微软 Power Platform 运行在微软 Azure 上，受益于在该超大规模平台上可用的所有 PaaS 安全服务，如 Microsoft Sentinel、Microsoft Defender for Cloud、Microsoft Entra 的全面审计日志等。

微软 Power Platform 的安全模型建立在最小权限访问（LPA）的原则之上，这有助于创建具有更精细访问控制级别的应用程序。Power Platform 利用微软身份平台来授权所有 API 请求，采用广泛认可的 OAuth 2.0 协议。此外，作为 Power Platform 基础数据层的 Dataverse 拥有一个全面的安全模型，涵盖了环境级安全、基于角色的安全以及记录和字段级安全、安全角色、通过安全组和应用用户的业务单元和团队，正如我们在第四章中所了解的。

此外，Power Platform 构建在不同的环境中，这些环境是我们应用程序、流程、连接和其他组件的容器，并具有在创建这些环境时定义的地理位置的安全性和数据访问管理能力。

Power Platform 的架构基于零信任安全原则， 永不信任，总是验证 的哲学。 零信任策略 **要求对每个用户和 设备进行严格的身份验证，无论其位置如何（公司内网或外部边界），并且每次访问公司资源时都会进行此检查。 这种方法通过微软身份平台和 Microsoft Entra ID 的能力得以实现。 每次访问 Power Platform 服务端点时，都需要有效的访问令牌（承载令牌）才能执行该端点。 在服务器端，每次请求到达端点时，都会将访问令牌发送到身份提供者（即 Microsoft Entra ID）以验证其有效性。 这些经过数字签名的访问令牌包含关于调用者的声明，用于身份验证和授权目的。 在识别出调用者后，Power Platform 会结合该端点确定其授权级别。 在此，考虑到自定义和内置安全角色、业务单元层级以及团队分配，这些都是 应用级授权。

下图 展示了 Power Platform 在一个 Microsoft Azure 区域中的架构：

图 7.2 – Power Platform 架构

一组网页 前端服务器包含托管在 Azure 应用服务环境中的 ASP.NET 网站。 应用服务环境 提供了底层的专用计算单元，应用服务计划在其上部署。 应用服务计划可以托管一个或多个应用程序（网站）。 这些都是 Azure 应用服务的一部分。 当访问 Power Platform 服务或应用时，客户端的 DNS 会将请求定向到最近的数据中心，具体由 Azure Traffic Manager 确定。 Azure Traffic Manager 提供了几种路由和负载均衡选项，在 OSI 模型的第 4 层进行，例如性能路由（按延迟选择最接近的端点）、加权轮询和基于地理位置的路由（按 地理位置选择最接近的端点）。

前端集群负责处理登录和身份验证过程。 一旦用户通过验证，他们会收到一个 Microsoft Entra ID 访问令牌（OAuth2 令牌）。 ASP.NET 系统会检查令牌，以识别用户的组织（后台使用的是 多租户 帐户类型的 Azure 应用注册）。 然后，它与 Power Platform 全球后端服务进行通信，通知浏览器该组织租户所在的具体后端集群。 之后，客户端与后端集群之间的所有进一步交互都会直接发生，绕过 网页前端。

对于静态资源，如 JavaScript、CSS 和图像文件，浏览器通常会从 Azure 内容分发 网络 (CDN) 获取它们。

Power Platform 服务的核心 运行在 后端集群 中，提供服务端点、后台服务、数据库、缓存和其他各种元素。 后端集群遍布多个 Azure 区域。 单个区域可能容纳多个集群（在前面的图中表示为 规模组 ），使 Power Platform 服务能够超越单个集群的垂直和水平扩展能力，进行水平扩展。

这些后端集群旨在 保持状态，承载它们所服务的所有租户的完整数据集。 存储某个租户数据的特定集群被称为该租户的主集群。 Power Platform 全球后端服务将有关用户主集群的详细信息提供给 Web 前端集群，后者会将请求定向到适当的主后端集群。 每个环境都驻留在一个规模组内，这是一个集体基础设施，旨在提供可扩展且可维护的资源集合。 一个规模组容纳多个客户组织，每个组织拥有自己的数据库，同时共享服务基础设施。 此设置利用了多种 Azure 服务，例如 Azure SQL、Azure 虚拟机和 Azure Cache for Redis。 这些规模组成对建立，分别对应客户选择的区域。 例如，选择美国作为区域时，会在西部美国和东部美国区域形成规模组。 虽然租户元数据和数据通常驻留在集群内，但数据也可以复制到位于同一 Azure 地理区域中配对区域的次要后端集群。 该次要集群在区域性中断期间作为应急备用，否则保持不活动状态。 此外，分散在集群虚拟网络内各种机器上的微服务也有助于 后端的功能。

DevSecOps 流程和活动由 Power Platform 产品团队实现并运营，我们将其视为 这部分 软件即服务 (SaaS)提供的一部分。 这意味着产品工程团队已经建立了从库存管理、访问控制、提交前钩子、同行评审、SAST 和 DAST 分析、安全管道、IaC 扫描到通过威胁情报进行的依赖性分析等一系列控制和防护措施，涵盖了他们的开发流程。 这一方法经过第三方独立审计员的定期审计和认证。 在开发过程中，这些团队还使用 Microsoft SDL 来确保编码最佳实践和威胁建模。 由此得出的结论是，我们需要专注于平台的定制化和可扩展性点，因为这些是 我们可能引入 漏洞的地方。 这些包括但不限于 以下内容：

• 环境 访问管理

• 自定义开发的 Power Apps 组件框架 （PCF）组件

• Dataverse 自定义工作流活动和 Dataverse Web 资源（HTML 和 JavaScript）

• Dataverse 配置和 Dataverse 自定义开发的插件

• Power Fx 表达式

• Power Pages 自定义代码（HTML、JavaScript、 和 Liquid）

• 我们自己的 DevOps 流程与 CI/CD 自动化脚本

• 解决方案和 库存管理

• Fusion 架构组件 在 Microsoft Azure 中

在了解 Power Platform 的安全模型及从安全角度看该 SaaS 产品的优势后，让我们进一步了解可以用于静态代码分析、依赖性检查和 密钥扫描的工具。

密钥扫描和静态代码分析工具

尽管市场上有许多其他 SAST 工具， GitHub 高级安全性 （GHAS）提供了 最全面的静态安全代码分析功能，同时支持 Copilot 安全功能。 GHAS 功能 对于私有 GitHub 代码库如下：

• 代码扫描 使用 CodeQL 或其他 您喜欢的工具来查找漏洞 和编码错误。 结果以 SARIF 格式存储，并在 GitHub 的代码库级别进行管理。

• CodeQL CLI 是一个独立的 工具，我们可以用它扫描代码库中的漏洞和编码错误。 该 CodeQL CLI 与前述的（代码扫描）一起使用，或者可以在其他 DevOps 工具中使用，例如 GitLab 或 Jenkins。

• 密钥扫描 查找 代码库中的秘密、密钥和敏感令牌。 预提交钩子 也可用来阻止本地提交 在到达代码库并创建新 历史记录之前。

• 自定义自动分类规则 有助于 大规模协调 你的 Dependabot 提示 。使用自定义自动分类规则，你可以决定忽略、推迟或触发 Dependabot 安全 更新。

• 依赖性审查 帮助我们 在将不安全的依赖引入我们的代码库之前进行识别 并提供有关许可证、依赖项和依赖项年龄的信息。

这些高级安全功能在每个公共的 GitHub 仓库中都可以使用，无需额外的 费用。

GHAS for Azure DevOps 于 2023 年 9 月正式发布。 此产品提供的代码扫描、密钥扫描和依赖扫描功能与 GitHub 企业版中的功能相同。 GitHub 工程团队已与 Azure DevOps 团队分享这一功能集，就像几年前 Azure DevOps 团队将构建代理（托管运行器）功能提供给 GitHub 产品组一样。

哪种工具，何时使用？

我们只能在 Azure DevOps 中使用 GHAS 来处理 Azure Git 仓库。 如果我们有一个附加到 Azure DevOps 流水线的 GitHub 仓库，我们需要在 GitHub 端使用 GHAS。 Azure DevOps 中的 GHAS 构建任务将 无法工作。

GHAS 基于 的 代码查询语言 (CodeQL)，可以用于构建不同编程语言的代码分析数据库。 CodeQL 支持 C、C++、C#、Java、Go、Kotlin、JavaScript、Python、Ruby、Swift 和 TypeScript。 CodeQL 将代码视为数据，比传统的静态分析工具更有保障地发现潜在的安全漏洞。 通过创建一个与代码库相匹配的 CodeQL 数据库，你可以对这个数据库执行 CodeQL 查询，以查明代码中的问题。 查询结果将显示为 代码扫描警报 ，当你在 GitHub 和 Azure DevOps 中使用 CodeQL 进行 代码扫描时。

CodeQL 在底层创建了一个关系数据库。 每种语言都有自己的架构，CodeQL 使用 提取器 (每种语言都有独特的提取器)来读取代码文件和编译后的二进制文件（脚本语言除外），并建立代码表达式、抽象语法树、数据流图和控制流图的层次表示。 这些构建块存储在数据库中，安全查询会针对这些表执行，以发现特定语言的漏洞和编码错误。 CodeQL 的数据库是我们执行分析时的快照。 GitHub 提供了适用于任何支持语言的查询包。 查询包 由 组成 CodeQL 套件 (qls) 是查询语言文件集（ql 文件）。 这些查询套件帮助我们立即受益于 GitHub 的安全知识和专业技术，并在我们的代码库上执行这些代码扫描规则。 我们还可以使用 Visual Studio Code 和 CodeQL 扩展编写自己的查询，并可以从现有查询套件中派生，增加我们自己的检查（Windows 驱动验证团队就是这样做的，引入了他们自己的自定义 规则： https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/static-tools-and-codeql）。

CodeQL CLI 是 GHAS 服务的一部分，对学生和学术人员免费。 作为独立工具的 CodeQL CLI 支持 macOS、Linux 和 Windows 操作系统，我们可以将其作为二进制文件下载（请参见 进一步阅读）。

我们可以使用 CodeQL CLI 在本地、Azure DevOps 构建代理，或我们的 GitHub 执行器上执行代码分析。

Azure DevOps 和 GitHub 都提供围绕 CodeQL CLI 的构建任务和操作，便于将代码扫描功能轻松集成到现有的流水线 和工作流中：

图 7.3 – DevOps 工具中的 CodeQL CLI 包装器

由于 在 Power Platform 中有许多地方可以引入自定义代码，建议首先了解如何使用 CodeQL CLI 以及如何设置管道和工作流来执行不同的查询包。 最好的地方是 找到Power Platform 的自定义代码在 PowerApps-Samples 仓库，地址是 https://github.com/microsoft/PowerApps-Samples。让我们检查一下本章中的 GitHub 仓库中的自定义 runcodeql_javascript.ps1 文件：

1. 我们可以下载 CodeQL CLI 二进制文件（见 深入阅读 | CodeQL CLI 二进制文件），并将解压后的文件夹位置添加到我们的 环境路径中。

2. 然后我们克隆该仓库并导航到 目标文件夹：

   git clone https://github.com/microsoft/PowerApps-Samples
   

3. 让我们下载 JavaScript 和 TypeScript 的查询包：

   codeql.exe pack download codeql/javascript-queries --dir ./codeql-pack/javascript
   

4. 让我们为 JavaScript/TypeScript 创建 CodeQL 数据库（目前只有一个 JS/TS 提取器）：

   codeql-pack and export the results in a CSV file:
   
   

   codeql.exe database analyze .\codeql-database-js .\codeql-pack\javascript\codeql\javascript-queries\0.8.12\codeql-suites\javascript-code-scanning.qls --format=csv --output=results.csv

5. 当然，我们可以分析代码并以 SARIF 格式获取结果：

   codeql github upload-results to upload our SARIF file to one of our GitHub repositories (we cannot upload back the results to the original repository due to lack of privileges). We need to create a PAT token that grants us access to the repo (security_event):
   
   

   上传结果到 GitHub 仓库

   $env:GH_PAT = "ghp_PAT TOKEN"

   $env:GH_PAT | & codeql.exe github upload-results `

       --repository=ourrepo/test `
   
       --ref=refs/heads/main `
   
       --commit 18cd21585b94dd16c48dc13bc1365269696a75a4 `
   
       --sarif=javascript.sarif --github-auth-stdin
   

   
   We also need to have a commit hash ID to which we upload the SARIF result.
   

对于 C# 项目和解决方案，CodeQL 命令略有不同。 例如，当 我们需要实现 Dataverse 插件时，可以使用 C# 查询包，但在这种情况下，我们还需要在分析过程中构建 Visual Studio 项目（见 runcodeql_dotnet.ps1 文件，位于 Chapter07 文件夹下，在 GitHub 仓库中）：

 codeql.exe pack download codeql/csharp-queries --dir ./codeql-pack/csharp
codeql.exe database create --language=csharp --source-root . codeql-database --command "dotnet build .\dataverse\DiscoveryService\DiscoveryService.sln" --overwrite
codeql.exe database analyze .\codeql-database .\codeql-pack\csharp\codeql\csharp-queries\0.8.12\codeql-suites\csharp-code-scanning.qls --format=csv --output=csharp-results.csv

我们使用 --command 参数来为一种或多种编译语言创建数据库。 它需要我们用来构建解决方案的 build 命令，例如 dotnet build <<sln 文件路径>>。如果我们使用的是 Python 或 TS/JS，则不需要此选项。

在大规模代码库的情况下，我们可以使用以下技巧来优化 CodeQL 的运行时：

• 查询包：我们 可以创建自己的查询包，基于公开可用的查询包，也可以创建自己的查询套件，专注于不同的代码扫描和安全扫描分析，这取决于我们在流水线中的时间。 例如，在拉取请求验证构建期间，我们希望通过专注于最关键的安全漏洞来最小化分析的执行时间，而构建主分支时则会执行所有可用的 查询套件。

• codeql database analyze：如果我们希望使用多个线程运行查询，可以使用 --thread 参数 。默认值为 1，这意味着分析仅在一个线程中运行。 我们可以指定更多的线程来加速查询执行。 要将线程数设置为逻辑处理器的数量，我们可以将此参数设置为 0 。

• 仅针对部分代码库执行 CodeQL：理想情况下，我们可以拥有拉取请求流水线/工作流，这些工作流不仅包含拉取请求发生的触发条件，还可以 包含 路径过滤器 来过滤源代码中的变更。 这样，CodeQL 只会针对源代码层次结构中已变更的部分执行。 通过这种方式，CodeQL 仅在源代码中已更改的区域运行。

最后，我们深入了解可用的 Azure 流水线构建任务 在 .pipelines/codeql.yml 文件中，该文件位于 Chapter07 文件夹下的 GitHub 仓库中：

1. 让我们 导入 https://github.com/microsoft/PowerApps-Samples 到我们的 Azure DevOps 项目中。 我们需要进入 代码库 并点击包含所有仓库的下拉列表，在该列表中我们可以找到 导入仓库 操作项：

图 7.4 – 导入 Git 仓库

在这里，我们可以添加 GitHub 公共仓库的 URL 并 导入 PowerApps-Samples。

1. 通过打开项目设置启用 Advanced Security 功能（需要项目管理员权限），然后选择最近导入的仓库。 我们 需要启用 Advanced Security ，方法是切换 按钮：

图 7.5 – 在 Azure DevOps 中启用高级安全功能

1. 启用此安全功能后，我们可以导航到 Pipelines，然后我们可以创建一个新的管道 YAML 文件，该文件将存储在新的 Git 仓库中。

2. YAML 文件应如下所示：

    trigger:
   - none
   pool:
     vmImage: ubuntu-latest
   steps: - task: PowerPlatformToolInstaller@2
    inputs:
    DefaultVersion: true
   - task: AdvancedSecurity-Codeql-Init@1
    inputs:
    languages: 'javascript'
    querysuite: 'code-scanning'
   - task: AdvancedSecurity-Codeql-Analyze@1
    inputs:
    WaitForProcessing: true
   

   此 YAML 文件将执行与之前使用 PowerShell 对 JavaScript 进行的相同的 CodeQL 分析，通过 CodeQL CLI。

3. 代码扫描和密钥扫描警报列在 Repos 下的 Advanced Security 选项卡中，位于 Azure DevOps 中：

图 7.6 – 在 Azure DevOps 中的代码和密钥扫描结果

在 GitHub 的情况下，我们可以通过分叉 PowerApps-Samples 并创建 与代码分析相关的操作（请参阅 .github/workflows/codeql.yml 文件，位于 Chapter07 文件夹中的 GitHub 仓库中）：

 name: "CodeQL"
on:
  workflow_dispatch:
jobs:
  analyze:
    name: Analyze javascript
    runs-on: ubuntu-latest
    timeout-minutes: 120
    permissions:
      # required for all workflows
      security-events: write
      # only required for workflows in private repositories
      actions: read
      contents: read
    steps: - name: Checkout repository
 uses: actions/checkout@v4
 - name: Initialize CodeQL
 uses: github/codeql-action/init@v3
 with:
 languages: javascript-typescript
 build-mode: none
 - name: Perform CodeQL Analysis
 uses: github/codeql-action/analyze@v3
 with:
 category: "/language:javascript-typescript"

使用 Azure DevOps 管道模板和可重用的 GitHub 工作流，我们可以轻松地在每个项目中引入这些额外的代码扫描和安全分析步骤。 幸运的是，还有另一种方法可以在 Power Platform 解决方案中注入安全验证和代码扫描检查，那就是 解决方案检查器。

解决方案检查器

解决方案检查器 利用 Power Apps 检查服务，通过提交任务到 Power Platform 后端执行代码分析。 有 预定义的 规则集 和 规则 用于覆盖我们解决方案的某些安全建议和编码最佳实践。 解决方案检查器可以以 SARIF 格式报告找到的问题，我们可以轻松将其上传到我们的 DevOps 工具中，例如使用 GitHub 的 GHAS 或 Azure DevOps 的 GHAS。 解决方案检查器检查以下 Power Platform 资产 中的非托管解决方案：

• Dataverse 自定义 工作流活动

• Dataverse Web 资源（HTML 和 JavaScript）

• Dataverse 配置，例如 SDK 消息步骤

• Power Automate 流程（通过 Power Automate Flow Checker）

• Power Fx 表达式（通过应用检查器 – Power Apps 检查服务的一部分）

规则集及其规则是预定义并分类的，涵盖了之前列出的组件：插件或工作流活动、Web 资源以及画布应用。 我们可以通过多种方式执行 解决方案检查器，以检查 非托管解决方案：

• 在 Power Apps 创建者门户的 解决方案 面板中。

• 使用 pac solution check 命令，带上正确的参数，例如 如下：

  pac solution check call on that blob using Microsoft.PowerApps.Checker.PowerShell, and respectively the Get-PowerAppsCheckerRulesets cmdlet for fetching the pre-built rulesets and the Invoke-PowerAppsChecker cmdlet for submitting the analysis job to the Power Platform backbone. However, these cmdlets are in the pre-release version and they might change.
  

• 使用 以下 Power Apps 检查器 Web API：Power Apps 创建者门户、PAC CLI 和 PowerShell 模块都依赖于这些 REST API 端点。 我们可以直接调用这些端点，前提是有适当的访问令牌；例如， 美国端点可通过以下 URL 访问： 以下是 https://unitedstates.api.advisor.powerapps.com。

• 使用 托管环境 在导入解决方案到目标环境之前强制执行解决方案检查器运行。 在此，我们可以阻止导入解决方案，如果遇到违反这些规则的情况 。

• 利用 PowerPlatformChecker@2) 在从 Git 仓库导入解决方案的过程中。 此任务在后台使用 PAC CLI。

让我们来看一下在 Azure 管道中执行静态代码分析的构建任务，该任务分析我们的 解决方案（见 .pipelines/solution-checker.yml 在 第七章 文件夹中的 GitHub 仓库）：

 trigger:
- none
pool:
  vmImage: ubuntu-latest
variables:
 solutionName: "PacktCopilotSolution"
steps:
- task: PowerPlatformToolInstaller@2
  inputs:
    DefaultVersion: true
- task: PowerPlatformPackSolution@2
  inputs:
    SolutionSourceFolder: '$(System.DefaultWorkingDirectory)/src/$(solutionName)'
    SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip'
    SolutionType: 'Unmanaged' - task: PowerPlatformChecker@2
 inputs:
 authenticationType: 'PowerPlatformSPN'
 PowerPlatformSPN: 'dev-US_XXX_Y'
 FilesToAnalyze: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip'
 RuleSet: '0ad12346-e108-40b8-a956-9a8f95ea18c9'
PowerPlatformChecker@2 task to perform the solution check. The RuleSet GUID is the solution checker ruleset. There is only one other and that is AppSource certification for submitting solutions for Microsoft AppSource. We need to define a service connection, as we did in *Chapter 6*, to connect to an environment because the AppChecker service job executes solution validations in environments. Although we reference here a local unmanaged solution, that solution is uploaded to the environment before the analysis. The results are not stored in the environment but exported as a SARIF file. The build task also publishes the SARIF result to the artifacts of pipeline results.
			In the case of GitHub, we can use the following workflow to achieve the same result (see `.github/workflows/solution-checker.yml` in the `Chapter07` folder of the GitHub repo):

名称：解决方案检查器

触发：

workflow_dispatch:

作业：

solutioncheck:

在：ubuntu-latest

环境：

解决方案：mpa_ITBase

步骤：

- 使用：actions/checkout@v3

- 名称：安装 Power Platform 工具

    使用: microsoft/powerplatform-actions/actions-install@v1 - 名称: 打包未管理的解决方案

使用: microsoft/powerplatform-actions/pack-solution@v1

使用：

解决方案文件夹: ${{ env.Solution }}

解决方案文件: ${{ env.Solution }}_unmanaged.zip

解决方案类型：未管理

• 名称：检查解决方案

使用: microsoft/powerplatform-actions/check-solution@v1

使用：

环境网址: https://yourorg.crm.dynamics.com

应用程序 ID: 862e5a17-d38b-BBBB-FFFF-88a77f59623f

客户端密钥：“${{ secrets.CLIENTSECRET_DEV }}”

租户 ID：4ae51f31-033a-XXXX-YYYY-5ece14d2c081

microsoft/powerplatform-actions/pack-solution@v1，还将 SARIF 结果上传到 GitHub 工作流运行的工件中。

        管理发现

        无论是使用带有 SARIF 结果的解决方案检查器、GHAS，还是其他代码和依赖扫描工具执行 SAST，在收集结果后，我们还需要管理这些发现。 我们可以通过接受这些风险来减轻风险，例如在测试代码中的安全警报不被修正，或者我们可以引入新的问题或工作项，根据发现和相应描述的漏洞 在 **常见弱点枚举** (**CWE**) 数据库中。 现代 DevOps 工具支持将代码扫描、依赖扫描和密钥扫描警报链接到工作项或问题，并在开发 生命周期中引入修复需求。

        现在我们已经熟悉了解决方案检查器、GHAS 功能以及与 SDLC 方法论相关的 DevSecOps 流程中的任务，我们将这些知识与来自 *第六章*的自动化 DevOps 流程结合起来。

        大规模启动 DevSecOps 项目

        在 *第六章*中，我们学习了如何为我们的 Git 仓库分配解决方案并相应地设置底层分支来启动 Power Platform 环境。 我们在 GitHub 中创建了管道模板和可重用的工作流，以提供以下自动化功能：

            +   启动新的 Power Platform 开发者环境

            +   为这些 Power Platform 环境创建服务连接

            +   从开发者环境导出解决方案到 Git 分支

            +   通过拉取请求或直接将解决方案从 Git 仓库和分支导入目标环境，或导入到我们的 开发分支

        我们可以在这段旅程中迈出一步，自动化整个 Power Platform 解决方案的开发过程。 首先，让我们引入一个新术语：工作负载。 **工作负载** 由一个或多个相互配合的解决方案组成，旨在实现复杂的业务需求。 我们可以将它们视为包部署器包的输入解决方案，例如我们在 **企业模板** 中学到的内容，在 *第四章*中学到的内容。要为工作负载或独立解决方案设置一个企业级的 DevSecOps 项目，我们需要完成以下额外的自动化任务：

            1.  为所有者和贡献者创建 AAD 组（Microsoft Entra ID 组）。 必须至少有两个所有者在 `所有者` 组中。 在大多数情况下，我们建议指定一个预算所有者和一个技术所有者来负责 项目。

            1.  为每个工作负载创建测试和生产环境，或者使用现有的共享环境来托管更多的解决方案 。

            1.  为这些环境创建 服务主体，使用 `pac admin create-service-principal` 和之前创建的 `所有者` AAD 组 。

            1.  创建一个 Azure DevOps 项目，并将 `所有者` AAD 组分配给 `贡献者` 组， **贡献者** 组分配给 Azure DevOps。

            1.  为工作负载或解决方案在 Azure DevOps 项目中创建一个 Git 仓库，并设置分支策略 。

            1.  为这些环境创建服务连接，使用我们创建的服务主体。 这正是我们在 *第六章*中所做的。

            1.  创建使用位于单独专用库中的管道模板的 CI/CD 管道，并配置它们以使用这些新的服务连接 作为参数。

        最终，我们可以实现以下的 项目设置：

        ![图 7.7 – DevSecOps Power Platform 项目](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_7.jpg)

        图 7.7 – DevSecOps Power Platform 项目

        我们可以在此看到 这里的 `所有者` 和 `贡献者`) 可以在项目中工作。 成员变更被记录到 **Azure Log Analytics 工作区** 并 由 SIEM 解决方案监控，如 Microsoft Sentinel（威胁情报）。

        我们可以借助 的帮助 **Azure 管道** 位于一个单独的 Azure DevOps 项目中。 让我们详细查看这些步骤 ：

            1.  创建 AAD 组：

要创建 AAD 组，我们可以使用以下脚本（参见 `create-aad-group.sh` 在 `第七章` 文件夹中的 GitHub 仓库）：

```
 #!/bin/bash
set -e
# Variables
SERVICE_PRINCIPAL_APP_ID="<your-service-principal-app-id>"
SERVICE_PRINCIPAL_SECRET="<your-service-principal-password>"
TENANT_ID="<your-tenant-id>"
GROUP_NAME="<your-group-name>"
# Login as the service principal az login --service-principal -u $SERVICE_PRINCIPAL_APP_ID -p $SERVICE_PRINCIPAL_SECRET --tenant $TENANT_ID # Create the AAD group az ad group create --display-name $GROUP_NAME --mail-nickname $GROUP_NAME # get the user object id AADObjectID=$(az ad user show \
 --id $userPrincipalName \
 --query id \
 --output tsv) # add a member to the group pac admin create commands to create Power Platform developer environments. To create a sandbox or a production environment, we can use the following script (see create-powerplatform-env.sh in the Chapter07 folder of the GitHub repo):

```

#!/bin/bash

set -e

# 定义环境变量

SERVICE_PRINCIPAL_APP_ID="<your-service-principal-app-id>"

SERVICE_PRINCIPAL_SECRET="<your-service-principal-password>"

TENANT_ID="<your-tenant-id>"

ENV_NAME="YOUR_ENV_NAME"

REGION="YOUR_REGION"

CURRENCY="YOUR_CURRENCY"

LANGUAGE="YOUR_LANGUAGE"

# 使用服务主体登录到 Power Apps pac auth create --applicationId $SERVICE_PRINCIPAL_APP_ID --clientSecret $SERVICE_PRINCIPAL_SECRET \

--tenant $TENANT_ID # 创建一个新环境 pac admin create --name $ENV_NAME --region $REGION \

--currency $CURRENCY --language $LANGUAGE \

--type 生产环境

rawOutput=$(pac admin list --name $ENV_NAME | tail -n 2)

environmentId=$(echo $rawOutput | cut -d ' ' -f 2) #启用托管环境 pac admin set-governance-config \

--environment $environmentId \

pac admin set-governance-config 命令以启用托管环境功能。

```

```

                1.  创建 服务主体 用于环境：

正如我们在 *第五章*中所做的，我们可以使用以下 PAC CLI 命令来创建一个分配给新创建环境的服务主体：

```
AzureKeyVault@2 build task.
```

                1.  创建一个 Azure DevOps 项目：

在这里，我们需要使用 一个 `System.AccessToken` ，并且我们可以引用这个令牌来执行管理或全组织范围的操作。 通过这种方式，我们可以消除 个人访问令牌的使用，并且我们可以在集合级别为构建服务帐户授予访问权限和特权。 为此，我们需要禁用 **将作业授权范围限制为当前项目（针对非发布管道）** 和 **将作业授权范围限制为当前项目（针对发布管道）** 选项，位于 **项目设置** 中的 **设置** 面板，在将托管我们管理管道的项目中，如下图所示：

        ![图 7.8 – System.AccessToken：项目与组织范围](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_8.jpg)

        图 7.8 – System.AccessToken：项目与组织范围

        如果这些切换按钮被禁用，我们需要在组织级别关闭它们。 最后，我们需要在我们的管道中授予权限，使用 `$(System.AccessToken)` 系统变量来执行以下脚本（请参见 `.pipelines/setup-azure-devops-project.yml` ，位于 `Chapter07` 文件夹中的 GitHub 仓库）：

echo $(System.AccessToken) | az devops login --organization $(System.CollectionUri)
az devops project create --name ${{ parameters.projectName }} --org $(System.CollectionUri)
aadAdminGroupId=$(az ad group show --group $(AADGroupForAdmin) --query id -o tsv) echo "Admin group id: $aadAdminGroupId" azureDevopsAdminGroupDescriptor=$(az devops security group list --organization $(System.CollectionUri) --project ${{parameters.projectName}} | jq -r '.graphGroups[] | select(.displayName=="Project Administrators") | .descriptor') echo "Azure DevOps Admin Group Descriptor: $azureDevopsAdminGroupDescriptor"
# Add the AAD group to the Administrators groups in Azure DevOps
collectionUri=$(System.CollectionUri)
orgnamewithouthttps=${collectionUri//https:\/\//} curl -u :$(System.AccessToken) \
 -H "Content-Type: application/json" \
 -d "{\"originId\": \"$aadAdminGroupId\"}" \
az devops security group membership add --group-id $azureDevopsAdminGroupId --member-id $aadAdminGroupId --org $(System.CollectionUri) command doesn’t work across projects.

				1.  Create a Git repository:

    When creating a new Azure DevOps project, a default Git repository with the name of `project` and a default team is created. To create a repository, we can use the `az repos create` command with the appropriate parameters. We need the following variables in our Bash script:

    ```

    # 变量

    organizationURL="<Your-Azure-DevOps-Organization-URL>"

    project="<Your-Azure-DevOps-Project>"

    repository="<Your-New-Repository-Name>"

    pat="<Your-Personal-Access-Token>"

    main 分支：

    ```

    ```

    organizationName=$(basename $organizationURL) git clone https://$organizationName@dev.azure.com/$organizationName/$project/_git/$repository cd $repository git checkout -b main echo "# $repository" >> README.md git add .

    git commit -m "初始提交"

    main 分支通过引入对拉取请求中关联工作项的检查，防止直接提交（请参见 GitHub 仓库中create-gitrepo-and-branch-policy.sh，位于Chapter07文件夹）：

    ```
    az repos policy work-item-linking create \ ....--branch "refs/heads/main" \
     --enabled true --organization $organization --project $project \
     --repository $repositoryId --blocking true --detect false
    ```

    ```

    				2.  Create service connections for Power Platform environments:

    We did this exercise in *Chapter 6*, in the *Branches and* *environments* subsection.

				3.  Create CI/CD pipelines on pipeline templates:

    To create an Azure pipeline that uses a pipeline template from a different Git repository in a different Azure DevOps project, we can use the `resources` keyword in our pipeline YAML file to specify the repository containing the template. Then, we can reference the template in our pipeline. Here is an example for this (see `.pipelines/azure-pipelines-using-template.yml` in the `Chapter07` folder of the GitHub repo):

    ```

    资源：

    仓库：

    - 仓库：templates

    类型：git

    名称：OtherProject/TemplateRepo

    引用：refs/heads/main

    端点：MyServiceConnection 步骤： #或阶段：

    - 模板：.pipelines\ include-paccli-steps.yml@templates

    --yml-path 选项。要创建这些 YAML 文件，我们可以使用先前讨论过的 Git 命令提交基线流水线，这些流水线已经引用了丰富了秘密扫描和静态代码分析的流水线模板。

    ```

			At the end of these steps, we have the new Azure DevOps project and the new Git repository with pipelines in place that use the service connections to connect to the Power Platform environments and leverage pipeline templates located in a centralized repository governed by Microsoft Entra ID.
			We can realize the same approach in GitHub. The only difference here is that we need to configure our GitHub organization to use Microsoft Entra ID through the **SAML protocol**. GitHub can provision enterprise accounts with the help of a **system for cross-domain identity management** (**SCIM**) configuration. This means we can add Microsoft Entra ID accounts to GitHub Enterprise organizations and, respectively, repositories, and those users can sign in.
			Microsoft Entra ID
			Regarding the DevOps tools we use, the main security takeaway is that we need to embrace Microsoft Entra ID accounts and, respectively, groups to manage access to projects, repositories, pipelines, work items, workflows, and so on. From the administration perspective, we want to manage only memberships of Entra ID groups to grant or remove access to DevOps services and we do not allow individuals account-level access to our services.
			Of course, there are many other tasks that we can introduce in our development life cycle stages. One of the most crucial activities is Inventory Management as discussed in the *Setup* section of this chapter. Inventory Management can be realized within Power Platform on Dataverse as well. The setup of new development projects can be managed with the help of Power Automate cloud flows that execute those previously discussed Azure DevOps pipelines behind the scenes. The Inventory Management repository can store the metadata about our projects, such as who the owners are, where the source code/solution packages are located, which Entra ID groups are created, which Power Platform environments are spun up, and so on.
			However, as illustrated in the following figure, there are numerous additional tasks, including those activities we discussed at the beginning of the chapter in conjunction with custom development projects, that occur at different stages of the SDLC of Power Platform solutions:
			![Figure 7.9 – DevSecOps activities in Power Platform solutions](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_9.jpg)

			Figure 7.9 – DevSecOps activities in Power Platform solutions
			For instance, we can introduce more security analysis tasks in our pipelines, such as using GHAS or CodeQL for SAST, we can create our own build farms for our dedicated builds, apply code signing for our binary components or even for our Power Apps native mobile apps (wrap the app), perform DAST, execute test automation during CI/CD steps, and also set up advanced monitoring to read and analyze the DevOps audit logs or even the application logs. This is only the tip of the iceberg since projects and organizations are continuously improving their DevSecOps practices and, with that, their security postures as well.
			We now delve into our final topic, the security of our established DevOps processes.
			Security of DevOps processes
			Creating DevSecOps processes and setting up whole development projects fully automated from scratch is necessary to infuse security tasks in every phase and stage of the development life cycle. On the other hand, we need to consider our established DevSecOps processes for security vulnerabilities and the attack surface as well. In the previous sections, we have seen that with the help of Microsoft Entra ID groups, we can control and guardrail access to our running projects, but it is only one of the first steps to create more secure methods in those processes. We need to continuously monitor the activities of our engineers and DevOps teams, such as accessing repositories and executing workflows/pipelines by logging them to Log Analytics workspaces. We can then use threat intelligence tools such as Microsoft Azure Sentinel to discover unusual patterns throughout the application life cycle. We can also create threat models using Microsoft’s Threat Modeling Tool on our own CI/CD pipelines to play around with security scenarios, such as how to avoid vulnerable code injections through DevOps tools, or how to avoid granting access to a developer in production environments via DevOps pipelines or GitHub workflows from risk and probability perspectives.
			Mission-critical workloads operating in highly regulated industries and environments, such as the US government cloud or deployments in the financial sector, require even more guardrails in place. We can fully isolate Power Platform development tenants from production ones. The handover between these separate tenants can happen through **Azure Service Bus** or other messaging queue services, as the following figure shows:
			![Figure 7.10 – Isolated tenants](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_10.jpg)

			Figure 7.10 – Isolated tenants
			On the development side, Azure pipelines or GitHub workflows build the managed and unmanaged solutions and place them in Azure Blob Storage. They also queue new messages in the message queue that contain the metadata information about the deployment, such as which solution from which blob container with which version the production side pipelines should deploy to. They also contain the SAS tokens to access Blob Storage from the production tenant. On the production side, Power Automate cloud flows pick up the queue message triggered by the Service Bus condition and execute the deployment based on the queue message to the targeted environments. With that, there is no direct, synchronous connection between development and production tenants. We apply the **asynchronous design pattern** here (pulling model) to terminate the original synchronous deployment call to our production environment.
			Summary
			In this chapter, we explored the DevSecOps process, delving into its evolution, the concept of a shift-left mindset, and the integration of security tasks within our SDLC. We then acquainted ourselves with the security architecture and guiding principles underpinning Power Platform. Our journey continued with an examination of GHAS, leveraging CodeQL to conduct SAST. We also investigated the solution checker, utilizing Azure DevOps build tasks and GitHub Actions to perform the platform’s built-in analysis. Our deep dive extended into the realms of the Azure CLI, Azure DevOps scripts, pipelines, and pipeline templates, enabling us to construct an Azure DevOps project embedded with security from the ground up in a fully automated manner. Lastly, we dedicated time to understanding the security threats that could potentially compromise our DevOps pipelines or workflows and discussed strategies to mitigate these risks.
			In the next chapter, we will craft a tangible solution, applying every aspect of DevOps and ALM through practical, hands-on walkthroughs.
			Further reading

				*   DevSecOps controls: [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls)
				*   **Security Development Life Cycle**(**SDL**) Practices: [https://www.microsoft.com/en-us/securityengineering/sdl/practices](https://www.microsoft.com/en-us/securityengineering/sdl/practices)
				*   Threat Modeling: [https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling)
				*   Microsoft threat modeling tool: [https://aka.ms/threatmodelingtool](https://aka.ms/threatmodelingtool)
				*   GitHub Dependabot: [https://docs.github.com/en/code-security/dependabot](https://docs.github.com/en/code-security/dependabot)
				*   CodeQL: [https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql)
				*   Security in Power Platform: [https://learn.microsoft.com/en-us/power-platform/admin/security/overview](https://learn.microsoft.com/en-us/power-platform/admin/security/overview)
				*   GitHub Advanced Security for Azure DevOps: [https://azure.microsoft.com/en-us/products/devops/github-advanced-security](https://azure.microsoft.com/en-us/products/devops/github-advanced-security)
				*   CodeQL CLI binaries: [https://github.com/github/codeql-cli-binaries](https://github.com/github/codeql-cli-binaries)
				*   CodeQL query packs: [https://github.com/github/codeql](https://github.com/github/codeql)
				*   CodeQL analysis: [https://docs.github.com/en/code-security/codeql-cli/getting-started-with-the-codeql-cli/preparing-your-code-for-codeql-analysis](https://docs.github.com/en/code-security/codeql-cli/getting-started-with-the-codeql-cli/preparing-your-code-for-codeql-analysis)
				*   Solution checker: [https://learn.microsoft.com/en-us/power-apps/maker/data-platform/use-powerapps-checker](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/use-powerapps-checker)
				*   PAC CLI for solution checker: [https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/solution#pac-solution-check](https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/solution#pac-solution-check)
				*   Microsoft.PowerApps.Checker.PowerShell module: [https://learn.microsoft.com/en-us/powershell/module/microsoft.powerapps.checker.powershell/invoke-powerappschecker?view=pa-ps-latest](https://learn.microsoft.com/en-us/powershell/module/microsoft.powerapps.checker.powershell/invoke-powerappschecker?view=pa-ps-latest)
				*   System access token: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml)
				*   Work item branch policy: [https://learn.microsoft.com/en-us/rest/api/azure/devops/policy/configurations/create?view=azure-devops-rest-7.1&tabs=HTTP#work-item-policy](https://learn.microsoft.com/en-us/rest/api/azure/devops/policy/configurations/create?view=azure-devops-rest-7.1&tabs=HTTP#work-item-policy)
				*   GitHub enterprise accounts: https://docs.github.com/en/enterprise-cloud@latest/admin/managing-your-enterprise-account/about-enterprise-accounts

第八章：展示 ALM 和 DevOps 实现

在本章中，我们将通过一个动手练习，使用真实的例子，结合代码片段和逐步说明。 我们将使用 Power Platform 企业模板 Power Platform 企业模板 来演示 DevOps 流程的端到端场景。 该模板是 员工奖励模板，我们可以用它来表扬 他人出色的成就。 可用的解决方案 提供了一个基于模型的应用程序（Kudos 管理应用），用于管理奖励、选择退出用户并创建徽章，这些徽章可以在画布应用中使用，填写奖励内容。 这个画布应用，称为 Kudos 应用 在解决方案中，提供了一个用户界面 供组织中的用户使用。 由于 Kudos 解决方案依赖于 员工体验基础解决方案 ，我们将学习如何通过引入多个 GitHub 工作流 在发布火车中同时管理两个解决方案，并利用部署包。 我们将为此应用定义分支策略，并深入了解不同的 GitHub 工作流，以及 DevSecOps 任务来管理这些解决方案的开发。 我们将介绍待办事项管理，并使用分支策略来保护我们的主分支，避免意外更改。 我们将为 Kudos 应用创建测试，并引入 监控 到我们的应用和流程中。 最后，我们将学习 功能开关 以及如何使用它们启用或禁用 我们应用中的某些功能。

在本章中，我们将涵盖以下 主要主题：

• 练习 – 存储库管理和分支策略 对于应用程序

• 练习 – 构建 CD 流水线和一个 发布火车

• 练习 – 待办事项管理 在 GitHub 中

• 练习 – 测试解决方案

• 练习 – 监控应用程序

• 练习 – 引入 功能开关

技术要求

要深入了解 DevSecOps 方法和工具，我们需要具备以下内容：

• Microsoft Azure 订阅：我们可以通过 https://azure.microsoft.com/en-us/free注册 Microsoft Azure 订阅。如果我们拥有 Visual Studio 订阅或是 Microsoft 认证培训师，可以通过 MSDN 订阅加入，每月获得 150 美元的信用额度。

• Power Platform 订阅：如果我们已经拥有 Microsoft Entra ID 工作账户，可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free），或者可以加入 Microsoft 365 开发者计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。

• GitHub 账户和公共 仓库：（https://github.com/signup）

• GitHub 高级安全功能 对于公共 仓库免费提供： https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security#about-advanced-security-features。

• 示例和操作指南 将在本章中讨论，并位于 以下位置： https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter08。

• Azure CLI：我们可以通过安装指南直接在机器上安装 Azure CLI（https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install），或者可以通过 Azure 门户使用 Azure Cloud Shell 获取交互式 Bash 或 PowerShell 会话。

• GitHub Codespaces：GitHub 每月为个人提供 60 小时的计算资源，免费使用。 要创建并启动 GitHub Codespaces，只需拥有一个 GitHub 账户。

• .devcontainer/devcontainer.json。

练习 – 应用程序的仓库管理和分支策略

在我们深入实际操作之前， 值得先了解一下 Power Platform 企业模板中的 Kudos 应用。 我们可以通过访问企业模板的官方文档 了解更多关于该解决方案的信息： https://learn.microsoft.com/en-us/power-platform/enterprise-templates/hr/employee-kudos/install-and-set-up。我们为本书提供的仓库中包含了此解决方案的源代码，包含了我们将在整个练习过程中使用的额外扩展和工作流。

在本练习中，我们 将创建一个公共的 GitHub 仓库 ，该仓库将托管本章的应用程序，并且我们将 设置我们的分支策略并创建 部署 Kudos 应用到 Power Platform 生产环境的前置条件。 我们将采取以下步骤：

步骤	描述
1.	克隆示例仓库到我们自己的 GitHub 公共仓库中。
2.	创建我们的 Power Platform 生产环境，该环境将托管 Kudos 应用以及我们将在 GitHub 工作流中使用的服务主体。 该服务主体的凭证存储在 GitHub secrets 中。
3.	创建一个 Microsoft Entra ID 组（Azure AD 组），该组将包含可以使用 该应用程序的用户。
4.	在生产环境中创建 Kudos 应用的连接。
5.	创建部署设置文件，以管理 CI/CD 工作流中的连接引用，并执行Release to Production 流程，将 Kudos 应用部署到 生产环境中。
6.	基于 GitHub flow 定义我们的分支策略。
7.	创建我们的第一个分支保护规则，以强制对主分支的拉取请求 进行保护。

表 8.1 – 练习步骤

为了简化接下来的 脚本执行 和 后续步骤 及章节的操作，我们将使用 GitHub Codespaces。GitHub Codespaces 提供的计算资源 和开发容器托管在 GitHub 云端。 我们已经准备了一个包含各种工具的容器，例如 GitHub CLI、 Git CLI、 PAC CLI以及 Azure CLI，这些工具已预装在其中。 其配置文件位于以下位置： 直接位于 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/blob/main/.devcontainer/devcontainer.json。

要启动容器，我们需要在网页浏览器中导航至本书的 GitHub 仓库（https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform），然后点击 代码 按钮，再点击 在主分支上创建代码空间 按钮，如下图所示：

图 8.1 – 在 GitHub 中创建代码空间

点击按钮后， 系统会解析 devcontainer.json 文件， 该文件位于 .devcontainer 文件夹中，然后 基于该配置， 在后台创建一个新的 Docker 镜像 。 该镜像将作为容器运行，并且在新的浏览器窗口中，Visual Studio Code 将很快启动，预装了在 JSON 文件中描述的功能：

图 8.2 – 浏览器中的代码空间

在 终端 窗口（通常是 Bash，但也可以使用 PowerShell ）中，我们 将开始创建我们自己的 代码库，按步骤进行：

1. copilot suggest 或 copilot explain 参数，用于在不切换上下文的情况下与 GitHub Copilot 进行交互。 Gh copilot suggest 将我们的自然语言提示转换为正确的 GitHub CLI 命令，并附带适当的参数，而 gh copilot explain 则用自然语言描述我们感兴趣的命令。 我们可以使用以下脚本，在我们自己的 GitHub 企业组织中创建一个名为 Kudos 的仓库（如果可用），或者在登录后使用我们自己的 GitHub 账户（GitHub Codespaces 默认提供有限访问 GitHub 管理端点的权限）：

    export GITHUB_TOKEN=
   gh auth login
   gh auth switch
   # move out of the book repoto "/workspaces"
   cd .. gh repo create Kudos --public --clone
   git clone https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform.git
   

   克隆后，我们可以将 Chapter08 文件夹中的文件和文件夹复制到我们的 Kudos 文件夹中（即 git 仓库）：

   cp -rT ./Mastering-DevOps-on-Microsoft-Power-Platform/Chapter08/ ./Kudos
   

   然后，我们可以使用以下脚本将文件添加、提交并推送到 新仓库：

   # use the credentials of gh CLI in Git commands
   gh auth setup-git
   git config --global user.email "ouremail@address.com"
   git config --global user.name "Our Name"
   git add . git commit -m "Baseline Kudos app"
   git branch -M main
   git push -u origin main
   

   这样，我们 就拥有了新 仓库中的一切，将在 我们的 动手操作练习中使用：

图 8.3 – 我们自己的仓库与 Kudos 应用程序

在我们的新仓库中， 也有一个 .devcontainer 文件夹，里面包含 GitHub Codespace 定义。 在这里，让我们在主分支上创建自己的 codespace，并再次通过 GitHub 进行身份验证，以便获得对 仓库的写权限：

 export GITHUB_TOKEN=
gh auth login
gh auth switch

此外，如果 我们已经正确完成了每个准备步骤，并且现在打开 Actions 标签 ，我们应该看到可用的 GitHub 工作流，如下图所示：

图 8.4 – Kudos 应用程序的 GitHub 工作流

我们将很快使用这些工作流，将我们的 Kudos 应用程序部署到 Power Platform 生产环境中。

1. pac admin create 命令，而创建服务主体时，我们应用 pac admin create-service-principal 命令。 所以，让我们使用交互式登录在 GitHub Codespaces 或本地创建我们的 Kudos 应用程序的生产环境：

    pac auth create pac admin create --name Kudos-Prod --region Europe \
    --currency EUR \
   gh repo create command in our GitHub codespace, the default repository is our Kudos repository. Otherwise, we can use gh repo set-default owner/repo command to set it as default.
   

2. 创建 AAD 组：如果我们使用服务主体将解决方案部署到目标环境，那么解决方案中的应用将归服务主体所有。 为了让其他人访问这些应用，我们需要 创建一个 Microsoft Entra ID 安全组 （我们在 第七章中学习了如何操作）。 我们需要被分配 组管理员 Microsoft Entra 内置角色，才能管理组的创建和成员分配。 让我们执行以下 脚本来创建 Microsoft Entra ID 组：

   az login
   az ad group create --display-name $GROUP_NAME --mail-nickname $GROUP_NAME # get the user object id AADObjectID=$(az ad user show \
    --id $userPrincipalName \
    --query id \
    --output tsv) # add a member to the group \.github\workflows\share-app.ps1, we can share the Kudos app with the created security group. At the time of writing, there is no PAC CLI command that can be used to share an app with Entra ID groups; that’s why we had to use Set-AdminPowerAppRoleAssignment -PrincipalType "Group" -PrincipalObjectId $GroupID -RoleName CanView -AppName $AppName -EnvironmentName $EnvironmentName cmdlet here. The security group’s object ID needs to be provided as an input parameter to the script. The GitHub workflows available in the repository also expect this AAD group ID as input.
   

3. 准备 Power Platform 生产环境：Kudos 应用程序包含四个 Power Automate 云流和 Power Apps 画布应用，这些应用使用连接引用及其对应的连接，已为 Dataverse、 Office 365 Outlook 和 Office 365 Users 连接器创建。 这些 连接引用 用于在其他环境中使连接 可调整。 这些 连接器 是连接的定义；就像 面向对象编程 （OOP）中的类一样，它们是基于 OpenAPI REST API 规范， 并在环境中实例化为 连接 （即面向对象编程中的对象）。 当我们使用解决方案创建流、应用及其他 Power Platform 资产时，每次在流或应用中启动新的连接时，都会在解决方案中自动创建一个 连接引用 。 如果我们在解决方案外工作并在 我的流下创建流，则会创建直接连接，而不是连接引用。 然而，PAC CLI 可以代表服务主体在我们的生产环境中创建 Dataverse 连接，使用以下脚本：

    pac connection create [--environment] --tenant-id --name --application-id --client-secret
   

   Office 365 Outlook 和 Office 365 用户 连接器需要服务账户 和真实用户账户，而不是服务主体，用于在 Outlook 和 Office 365 API 中进行身份验证。 我们不能将 O365 或 M365 许可证分配给服务主体。 这就是为什么我们需要在部署解决方案之前，在目标环境中创建这些 连接。 我们可以在 PowerApps 制作门户 中的 连接 面板，通过点击 + 新建连接 按钮，如下图所示：

图 8.5 – Kudos 应用的连接

创建三个 连接后，我们应该看到与图中显示相同的结果。 最后，我们需要将这些连接与服务主体和之前在 步骤 2中创建的应用用户共享，通过点击三个点并选择 共享 菜单项 在 连接：

图 8.6 – 与服务主体共享连接

让我们通过 引入部署 设置文件 来在部署中使用这些连接。

1. 部署设置文件：为了在解决方案部署期间使用这些连接，我们需要使用一个所谓的 部署设置文件。该文件已经为解决方案生成，脚本如下：

    pac solution create-settings --solution-zip .\mpa_Kudos_1_0_0_36.zip
   

   此命令提取 \src\mpa_Kudos\deploymentSettings.json 文件，该文件位于 GitHub 仓库中：

   {
     "EnvironmentVariables": [], "ConnectionReferences": [ {
         "LogicalName": "mpa_KudosDataverse",
         "ConnectionId": "[Dataverse]",
         "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
       }, {
    "LogicalName": "mpa_KudosO365",
    "ConnectionId": "[O365]",
    "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365users"
    }, {
         "LogicalName": "mpa_KudosOutlook",
         "ConnectionId": "[Outlook]",
         "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365"
       }]}
   

   缺失的 ConnectionId 值会在 GitHub 工作流运行时 设置。 这些值 是我们工作流的输入参数。 要从我们的 Power Platform 环境中获取这些值，我们 需要点击 Power Apps maker portal 中的连接 Power Apps 创建者门户 并复制连接的 ID 从相应的 URL 中。 下图展示了 Dataverse 连接的连接 ID，突出显示在 URL 中：

图 8.7 – URL 中的连接 ID

第一个 GUID 在 URL 中是环境 ID，而 第二个 GUID 是连接 ID。 以下示例突出了 第二个 GUID：

 https://make.powerapps.com/environments/<<Environment GUID>>/connections/shared_commondataserviceforapps/\.github\workflows\cd-to-prod.yml contains the default values of these connection IDs, which we can overwrite and commit back to the main branch. With everything in place, we can deploy the Kudos app from the main branch to our production Power Platform environment, by starting this workflow with the gathered connection IDs:
			![Figure 8.8 – The Release to Production workflow with parameters](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_8.jpg)

			Figure 8.8 – The Release to Production workflow with parameters
			To store these connection IDs, we can alternatively use **GitHub environments**. In the case of our developer branch, we will use a dedicated GitHub environment to pre-configure these values later in this chapter.

				1.  **Create our branch strategy**: At the beginning of our development project, we need to design which branching and merging strategy we will use. In *Chapter 5*, we learned about the **GitHub flow**, and this is what we are going to create for the Kudos application. The following figure shows our strategy and the direct mapping between Power Platform environments and Git branches:

			![Figure 8.9 – The branch strategy](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_9.jpg)

			Figure 8.9 – The branch strategy
			The arrows between the Power Platform environments and Git branches represent the code and deployment flows. A production environment can handle only `dev/DEV-US_XXX_Z` branch represents a short-lived feature branch containing the implementation of a user story or a bug fix.

				1.  `main` in the **Branch name pattern** field, and we need to select the **Require a pull request before merging** checkbox, as shown in the following figure:

			![Figure 8.10 – The branch protection rule for main](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_10.jpg)

			Figure 8.10 – The branch protection rule for main
			At the bottom of the page, we need to click on the **Create** button. With this setting, we ensure that only pull requests are allowed to our main branch. Note that, by default, **Require approvals** is checked, which means at least someone else should review our pull requests. Since we cannot assign a pull request to ourselves, if we work alone, it is recommended to uncheck **Require approvals**. However, it is obviously not best practice to do so in a real-world project. Besides this setting, we need to define the type of merge that we want to allow developers to do. It is recommended to use **squash merging**, which combines all commits from the head branch into a single commit in the target branch. This significantly reduces the commit history, since all changes we commit in our developer branch sequentially will be combined into one commit after a successful pull request to the parent branch. We can force this type of merge by going to the **Settings** menu in GitHub and, under the **General** blade, removing every other merge type:
			![Figure 8.11 – Enforcing squash merging](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_11.jpg)

			Figure 8.11 – Enforcing squash merging
			Checking only **Allow squash merging** will force the pull requests to be squash commits. The other two options, **Allow merge commits** and **Allow rebase merging**, will copy the commit history of the child branches into the main branch, leading to large history nodes in the commit history.
			If we encounter any issue in the previous steps, we can use the following settings to get verbose logging of the commands.

				*   `GH_DEBUG` environment variable. If its value is `1`, it provides more insights, but if we set this variable to `api`, then we will see every REST API call to the GitHub endpoints:

    ```

    export GH_DEBUG=gh 命令执行将会在标准输出中打印详细的跟踪信息。

    ```

    				*   `--debug` flag to the end of every command that we want to troubleshoot:

    ```

    az login --debug

    ```

    				*   **The PAC CLI**: At the time of writing, the PAC CLI doesn’t offer any flag or environment variable to enrich the verbose logs in the standard output. If we need to troubleshoot PAC CLI commands, we can only use the log available under the following:

    ```

    %userprofile%\.dotnet\tools\.store\microsoft.powerapps.cli.tool\1.30.7\microsoft.powerapps.cli.tool\1.30.7\tools\net6.0\any\logs\pac-log.txt

    ```

			Now, we are fully prepared to make some changes to the Kudos application. Let’s understand the existing GitHub workflows and their roles in the DevOps processes.
			Exercise – building CD pipelines and a release train
			In the GitHub repository, we will find the following prebuilt GitHub workflows to manage the life cycle of our development project, end to end:

				1.  `.github/workflows/setup-dev-environment.yml`, this workflow creates a developer branch with the name provided before the workflow execution (the branch name follows the naming rule, `dev/branch_name`). The pipeline spins up a Power Platform developer environment with the same name used for the branch. We need to add the work account that we use in the Power Platform tenant to create the developer environment on behalf of our account. At the end of the workflow, we can see additional steps that grant **System Administrator rights** to our work account and to the service principal that we created for the production environment earlier. Let’s execute this workflow with the following parameters:

			![Figure 8.12 – Workflow inputs of “Setup dev environment”](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_12.jpg)

			Figure 8.12 – Workflow inputs of “Setup dev environment”
			After a successful run, we will see a new Power Platform developer environment with the name `DEV-US_XXX_Z` and a branch with the name `dev/DEV-US_XXX_Z`.

				1.  `dev` prefix. In our case, it is `dev/DEV-US_XXX_Z`. We can create the GitHub environment by opening the `DATAVERSE_CONNECTION_ID`2.  `O365_CONNECTION_ID`3.  `OUTLOOK_CONNECTION_ID`

We can see how we’ve introduced the variables in the following screenshot:

			![Figure 8.13 – The GitHub environment with connection IDs](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_13.jpg)

			Figure 8.13 – The GitHub environment with connection IDs
			As a next step, we need to create these three `KudosSPN`), and copy the connection IDs from the appropriate URLs into the `deploymentSettings.json` file. Our workflow expects to find this information in the assigned GitHub environment with the matching name. Let’s execute the *Import to dev* workflow located under `github/workflows/import-to-dev.yml` from the dev branch, to import the **unmanaged solutions** to the developer environment:
			![Figure 8.14 – The Import to dev workflow](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_14.jpg)

			Figure 8.14 – The Import to dev workflow
			We need to select our recently created developer branch to use its name to find the right environment in the Power Platform tenant:
			![Figure 8.15 – Executing the workflow on the dev branch](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_15.jpg)

			Figure 8.15 – Executing the workflow on the dev branch
			When everything is set up right according to the previous steps, we will see the GitHub workflow running during the execution of the job. The `import-to-dev` job will run in the `dev/DEV-US_XXX_Z` environment, displaying the GitHub environment name in the job’s rectangular box of the workflow run (`Import to dev`), as shown in the following figure:
			![Figure 8.16 – The GitHub workflow import-to-dev job](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_16.jpg)

			Figure 8.16 – The GitHub workflow import-to-dev job
			After the successful run, we have only one task left, which is to turn on the **Power Automate cloud flow**, *Kudos App – Notification email*, by opening the Kudos solution and viewing the flow under the **Cloud flows** solution asset. We will not see the flows under **My flows** because these flows are intentionally not shared with us.
			When we examine the YML file of the workflow in detail, we can see that this pipeline uses a `deploymentSettings.json` file with the right connection IDs. Finally, we execute the `microsoft/powerplatform-actions/import-solution@v1` action to import the unmanaged solutions with the right deployment configurations to our Power Platform environment. We also import data to the `Badge`, with the help of the `microsoft/powerplatform-actions/import-data@v1` GitHub action.
			*The branch name is the glue that ties the Power Platform environment, the Git branch, and the GitHub environment together to help developers easily find their* *own environments/configurations.*

				1.  `\.github\workflows\commit-to-dev.yml`, this workflow has been built to easily commit the changes made in the Power Platform developer environment back to the developer branch. We can make changes by going directly to the Kudos solution in the **maker portal** and opening the canvas app, (the Kudos app) for editing. On the main screen of the application, let’s change the textbox to include the current date, as shown in the following figure:

			![Figure 8.17 – Editing the Kudos App in the developer environment](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_17.jpg)

			Figure 8.17 – Editing the Kudos App in the developer environment
			We need to save the app and publish the customizations before executing the *Commit to dev branch* GitHub workflow. If we want to run the app locally in this environment, we also need to share the application within the solution with our account. The *Commit to dev branch* expects no input parameter; we only need to set the branch to our developer branch. If we started the workflow directly on the main branch, it would fail because of the branch protection rules that are applied. Under the hood, this workflow exports both solutions as managed and unmanaged (`microsoft/powerplatform-actions/export-solution@v1`) and also unpacks them to the right folders in the developer branch (`microsoft/powerplatform-actions/unpack-solution@v1`). Finally, the flow commits the changes to the dev branch. As we did earlier, we use the branch name to find the **Power Platform environment URL** to export the solutions from the right Dataverse instance, with the help of the following Bash script snippet:

ref=${{ github.ref }}

branch="${ref#refs/heads/dev/}"

echo "$branch"

工作流在 dev 分支上执行，所以我们需要从 dev 分支获取环境 URL rawOutput=$(pac admin list --name $branch | tail -n 2)

environmentURL=$(echo $rawOutput | cut -d ' ' -f 3) echo "Environment URL: $environmentURL"

设置 env.devEnvironmentURL

echo "devEnvironmentURL=\(environmentURL" >> "\)GITHUB_ENV"

			In the final line, we create an environment variable with the value of the URL to use in the upcoming actions within the GitHub job. We hand over this URL to other jobs in the workflow by using the `outputs` and `needs` keywords in the YML file.

				1.  `dev/DEV-US_XXX_Z` branch to `main`. The pull request will compare the two branches and list every change that has been made since the creation of the developer branch. We can use **GitHub Copilot** to generate a summary of these changes by clicking the Copilot icon on the pull request page:

			![Figure 8.18 – A Copilot-generated pull request summary](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_18.jpg)

			Figure 8.18 – A Copilot-generated pull request summary
			By clicking the **Merge** button, our pull request will close and the changes will merge back to the parent branch. Usually, we delete developer branches after a successful pull request, but this time, let’s keep our dev branch to execute some additional exercises in the upcoming sections.

				1.  `\.github\workflows\cd-to-prod.yml`, this workflow deploys the latest version of the main branch to the production environment, as we discussed in the previous section. We can execute this workflow to deploy the latest version of the Kudos app to the production environment.

			In *Chapter 6*, we learned about the `0.0.0.0.` in Azure DevOps Services during the development phase. We can apply the same concept in GitHub by introducing a reusable workflow located under `\.github\workflows\set-version-number.yml`. This workflow has two parameters; one is the source folder of our solutions, and the other is the version number to be set. The workflow checks out the repository, searches for the `Solution.xml` file under the source folder, and replaces the inline version tags with the version number, provided as an input parameter:

• shell: bash

run: |

在解决方案目录及其子目录中查找所有 Solution.xml 文件 find ${{ inputs.source_folder }} -type f -name "Solution.xml" | while read -r file; do

使用输入的版本号替换标签中的内容 sed -i 's|.*|\({{ inputs.version_number }}</Version>|g' "\)file"

done

			The final action in the flow commits back the changes to the branch on which the workflow runs.
			We need to add this reusable workflow to the *Commit to dev branch* workflow to set the version number of the solutions to `0.0.0.0`. Let’s update the workflow in the dev branch (`dev/DEV-US_XXX_Z`) with the following lines, directly adding them to the end of the workflow:

set-version-number:

needs: [ commit-to-dev-kudos ]

name: 将版本号设置为 0.0.0.0

uses: jovadker/ppdemo/.github/workflows/set-version-number.yml@main

with:

    source_folder: src/

    version_number: "0.0.0.0"

			Let’s commit the changes locally and push them back to the remote repository. We can work in `dev/DEV-US_XXX_Z`) and create another codespace:
			![Figure 8.19 – A GitHub codespace on the dev branch](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_19.jpg)

			Figure 8.19 – A GitHub codespace on the dev branch
			After launching the newly created codespace, we can add the workflow snippet (the GitHub job with the name `set-version-number`) to the end of the file, as shown in the following figure:
			![Figure 8.20 – The commit-to-dev.yml file in the GitHub codespace](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_20.jpg)

			Figure 8.20 – The commit-to-dev.yml file in the GitHub codespace
			After saving the file in the VS Code editor in the browser, we can navigate to the source control icon on the left menu and commit our changes, by providing a commit message and clicking on the **Commit** button:
			![Figure 8.21 – A Git commit in a GitHub codespace](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_21.jpg)

			Figure 8.21 – A Git commit in a GitHub codespace
			After clicking on the **Commit** button, we should not forget to click on **Sync Changes** to push back the changes to the remote origin.
			To test the GitHub workflow upon our changes, we can start it on the branch, `dev/DEV-US_XXX_Z`, and see how the two solutions and their `Solution.xml` files are updated. Similarly, we can introduce this job to other flows if we plan to maintain a homogenous versioning in our solutions.
			Version number – 0.0.0.0
			If we use the `0.0.0.0` version number, then the solutions imported to Power Platform developer environments will also have this version. This approach is ideal for multiple developers working on the same solution or project, since they will not override the versions by committing their changes back to developer branches and later, through pull requests, to the main branch.
			Finally, we can leverage the releases feature of GitHub to publish our new versions. **GitHub releases** offer an easy way to package our software, along with release notes and links to binary files, for other people to use. We can manage these releases in GitHub workflows; the platform provides a special trigger that we can use to add our solutions to a release, and there are actions available in the **GitHub marketplace** to create releases within workflows. We will create our release by executing a new GitHub workflow that builds our solutions, using **MSBuild**, creates a deployment package, and publishes the generated artifacts as part of the new release version.
			The Kudos application provides `MSBuild` and `dotnet` CLIs. We can create these `.cdsproj files` at any time by executing the following PAC CLI command in the `solution` folder:

pac solution init --publisher-name developer --publisher-prefix dev

			This command creates a wrapper around our solution, if empty, and then it will create an empty solution under the `src` folder, into which we can copy our solution files (XML and JSON files).
			In *Chapter 4*, we learned about deployment packages and the `.csproj` file under the `DeploymentPackage` folder:

pac package init --outputDirectory DeploymentPackage

cd .\DeploymentPackage pac package add-solution --path <>\mpa_EmployeeExperienceBase_managed.zip

pac package add-solution 命令将之前由 MSBuild 构建的托管解决方案作为引用添加到此 .csproj 文件中。设置部署包后，我们可以使用 dotnet publish -c Release 命令来构建部署包的发布版本。

        部署包

        我们在 GitHub 仓库中创建了一个文件夹结构，其中两个解决方案和 `DeploymentPackage` 文件夹位于 `src` 文件夹下。 在 `csproj` 文件中， `DeploymentPackage` 文件夹引用了两个解决方案的发布构建，分别是 Employee Experience Base 和 Kudos。

        最后，我们可以通过使用 *GitHub Release* 工作流来创建我们的 GitHub 发布，该工作流位于 `/.github/workflows/create-release.yml`。该工作流的高层步骤和关键要点如下：

            1.  `/.github/actions/set-version-number-action/action.yml`，它设置了 Power Platform 解决方案的版本号。 正如我们之前所看到的，可重用的工作流需要作为作业运行，这意味着 GitHub 运行器将在完成可重用工作流作业并继续下一个作业后清理本地仓库。 如果我们不希望提交版本号，我们需要将所有操作都运行在同一个作业中。 这就是为什么我们创建了这个 复合操作。

            1.  `MSBuild` 和 `dotnet` CLI 可用于我们的构建操作。 我们使用以下命令构建解决方案：

```
proj file contains the references to the cdsproj files under the solutions folders. We generate the deployment package with the dotnet publish -c Release /p:Version=${{inputs.release_version}} command by setting the version of the package to the one provided as the workflow parameter. After having the binaries generated, we upload every build artifact to the GitHub artifact store.
```

                1.  `gh cli` 命令用于创建一个 GitHub 发布：

```
 gh release create ${{inputs.release_version}} --title "${{inputs.release_title}}" --generate-notes ${{ env.solution_release_folder}}/*.*
```

通过使用 `generate-notes` 参数，GitHub 发布说明将自动生成。 我们还通过引用文件夹及其内容将二进制文件附加到创建的发布中， `${{` `env.solution_release_folder}}/*.*`。

        现在，让我们使用默认参数执行此流程，并在完成后检查是否能在 GitHub 仓库的主页上看到 **Releases**下的一个名为 **Initial release**的发布。打开它后，我们应该能发现关于第一次发布的更多细节——例如， 附加的资产：

        ![图 8.22 – 包含 Power Platform 包的 GitHub 发布](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_22.jpg)

        图 8.22 – 包含 Power Platform 包的 GitHub 发布

        包部署器

        该 `.pdpkg` （ `pac package deploy --package` `.\bin\Release\mpa_Kudos_DeploymentPackage.1.0.0.pdpkg.zip` 在另一个租户上进行部署。 这些包 还可以上传数据并为 解决方案准备目标环境。

        通过 GitHub 发布，我们可以 将我们的开发项目结果分发给负责生产租户的 IT 运维团队，而无需直接将我们的开发租户和工作流与 生产租户连接。

        如果在尝试运行 工作流时遇到问题，请考虑以下 故障排除选项：

            +   **检查运行日志**：第一步是检查工作流运行的日志。 GitHub 为每个工作流步骤提供详细日志，这可以帮助我们识别错误发生的地方。

            +   `ACTIONS_STEP_DEBUG` 密钥用于启用步骤调试日志，提供每个步骤的更详细输出。 步骤日志的详细输出可以帮助我们诊断问题。

            +   **在本地运行工作流**：我们可以使用诸如 **act** ([https://github.com/nektos/act](https://github.com/nektos/act))等工具在本地机器上运行工作流。 这可以帮助我们在受控的环境中调试工作流。

            +   `.yml` 工作流文件格式正确，且所有必需字段都已包含。 语法错误或缺失字段可能导致工作流失败。 我们需要非常小心地更改 YML 文件中的行缩进，因为仅一个额外的空格就可能导致语法错误。

            +   **检查外部更改**：有时，外部依赖项或环境的变化会导致工作流失败。 我们需要确保所有外部服务和依赖项 都是正常运行的。

        现在，让我们进入下一个话题，深入了解 待办事项管理。

        练习 – GitHub 中的待办事项管理

        在 *第一章*中，我们了解了为何跟踪我们的活动、用户故事、变更请求和 bug 修复在任何代码库中都是至关重要的。 让我们回顾一下 关键要点：

            +   我们希望在每个冲刺前规划好开发人员的工作 以便集中精力 处理最关键的 功能 **特性**, **缺陷**和 **问题**。整个 **冲刺规划过程** 基于一个健康的 **产品待办事项** ，每个开发人员 和产品负责人 都需要 维护它。

            +   健康的待办事项管理只允许计划中的源代码更改 ，以避免 **黄金镶嵌** (开发人员添加不属于活动范围的额外功能) 和 **范围蔓延** (当项目团队在不调整项目成本或时间表的情况下，处理客户请求的功能) 。

            +   **待办事项管理** 提供 **向后追溯性** 以及追溯 从生产环境中运行的应用程序到生成该应用程序的源代码 的能力。 **二进制文件** 的生成。 我们可以利用这些信息进行根本原因分析，发现哪个工作项跟踪的更改导致了生产环境中的问题。

        Azure DevOps 服务 和 GitHub 提供了这些需求工程 和问题管理功能，具备先进的项目管理特性，例如安排我们的活动并分配给团队成员 在冲刺中。

        为了保持 GitHub 中健康的待办事项管理，我们可以 改进最小 `pull_request` 操作，目标是 main 分支并执行以下操作：

        ![图 8.23 – 触发拉取请求的工作流，用于分支保护](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_23.jpg)

        图 8.23 – 触发拉取请求的工作流，用于分支保护

        我们的工作流关键部分如下所示（位于 `/.github/workflows/pr-check.yml` ）：

name: Pull request check
on:
 pull_request:
 types: [edited, synchronize, opened, reopened]
 branches: [ "main" ] jobs:
  prcheck:
    runs-on: ubuntu-latest
    steps:
      - name: Check for comments in PR id: check-comments run: |
          # every pull request is an issue as well
          #- we can address them through /issues/ endpoint
          comments=$(curl -s -H "Authorization: token ${{secrets.GITHUB_TOKEN}}" \
             "https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments") if [ $(echo "$comments" | jq '. | length') -eq 0 ]; then
            echo "There is no comment added to the PR." echo "no_comments=true" >> $GITHUB_OUTPUT else
            echo "Comments are added to the PR." echo "no_comments=false" >> $GITHUB_OUTPUT fi
        shell: bash
      - name: Fail if no comments
        run: |
          if [[ "${{ steps.check-comments.outputs.no_comments }}" == "true" ]]; then
           echo "No comments added to the pull request. Failing the build." exit 1
          fi
        shell: bash

        我们使用 `curl` 通过 REST API 端点查询属于该问题的评论 （https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments ），因为每个拉取请求也被建模为一个 `no_comments`，因此。 下一步操作会使用前一步操作的输出，判断构建是否通过。 如果工作流失败，拉取请求将被阻止，无法合并。 工作流还会在开始时检查拉取请求是否添加了描述，采用相同的方法。 我们可以通过回溯写描述并添加评论来修正我们的拉取请求。 此外，我们还可以使用 GitHub Copilot 根据子分支和 父分支之间的更改生成拉取请求描述：

        ![图 8.24 – 使用 GitHub Copilot 生成 PR 描述](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_24.jpg)

        图 8.24 – 使用 GitHub Copilot 生成 PR 描述

        我们只需要点击 Copilot 图标，然后底层的 **GPT-4 模型** 会生成拉取请求的摘要 ——在我们的案例中， **该拉取请求对** **Readme.md 文件进行了微小的更改……**。

        如果我们想要在拉取请求中引入更复杂的检查，以配合待办事项管理，我们可以访问这个 `verify-linked-issue` （[https://github.com/marketplace/actions/verify-linked-issue](https://github.com/marketplace/actions/verify-linked-issue)），它会检查拉取请求是否至少关联了一个 问题。

        现在我们已经建立了严格的仓库和工作管理控制，接下来我们进入下一个话题， **质量保证**。

        练习 – 测试解决方案

        在 *第六章*中，我们深入探讨了 **质量保证** (**QA**) 主题，并了解了 可用于端到端 UI 测试的工具和框架 ，例如 **Power Apps 测试引擎**，或开源的 Web 测试框架，如 **Selenium**、 **Playwright**、 **Appium** 或 **Cypress**。我们还得出结论，Power Automate 云流和 **桌面流** 被视为我们的业务逻辑层，我们可以通过 UI 组件进行端到端测试。 在本节中，我们将进行以下操作：

            +   在我们的 Power Platform 开发环境中，为 Kudos 应用创建一个 Power Apps 测试工作室的测试 （`DEV-US_XXX_Z`）。

            +   将其作为测试套件下载 **YAML 文件** 并提交到我们的开发 分支（记得这个分支 仍然存在）。

            +   在本地运行，借助 PAC CLI。

            +   将这一步引入到我们的 *提交到开发分支* GitHub 工作流中。

        我们还有一些先决条件 用于这个测试 自动化场景：

            +   为了能够在 CI/CD 过程中执行我们的测试，我们还 需要一个没有 **多因素认证** (**MFA**) 的用户在我们的开发租户中；可以通过 *进一步阅读* 部分中的链接了解更多信息（Power Apps 测试引擎）。

            +   我们还需要在 **解决方案** 页面下共享 Kudos 应用 **Microsoft Entra** **ID 用户**。

            +   我们必须将此用户添加到开发环境（`DEV-US_XXX_Z`）中，**Power Platform 管理中心**，并且我们需要为该用户分配内置的**安全角色**，**基本用户**和自定义角色**Kudos 员工**，这样才能访问由 Kudos 解决方案创建的自定义表格，其中包含徽章以及已经共享的 Kudos。

            +   我们需要代表测试用户第一次交互式启动该应用，且不启用 MFA，授予他们对 Kudos 应用、Office 365 用户和 Office 365 Outlook 中使用的连接的访问权限。

            +   最后，我们需要与该用户共享*Kudo 应用 – 与发送者共享 Kudo*，*分配给接收者*，以及*Kudos 应用 - 通知邮件*云流程，作为*仅限运行的用户*在 PowerAutomate 云流程 UI 中。

        我们可以通过使用`/test/SmokeTestSuite.yaml`文件来轻松记录我们的测试，继续进行这项练习。

        一旦我们有了 YAML 文件，我们需要进行一些更改，以便能够在`0x0`中运行，像是`102x768`像素（`screenWidth` `X screenHeight`）：

 testSettings:
  filePath:
  browserConfigurations:
  - browser: Chromium
    device: screenWidth: 1024screenHeight: 768 locale: en-US recordVideo: trueheadless: true enablePowerFxOverlay: false
  timeout: 30000

        除了这些更新之外，我们可以将`headless` 参数设置为`false`，以便在 Chromium 浏览器中进行本地测试，跟踪 UI 操作。要在本地执行此测试 YAML 文件，我们可以使用以下 Bash 脚本：

 export user1Email="USEREMAIL"
export user1Password="PASSWORD"
pac test run --test-plan-file ./test/SmokeTestSuite.yaml -env 4d3c1075-FFFF-GGGG-VVVV-40c6f5edd705 --tenant 4ae51f31-XXXX-YYYY-ZZZZ-5ece14d2c081

        我们需要将测试用户的电子邮件地址和密码设置为环境变量，并且还需要提供测试文件位置、环境 ID 和租户 ID。成功执行后，我们将在`TestOutput`文件夹中找到测试结果及视频录制，文件格式也将是`.webm`。

        要在 GitHub 中执行此测试，我们需要 创建两个额外的 `TESTUSER` 和 `TESTUSERPSW`，并且 – 与我们在本章开始时创建的其他三个（`PPAPPID`, `PPAPPSECRET`, 和 `PPTENANTID`）类似。

        我们提前创建了一个 GitHub 工作流，以便在开发分支上轻松执行我们的 `SmokeTestSuite.yaml` 文件。 此工作流位于 `/.github/workflows/run-test.yml` 并使用以下 Bash 脚本运行 测试：

 - name: Run test shell: bashrun: | set -e ref=${{ github.ref }} branch="${ref#refs/heads/dev/}"
       echo "$branch"
       # Get the environment Id rawOutput=$(pac admin list --name $branch | tail -n 2) environmentId=$(echo $rawOutput | cut -d ' ' -f 2) export user1Email="${{secrets.TESTUSER}}" export user1Password="${{secrets.TESTUSERPSW}}" DEV-US_XXX_Z). Based on the branch name, the workflow finds our developer environment and then calls pac test run with the appropriate parameters.
			To avoid feature regression and maintain the high quality of our solution, we can introduce this step in our *Commit to dev branch* GitHub workflow to fail fast and early in the development process. All we need to do is to append the entire job, called `test`, from the `/.github/workflows/run-test.yml` as the first job in the workflow, as we want to only allow new commits landing in the branch when our automated tests pass:
			![Figure 8.25 – The Commit to dev branch with a placeholder for “test” job](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_25.jpg)

			Figure 8.25 – The Commit to dev branch with a placeholder for “test” job
			Additionally, we can introduce this quality check in our pull request triggered workflow (*Pull request check*), in the production workflow (*Release to Production*), or even in the release workflow (*GitHub Release*) based on our preferences. Some of these workflows need to be extended, for instance, to be able to spin up new Power Platform environments, deploy the release candidate, and execute the tests. Only our imagination and project costs can limit our QA investments.
			Now, our application is ready to run in production. There is only one task left, which is to get real-time insights and telemetry data about our application’s runtime characteristics and behavior. Let’s discover what monitoring options we have in Power Platform.
			Exercise – monitoring the applications
			After publishing our application to the production environment, we want to understand how it performs, how users interact with the application, and how far the application is stable and can run without errors. As Microsoft Power Platform runs on **Microsoft Azure**, it can leverage the existing Azure **platform-as-a-service** (**PaaS**) services to provide real-time telemetry data collection and analysis for the Power Platform portfolio – Power Apps, Power Automate, Copilot Studio, Power Pages, and even Dataverse. Azure’s PaaS service is **Azure Application Insights**, which is tidily connected to **Azure Monitor** and **Azure Log Analytics workspaces**. Azure Application Insights is an **Application Performance Management** (**APM**) solution that can be used in live production monitoring scenarios. Application Insights provides application dashboards, application maps, live metrics, transaction search, availability view, failures view, performance view, monitoring alerts, workbooks, and so on. With Application Insights, we can also discover the usage patterns of our users, how people interact with the app, and how the churn rate or the conversion rate looks. It also visualizes the user journey on web applications. The Application Insights service offers machine learning-based analysis of telemetry data (called **Smart Detection**) to identify anomalies or performance degradation before outages or blackouts occur. If the built-in detection features are not enough, we can write our own queries to look for anomalies with the help of **Kusto Query Language** (**KQL**). We can introduce our custom alerting and notifications based on the query results of KQL scripts that can trigger **Azure Playbooks**, **Azure Logic Apps**, **Azure Functions**, **Azure EventHub**, and **custom Webhooks**. The custom webhooks can trigger Power Automate cloud flows to react to the anomalies and outriders in the Power Platform. Last but not least, Application Insights provides SDKs, available in JavaScript, Java, C#, Node.js, and Python, based on the **OpenTelemetry framework**.
			Since Power Apps are browser-based applications and the web player that hosts the apps in the browser is based on `react-native` in the native mobile apps through **wrap functionality**, it is a very straightforward approach to embrace Application Insights’ capabilities in our low-code/no-code platform. We can add Application Insights’ endpoint directly to the canvas app – in our case, to the Kudos app. We just need to edit the app in the developer environment through the Kudos solution and select the **App** node in the tree view on the left side:
			![Figure 8.26 – Application Insights in Power Apps Studio](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_26.jpg)

			Figure 8.26 – Application Insights in Power Apps Studio
			On the right side, among the properties of **App**, we will find the **Instrumentation key** field, and here, we should provide the instrumentation key of our Application Insights instance. Let’s create an Application Insights instance in our Azure subscription:

交互式登录

az login

选择正确的订阅

az account set --subscription baa70448-593c-4dc7-8a91-c92cf7eaf66e

az group create --location westeurope --resource-group KudosApp.AI.RG workspace=$(az monitor log-analytics workspace create \

--resource-group KudosApp.AI.RG \

--workspace-name KudosWorkspace \

--location westeurope --query id --output tsv)

az monitor app-insights component create \

--app KudosAppInsights \

--location westeurope \

--workspace $workspace \

instrumentationKey 密钥。我们现在可以将该密钥添加到 Kudos 应用并试用，查看数据如何被导入到应用程序 洞察 仪表板。

        Canvas 应用洞察

        要查看遥测 信息，我们需要在 Power Platform 管理中心启用 Canvas 应用洞察。 转到 **设置**，它列出了所有租户设置，然后选择 **Canvas 应用洞察** 项。 在右侧的 **Canvas 应用洞察** 面板中，我们可以开启此 功能。

        当然，我们不希望直接在画布应用中存储仪表密钥。 使仪表密钥与应用程序独立的最简单方法是引入一个新的环境变量，但在撰写本文时，仪表密钥属性尚不支持此方法。 我们可以做的是更新我们的部署管道，并将仪表密钥替换为正确的值，该值存储为 `json 文件` 在我们的解决方案文件夹中 – `/src/mpa_Kudos/src/CanvasApps/src/mpa_KudosApp/AppInsightsKey.json`。这个文件包含了我们可以在 GitHub 工作流中替换为正确的仪表密钥。

        尽管我们的解决方案中没有自定义聊天机器人， **Microsoft Copilot Studio** 同样支持这种与 Azure 应用程序洞察的集成 。 我们可以在 **设置** 中配置 Azure 应用程序洞察实例的连接字符串 ，位于 **Copilot 详细信息** 菜单下的 **高级** 标签页，如下图所示：

        ![图 8.27 – Microsoft Copilot Studio 中的应用程序洞察](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_27.jpg)

        图 8.27 – Microsoft Copilot Studio 中的应用程序洞察

        在这里，我们需要提供 完整的连接字符串，格式如下：

 InstrumentationKey=XXXXXXXX-YYYY-YYYY-YYYY-XXXXXXXXXXXX;IngestionEndpoint=https://westeurope-5.in.applicationinsights.azure.com/;LiveEndpoint=https://westeurope.livediagnostics.monitor.azure.com/;ApplicationId=TTTTTTTT-ZZZZ-ZZZZ-ZZZZ-SSSSSSSSSSSS

        我们可以在 **概览** 页找到此字符串，属于我们的 Azure 应用程序 洞察实例。

        对于 **Power Pages 网站**，我们需要注入跟踪用户在网站上操作的代码片段，并将遥测数据发送到 Azure 应用程序洞察终端。 我们只需获取文档中提供的客户端 JavaScript 代码片段 并将其作为内容片段添加到我们的 **Power Pages** **管理** 应用程序中：

        ![图 8.28 – Power Pages 中的应用程序洞察](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_28.jpg)

        图 8.28 – Power Pages 中的应用程序洞察

        代码片段本身 可以在此链接找到： [https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript-sdk?tabs=javascriptwebsdkloaderscript](https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript-sdk?tabs=javascriptwebsdkloaderscript)，只需要更新连接字符串为 我们自己的。

        除了画布应用、自定义 聊天机器人和 Power Pages 网站外，Azure Application Insights 作为通用的 APM 框架 可用于监控 **模型驱动应用**、Power Automate 云流，以及 **Dataverse 诊断和性能事件**。这可以通过使用 **将数据导出到 Application Insights** 功能实现，该功能可在 Power Platform 管理中心中使用，如果我们拥有付费/高级 Dataverse 许可证的话。 对于我们来说，这意味着我们可以创建导出包，将选定环境中的遥测数据推送到我们的 Application Insights 服务，而无需将端点或连接字符串注入到 Power Platform 资产中。 我们无需在解决方案中准备或创建任何内容；环境和此导出作业将负责遥测数据的摄取。 建议每个环境使用一个 Application Insights 实例，并且请注意，此功能仅在托管 环境中开启和支持。

        遥测数据的延迟摄取

        在 **服务级别协议** (**SLA**) 中规定的遥测数据流交付时间框架 从支持此功能的 Power Platform 产品到 Application Insights 的交付时间为 24 小时。

        如果我们想要收集 来自这些 Power Platform 资产的实时遥测数据，我们可以创建自己的扩展，例如 以下内容：

            +   在模型驱动应用中，我们可以创建一个 **Power Platform 组件框架** (**PCF**) 控件，该控件显示在 UI 中并通过客户端 JavaScript 连接到 Application Insights 端点。

            +   通过 Power Automate 云流，我们可以使用在 Dataverse 中记录的有关开始时间、持续时间、结束时间、状态（例如失败、取消或成功）和执行操作 的信息，并借助 **Dataverse 插件**将其发送到 Application Insights 端点。 监控这些流的另一个选项是使用 Power Automate 中新内置的 **自动化中心** 面板：

        ![图 8.29 – Power Automate 自动化中心](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_29.jpg)

        图 8.29 – Power Automate 自动化中心

        在这里，我们可以可视化记录在 Dataverse 中的数据，并且可以在右侧使用 Copilot 获得 故障排除的帮助。

            +   使用 Dataverse，我们可以开发一个 **自定义 Dataverse 插件** ，将这些信息发送到 Application Insights 端点，并借助 **C# SDK**。

        正如我们所见，Azure Application Insights 是一个企业级的应用程序性能管理 PaaS 解决方案，我们可以轻松地将其集成到我们的 Power Platform 产品组合中。

        现在，我们将深入探讨最后一个主题——功能标志的世界，以及它们能为我们的 Power Platform 解决方案带来什么。

        练习 - 引入功能标志

        在自定义开发项目中， **功能标志** 用于启用或禁用应用程序的功能。 敏捷团队非常受益于这一概念，因为具有重大影响和较长开发周期的功能，跨越多个冲刺，可以在完全开发之前对最终用户保持隐藏。 考虑一些功能，例如启用 Microsoft Azure 中的 Copilot 功能或在公共仓库中提供 GitHub Copilot。 这些功能在向公众发布之前，都是在功能标志下开发的。 我们也经常使用功能标志来为一组用户（例如参与 Beta 测试活动的用户）启用新功能。 上述的 Copilot 功能最初是作为专门客户的私人预览版提供的，之后进入了公共预览阶段，最终它们变得 全面可用。

        特定于解决方案的 **环境变量** 在 Power Platform 中可以提供此功能标志能力，前提是我们 在新功能前使用它。 要在 Power Platform 解决方案中将环境变量用作功能标志，我们可以按照 以下步骤操作：

            1.  在我们的解决方案中创建一个环境变量。 这可以通过选择 **新建** | **更多** | 解决方案中的 **环境变量** 来完成，我们正在 进行的工作。

            1.  设置环境变量的数据类型，可以是 `布尔值`、 `选项集`，或 `文本`，具体取决于我们为 功能标志所需的类型。

            1.  在我们的解决方案组件中使用环境变量，例如 Power Automate 流、Power Apps 画布应用或自定义连接器。 对于 Power Apps，我们可以使用 `LookUp()` PowerFX 函数来访问环境变量的值，对于 Power Automate，我们可以使用 Dataverse 的 `执行外部操作` ，并选择操作 名称 `RetrieveEnvironmentVariableSecretValue`。

            1.  将我们的解决方案部署到不同的环境，并根据我们的功能标志设置更改环境变量值。 这使我们能够根据 环境设置启用或禁用某些功能或功能。

        让我们为我们的 Kudos 应用解决方案引入一个功能标志 来控制登陆页面上需要显示哪个标签——是原始的标签，还是我们在 *练习——构建 CD 管道和发布列车* 一节中早些时候创建的标签：

        ![图 8.30 – 作为功能标志的环境变量](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_30.jpg)

        图 8.30 – 作为功能标志的环境变量

        我们定义这个 环境变量，数据类型为 `布尔` ，并将其默认值设置为 `featureFlagLabel`。

        要在画布应用中使用 PowerFX 读取环境变量的值，我们可以使用以下方法：

            +   确保我们已将 `环境变量值` 表添加到我们的画布应用的数据源中。

            +   使用 `LookUp()` 函数，结合我们环境变量的架构名称——例如， `LookUp('环境变量值', '环境变量定义'.'架构名称' = "``YourEnvironmentVariableSchemaName").Value`。

            +   这将检索我们指定的环境变量的当前值。 。

        让我们打开我们的 Kudos 应用来编辑 从我们的解决方案中，然后引入新的数据源， `环境变量值`。之后，我们需要将 `文本` 属性从 `lblTitle_LandingScreen` 的静态文本更改为 以下内容：

 If( IsBlank(LookUp('Environment Variable Values', 'Environment Variable Definition'.'Schema Name' = "mpa_featureFlagLabel").Value),
    "Employee Kudos",
    If( LookUp('Environment Variable Values', 'Environment Variable Definition'.'Schema Name' = "mpa_featureFlagLabel").Value = "no",
        "Employee Kudos",
        "Employee Kudos - April 2024"
    )
)

        正如我们在本章第一节中所学到的，部署设置文件不仅包含连接引用，还包含环境变量。 我们的 `deploymentSettings.json` 文件位于 `\src\mpa_Kudos\deploymentSettings.json`。在 `cat` 命令的帮助下，我们已经在 GitHub 工作流中更新了此文件（*发布到生产环境* 和 *导入到开发环境*），关于连接引用：

 newDataverseId="${{ github.event.inputs.dataverseConnectionId }}"
newO365Id="${{ github.event.inputs.o365IdConnectionId }}"
newOutlookId="${{ github.event.inputs.outlookIdConnectionId }}"
cat ${{ env.solution_source_folder}}/${{ env.kudos_solution_name }}/deploymentSettings.json | jq --arg dataverseId "$newDataverseId" --arg o365Id "$newO365Id" --arg outlookId "$newOutlookId" '.ConnectionReferences[] |=
         if .ConnectionId == "[Dataverse]" then .ConnectionId = $dataverseId
         elif .ConnectionId == "[O365]" then .ConnectionId = $o365Id
         elif .ConnectionId == "[Outlook]" then .ConnectionId = $outlookId
        else . end' > temp.json && mv temp.json ${{ env.solution_source_folder}}/${{ env.kudos_solution_name }}/deploymentSettings.json

        类似地，我们可以更新此 JSON 文件中的环境变量值，以便在部署管道中完全自动化它们。 我们只需 将 `.ConnectionReferences[]` 数组替换为 `.EnvironmentVariables[]` 数组来调整 我们的变量。

        在本节中，我们学习了如何利用环境变量将功能标志添加到我们的应用程序和 云流中。

        总结

        在本章中，我们踏上了一段激动人心的旅程，深入探讨了 DevOps 和 ALM 原则的实际应用。 我们通过各种实践练习，掌握了从存储库分支策略到构建稳健的 CD 管道、有效管理待办事项以及强制执行分支保护规则等内容。 我们还深入探讨了解决方案的自动化测试，通过 APM 监控应用程序在运行时的性能，并利用功能标志的强大功能。 这些练习不仅仅是理论上的；我们还将其应用于一个真实世界的例子，利用 GitHub 作为我们首选的 DevOps 工具。 通过这些实践教程，我们将 DevOps 和 ALM 的每一个环节编织成了一个 [实践 经验的画卷。](https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview)

        [在接下来的章节中，我们将深入探讨](https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview) 融合架构，并查看如何在我们的 Power Platform 解决方案中利用 Azure PaaS 服务。

        进一步阅读

            +   Power Platform 企业版 模板： [https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview](https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview)

            +   Kudos 应用程序： [https://learn.microsoft.com/zh-cn/power-platform/enterprise-templates/hr/employee-kudos/install-and-set-up](https://learn.microsoft.com/zh-cn/power-platform/enterprise-templates/hr/employee-kudos/install-and-set-up)

            +   GitHub CLI： [https://github.com/cli/cli](https://github.com/cli/cli)

            +   GitHub CLI 与 GitHub Copilot： [https://docs.github.com/zh-cn/copilot/github-copilot-in-the-cli/using-github-copilot-in-the-cli](https://docs.github.com/zh-cn/copilot/github-copilot-in-the-cli/using-github-copilot-in-the-cli)

            +   预填充连接 引用： [https://learn.microsoft.com/zh-cn/power-platform/alm/conn-ref-env-variables-build-tools#get-the-connection-reference-information](https://learn.microsoft.com/zh-cn/power-platform/alm/conn-ref-env-variables-build-tools#get-the-connection-reference-information)

            +   GitHub 环境： [https://docs.github.com/zh-cn/actions/learn-github-actions/variables#using-the-vars-context-to-access-configuration-variable-values](https://docs.github.com/zh-cn/actions/learn-github-actions/variables#using-the-vars-context-to-access-configuration-variable-values)

            +   GitHub 输出： [https://docs.github.com/zh-cn/actions/using-jobs/defining-outputs-for-jobs](https://docs.github.com/zh-cn/actions/using-jobs/defining-outputs-for-jobs)

            +   GitHub 作业和 需求： [https://docs.github.com/zh-cn/actions/using-jobs/using-jobs-in-a-workflow](https://docs.github.com/zh-cn/actions/using-jobs/using-jobs-in-a-workflow)

            +   GitHub 复合 操作： [https://docs.github.com/zh-cn/actions/creating-actions/creating-a-composite-action](https://docs.github.com/zh-cn/actions/creating-actions/creating-a-composite-action)

            +   GitHub 拉取 请求： [https://docs.github.com/zh-cn/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests](https://docs.github.com/zh-cn/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)

            +   GitHub 市场： [https://github.com/marketplace](https://github.com/marketplace)

            +   Power Apps 测试 引擎： [https://learn.microsoft.com/zh-cn/power-apps/developer/test-engine/overview](https://learn.microsoft.com/zh-cn/power-apps/developer/test-engine/overview)

            +   使用 Power Apps 测试 工作室： [https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/working-with-test-studio](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/working-with-test-studio)

            +   Azure 应用程序洞察 概述： [https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview](https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview)

            +   指标 警报： [https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/tutorial-metric-alert](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/tutorial-metric-alert)

            +   操作 组： [https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups)

            +   Power Apps 与应用程序 洞察： [https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/application-insights](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/application-insights)

            +   应用程序洞察 集成概述： [https://learn.microsoft.com/en-us/power-platform/admin/overview-integration-application-insights](https://learn.microsoft.com/en-us/power-platform/admin/overview-integration-application-insights)

            +   将数据导出到应用程序 洞察： [https://learn.microsoft.com/en-us/power-platform/admin/set-up-export-application-insights](https://learn.microsoft.com/en-us/power-platform/admin/set-up-export-application-insights)

            +   Power Pages 和应用程序 洞察： [https://learn.microsoft.com/en-us/power-pages/go-live/telemetry-monitoring](https://learn.microsoft.com/en-us/power-pages/go-live/telemetry-monitoring)

            +   环境 变量： [https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables)

            +   Power Automate 自动化 中心： [https://learn.microsoft.com/en-us/power-automate/automation-center-overview](https://learn.microsoft.com/en-us/power-automate/automation-center-overview)

第三部分：探索 DevOps 最佳实践及未来发展

在本部分中，我们将探索构建融合团队的可能性，在这些团队中，专业开发者和 DevOps 工程师可以帮助低代码/无代码开发方法的实施。 我们将了解文化如何在更快的开发周期中发挥重要作用，以及构建可重用组件的重要性。 我们将看看 Microsoft Azure 云服务如何与 Power Platform 解决方案进行集成。 专业开发者将了解 Power Platform 的可扩展性，并能够利用自定义代码组件，扩展 Power Platform 的功能。 我们将通过研究人工智能如何改变我们开发业务应用程序的方式，来总结本章内容，探讨它如何帮助我们构建定制的副驾驶，不仅支持我们的 DevOps 流程，还能丰富我们的 业务解决方案。

本部分包括以下章节：

• 第九章， 实施融合开发方法

• 第十章， 在 Power Platform 中实现专业开发者扩展性

• 第十一章， 通过设计最佳实践管理环境生命周期

• 第十二章， 展望副驾驶、ChatOps 和 AI 驱动的应用程序

第九章：实现融合开发方法

Power Platform 采用低代码/零代码方法，允许接近业务流程的公民开发人员利用他们对业务问题的了解来设计并更快地将新应用投入使用。 然而，他们所面临的挑战可能会变得更加复杂，或是功能需求超出了他们的能力，因此需要专业开发人员支持开发过程，帮助公民开发人员避免 重复性的任务。

在本章中，我们将探讨组织如何将不同的角色联系在一起，构建有效的团队，合作解决挑战，并为组织提供数字化的业务解决方案。 我们将从聚焦融合开发方法的基本理解及团队如何通过不同角色进行表现开始。 接着，我们将介绍一些好的开源开发实践，这些实践同样适用于低代码/零代码，并深入了解 Power Platform 中一个支持这些实践的工具。

最后一部分将集中讨论 Azure 云与 Power Platform 之间的集成。 这里将重点介绍特定的 Azure 服务，如 Azure API 管理服务，它作为 Azure 与 Power Platform 之间的集成服务。 此外，还将涵盖一些在与 Power Platform 集成场景中经常使用的其他常见 Azure 服务。 最后，我们将通过构建低代码应用与 代码优先解决方案的集成示例来结束。

本章将涵盖以下主要内容： ：

• 什么是融合 开发方法？

• Microsoft Azure 和 Power 平台的结合

• Azure 和 Power Platform 的集成示例 场景

技术要求

本章将连接 Power Platform 解决方案与 Azure 服务。 为了跟上进度，我们建议提前准备好以下要求： ：

• Power Platform 订阅：如果你已经拥有 Microsoft Entra ID 工作账户，可以注册 Power Platform 开发者计划（https://powerapps.microsoft.com/en-us/developerplan/）；或者，你也可以加入 Microsoft 365 开发者计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。

• Azure 订阅：你可以按照此网站上的指导，注册一个免费的 Azure 账户： https://azure.microsoft.com/en-us/free。注册完成后，可以通过以下 网址 https://portal.azure.com/访问 Microsoft Azure 门户。

• Visual Studio：如果你无法访问其他版本的 Visual Studio，可以使用免费的 Community Edition（https://visualstudio.microsoft.com/vs/community/）。 一些示例展示了 Power Platform 工具在 Visual Studio 中的功能，这些功能在 Visual Studio Code 中不可用。 在其他情况下，你也可以使用 Visual Studio Code (VS Code) 和 Power Platform Tools 扩展。 VS Code 可以在以下网址找到： https://code.visualstudio.com/。

• 示例 本章讨论的示例位于以下 代码库： https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter09。

什么是融合开发方法？

本节介绍不同团队成员如何通过一个名为 融合开发方法的概念进行协作，以实现项目目标。 我们将解释这是什么，以及它如何弥合公民开发者与专业开发者之间的差距。 我们还将解释 Power Platform 如何受益于来自开源开发世界的实践，最后将我们的开发环境配置为连接 Power Platform。

融合开发涉及整合不同的团队及其技能，以促进业务能力的数字化，并提供价值。 这一术语首次由 Gartner 定义，指的是一个跨学科的数字商业团队，结合了技术和业务领域的专业知识，负责交付数字产品。 Gartner 的研究表明，与传统的集中式团队相比，实施分布式融合团队可以更快地加速实现组织数字化转型的进程。 你可以在这篇文章中阅读更多关于 Gartner 研究的内容： 页面： https://www.gartner.com/en/articles/why-fusion-teams-matter。

在 Power Platform 的世界里，融合开发方法 将低代码/无代码开发方法与传统软件开发方法以及 IT 运营相结合，用于管理资源和平台。 这些多学科团队合作的目的是利用团队所掌握的知识，并通过使用低代码/无代码工具来扩展应用程序现代化或业务流程的数字化。 它帮助组织在快速变化的商业环境中实现业务转型的成功，在这个环境中，必须尽早提供市场上可用的商业解决方案，以获得 竞争优势。

我们可以将融合团队的成员分为三种不同的 角色组：

• 公民开发者：这一群体由具备商业知识、理解 商业 流程和商业挑战的人组成，他们决心将现有的业务流程数字化。 在这里，我们可以找到商业用户、业务分析师和业务工程师。 他们将使用支持低代码/无代码开发方法的工具，如 Microsoft Power Platform，以可视化的方式设计和构建项目的某些部分。 这可能包括在 Power Apps 中构建应用程序的前端原型，或在 Power Automate 中支持业务流程的工作流。

• 专业开发人员：这是一个由经验丰富的专业开发人员组成的团队 他们精通多种编程语言，能够解决复杂的应用程序开发挑战。 通过使用传统的软件开发工具，如 Visual Studio，他们将主要为低代码解决方案构建扩展。 他们的工作将侧重于开发后端 API、集成场景或由公民开发人员在其低代码/无代码项目中使用的自定义代码组件。 如果可能，建议专业开发人员也使用与公民开发人员相同的低代码开发工具，以支持开发更简单的任务 并将自定义解决方案集成到新开发的解决方案中。

• IT 专业人士/DevOps 工程师：最后一组是 IT 专业人士，他们将负责管理资源 这些资源将会 运行新建的业务应用程序，以便以受管理和受管控的方式使用，并与组织的 IT 政策对齐。 在这一组中，我们会找到 DevOps 工程师，他们将负责管理业务解决方案的 DevOps 流程。 他们将确保项目与 DevOps 实践对齐，例如确保 CI/CD 管道正常运行，并确保业务解决方案的所有组件都 得到正确的版本控制。

下图展示了各个角色如何相互连接并协作以实现构建 业务解决方案的目标：

图 9.1 – 融合开发方法

此外，我们应该 在融合开发方法中引入另外两个人物角色，这将为 融合团队带来好处。

第一个角色是 融合团队领导。他们的职责是监督 整个项目的开发并协调团队成员，负责沟通和 项目交付。

第二个角色是 解决方案架构师 角色。 建议在项目的规划和设计阶段引入解决方案架构师，因为他们将深入研究技术细节并帮助创建解决方案的高级架构设计，关注设计模式，分享关于工具和技术选择的建议， 等等。

融合团队的规模建议与敏捷团队规模的普遍建议非常相似。 没有一种适合所有的标准；这将取决于项目的复杂性和组织的成熟度。 然而，我们应该保持融合团队的 小型 规模，以保持团队的自主性和敏捷性。 团队。

团队规模在 5 到 7 人之间被认为是合适的敏捷团队规模。 这通常与亚马逊的 “两块披萨规则” 有关，该规则表示团队应该足够小，能够被两块披萨喂饱。 小型团队有助于提高沟通和协作效率，同时保持敏捷性。 这包括迅速适应团队面临的挑战的能力，而不会引入 必要的瓶颈。

融合团队 本身可能是一个临时的， 短期团队。它的目的是解决一个特定的业务问题，一旦完成，团队解散，团队成员继续他们的正常工作例程——例如，公民开发者，可能是业务用户和业务分析师，将继续他们的工作，而软件开发人员可能会回到另一个传统的软件 开发项目。

如前所述，在某些方面，融合开发 与敏捷文化有所重叠。 融合开发方法遵循精益方法论，我们在 第一章中进行了描述。精益方法论的理念是专注于在快速迭代的开发中交付价值。 融合团队可以在冲刺中工作，以跟踪和交付工作，使用 DevOps 工具和项目规划工具，例如 Azure Boards。

Power Platform 中融合开发方法的常见示例

融合团队汇聚在一起解决业务问题。 在规划和设计阶段，这些挑战被深思熟虑，任务在利益相关者之间分配。 接下来，我们将提供几个例子，展示通过融合方法，专业开发人员和公民开发人员如何通过 技术解决方案来解决这些问题。

自定义连接器到后端 API

我们经常 在组织中看到，已经有一套系统和服务正在被旧有应用程序和业务流程所使用。 如果我们只希望现代化前端应用程序或从头开始构建一个全新的应用程序，但利用一些后端服务，我们可以在 Power Platform 中使用自定义连接器，将后端服务与 Power Platform 应用程序连接起来。 在 Power Platform 中构建自定义连接器可以帮助组织解锁对这些 API 的访问，并允许开发者在任何潜在的 新场景中重用它们。

如果我们正在构建新的 API，我们可以记住它们可能会在 Power Platform 中使用。 因此，在构建应用程序、流程和助手时，构建和使用自定义连接器是一种常见做法，尤其是在使用 Power Platform 服务时。 从角色的角度来看，举个例子，我们可能会看到专业开发人员构建新的 Web API，公民开发者在 Power Apps 应用程序中使用它们，IT 运维人员则负责管理 Power Platform 环境，构建数据丢失防护策略，并描述 所需的基础设施，使用 基础设施即代码 (IaC) 方法，这将用于配置所需的基础设施，包括 Azure API 管理，以运行支持服务。 DevOps 工程师将与专业开发人员一起，确保 CI/CD 管道已配置好，以自动化的方式构建和部署应用程序和 API。

一旦自定义连接器构建并部署到 Power Platform，我们可以在 Power Automate 中重用它，将我们旧有系统和服务的能力引入到 Power Automate 流程 所实现的业务逻辑中。

Copilot Studio 现在还提供了在自定义助手中直接使用连接器，包括自定义连接器的能力。

通过 PCF 控件扩展

有时，Power Pages 或 Power Apps 画布和 模型驱动应用中提供的控件可能不足以满足需求。 也许我们正在寻找一个图形上更丰富的组件，或者只是一个执行特定任务的自定义组件。 在这种情况下，我们可以联系专业开发人员 支持我们通过使用 Power Apps 组件框架 (PCF) 构建自定义代码组件。 PCF 组件是可重用的，并能增强 用户体验。

这是另一个很好的例子，展示了专业开发人员如何运用他们的软件开发技能。 通过使用 TypeScript 编程语言，他们开发了一个组件，市民开发人员可以将其添加到他们在 Power Apps 中构建的应用程序或在 Power Pages 中构建的网站中，以改善用户体验或实现某些额外的 业务场景。

虽然之前使用自定义连接器的示例让专业开发人员几乎可以与 Power Platform 分离，因为他们只关注 Web API 和代码组件，但专业开发人员应该了解 Power Platform，因为每种应用类型（画布应用、模型驱动应用或网站/门户）都有其独特的开发最佳实践 和限制。

在自定义助理中启用复杂技能

另一个 融合方法的例子与在 Copilot Studio 中构建自定义助理或机器人有关。 Copilot Studio 允许通过 Power Automate 流程、连接器、插件和 Copilot 框架技能扩展自定义助理的功能。 如果使用现有连接器并构建与 Copilot Studio 集成的流程是市民开发人员可以完成的事情，那么构建技能操作则需要专业开发人员的参与。 。

技能 是一个可以为另一个机器人/技能消费者执行一系列操作的机器人，通常是面向用户的机器人。 它支持多轮操作，例如进行产品订单，而与 Power Automate 流程集成的则仅支持单轮操作，例如获取 包裹的状态。

在这种情况下，专业开发人员将使用 Copilot 框架 SDK 构建一个技能，然后该技能将在自定义助理机器人中由市民开发人员使用，该机器人将在 Copilot Studio 中构建。

所有这些示例有一个共同点——可重用性。 让我们看看在 Power Platform 中构建目录如何帮助组件的可发现性和可重用性。

通过开源开发实践增强协作

组织将以快速的 速度实施 新应用、流程或聊天机器人。 Fusion 团队将在 Power Platform 中开发许多可以在其他项目中重用的组件，而不是浪费时间重新发明轮子。 我们如何消除组织中的信息孤岛，赋能任何开发者，无论是专业开发者还是公民开发者，让他们了解已经完成的工作，并允许他们在自己的项目中重用这些成果呢？ 在回答这个问题之前，让我们稍微退一步，看看传统软件 开发世界是如何解决这个问题的。

不久前，许多组织 都非常封闭，独立 进行项目工作，缺乏合作。 这导致了重复的工作和开发过程中的低效率。 团队之间相互隔离，合作和沟通非常差，甚至根本不存在。 我们有时也会遇到对新想法或做法的抵触，这些新方法可能会改变团队的运作方式。

然而，如果我们看看开源世界中的软件开发实践，我们可以看到开源软件如何可能与任何人共享，开放供使用和修改。 几乎任何人都可以审查项目，修改和重用开源软件。 这种方法的目标是构建更可靠 和更优质的代码。

这时我们需要引入 InnerSource。InnerSource 是一种开发 方法论，它将开源软件开发的优秀实践应用到一个封闭的群体——组织的员工中。 这意味着软件开发项目将成为组织的私有开源项目。 一个组织的项目。

有趣的是，这种使用 DevOps 工具（如 Azure DevOps 和 GitHub）的开发方式，可以用于任何类型的项目，甚至是软件开发之外的项目。

InnerSource 为软件开发带来了现代化的方法，帮助我们消除传统专有软件在组织中带来的挑战。 在组织中开放地合作将有助于改进创新，因为更多人可以参与项目并做出贡献。 开发人员不必总是从头开始构建项目，因为 InnerSource 有助于 发现性。也许我们的组织内已经存在可以重复使用的东西。 这将推动快速开发，降低开发成本，提高上市时间。 它将改善协作，并且最重要的是，培养开放的文化。

InnerSource Commons Foundation 每年进行的研究称为 InnerSource 状态报告 (可在 https://innersourcecommons.org/找到)，它识别了 InnerSource 的好处和阻碍。 未应用 InnerSource 实践的常见阻碍包括组织文化、独立思维以及对 InnerSource 原则的认知和熟悉度不足。 因此，确保开发人员熟悉这些实践，并在组织中推广这一策略至关重要，这将有助于我们分配资源和时间来实施和释放 InnerSource 的好处。 该组织内。

这些良好的实践也可以应用于低代码/无代码 开发方法。

融合开发团队，尤其是专业开发人员和 DevOps 工程师，使用诸如 Azure DevOps 和 GitHub 等 DevOps 工具执行许多任务，其中 InnerSource 方法是产品的核心。 Azure Boards 或 GitHub Issues 等工具使开发人员能够提出新功能的想法，报告产品中的错误，评论任务等。 拉取请求机制通过构建验证和同行审查确保最终生成物符合所有要求，从而实现更好的结果。 为了进一步支持良好的 DevOps 实践，公司可以通过产品如 Microsoft Teams 扩展其工具集，以改进融合团队的沟通和协作，并 实现 ChatOps。

DevOps 工具的服务和功能 是以帮助 组织更轻松地实现和促进 InnerSource 的方式构建的。 为了让组织了解是否朝着目标前进，他们应该实施定期评审，以了解 InnerSource 的 采用情况。

构建目录流程

在为 Power Platform 开发业务解决方案时，我们还应该考虑如何遵循 InnerSource 最佳实践，允许融合团队共享他们的工作，并允许其他团队重用组件和构建的模板。 虽然在 Azure DevOps 和 GitHub 中打开项目可以让专业开发人员了解组织中有哪些项目，但我们不能指望业务用户按照与专业开发人员相同的步骤进行操作。 还有一种方法可以将我们的工作分享给组织中的任何人。

Power Platform 中的 目录 是所有已部署到目录并需要进行目录化和重用的组件和模板的唯一真实来源。 它以模型驱动应用的形式出现在 Power Apps 中，帮助我们了解组织中已经有哪些资源可用。 Power Platform 目录不是一个版本控制系统，不能替代用于版本控制和 CI/CD 流水线的 DevOps 工具。 然而，它确实增强了 ALM/DevOps 流程，因为它支持通过 PAC CLI 命令进行自动化场景，就像我们在 第六章 中的示例所看到的那样。

组件和模板在目录中作为项目呈现。 专业开发人员和公民开发人员将使用目录了解组织中现有的项目，以及谁发布了这些项目。 它还将用于在新项目中查找和重用组件，或从现有模板开始。 另一方面，IT 运维团队将使用目录的管理功能来控制代码组件 和模板的使用。

我们建议首先在组织中安装一个目录。 然而，在某些情况下，组织需要在 Power Platform 租户中安装多个目录——例如，如果一个组织有非常敏感的项目，必须与其他项目隔离。 在这种情况下，应该安装另一个目录，以提供所需的 隔离级别。

预览功能

请注意， 截至撰写本文时， Power Platform 中的目录 是一个预览功能，因此在功能上有一些限制，例如它不能在使用客户管理密钥的环境中使用。 在预览阶段，目录可以在所有类型的环境中使用，但发布到正式版后，这将仅在 受管 环境中可用。

目录过程

Power Platform 中的目录 遵循从目录项创建到获取阶段的生命周期，新的团队将在此阶段重复使用之前开发的 目录项。

这一过程始于由专业开发人员和公民开发者组成的融合团队，创建组件并构建包含解决初始业务挑战的所有组件的目录项。 这些目录项还包括在正确配置目录项时所需的配置参数。 以确保目录项能被正确配置。

这些目录项随后将提交到目录中，以供重新使用。 一旦提交，IT 管理员和业务线审批人员将审核这些新的目录项并相应地批准它们。 并据此进行批准。

其他专业开发人员和应用程序开发者 将使用该目录查找现有的解决方案和模板。 那些看似适合他们业务问题的目录项将被重新使用。 为了完成配置，开发者必须提供所有必要的配置参数并建立所需的连接。 之后，该目录项将在他们的环境中成功配置。 现在，他们可以在自己构建的解决方案中重复使用这些组件。 他们正在构建自己的解决方案。

从目录管理员开始

在我们开始在 Power Platform 中使用目录之前 ，我们必须首先从 Microsoft AppSource 安装它。 我们应该在环境中分配一个 系统管理员 安全角色，以便能够安装目录管理器。 目录管理器将安装在一个 Dataverse 环境中，该环境的数据库版本应至少为 9.2.22122.00148。我们可以在环境设置中的 版本 卡片上查看 Dataverse 版本。 我们首先需要打开 Power Platform 管理中心 | 环境 ，然后选择该环境，并选择 版本 卡片。

我们建议为目录创建一个单独的 Power Platform 环境。 这样，任何人都可以访问该环境并查看目录项，也可以将目录中的项安装到他们的环境中。

一旦我们完成所有前提条件的检查，就可以继续进行 安装。

我们可以选择通过 PAC CLI 安装目录管理器。 为了做到这一点，我们首先连接到我们希望安装目录管理器的 Power Platform 环境。 在该环境中，我们使用 pac application list 查找我们租户中所有可用的应用。 其中之一将是 mspcat_CatalogManager 或 GUID 为 83a35943-cb41-4266-b7d2-81d60f383695。这个唯一名称或 GUID 可以用来通过 pac application install --application-name mspcat_CatalogManager安装应用到当前环境。 要将应用安装到不同的环境中，使用 --environment <ENV_ID> 并替换为适当的环境 ID 或 URL。 为了验证我们是否已在租户中安装了目录，我们可以使用 pac admin list --application 83a35943-cb41-4266-b7d2-81d60f383695，它将返回安装了目录管理器的环境信息。

如果我们想通过 UI 安装此应用程序，我们需要直接使用此链接进行安装： https://appsource.microsoft.com/product/dynamics-365/powerappssvc.catalogmanager-preview?flightCodes=dde212e5c66047c59bf2b346c419cef6。当提示我们登录 Microsoft AppSource 时，我们需要使用系统管理员帐户登录并点击 立即获取进行确认。这会将我们带到 Dynamics 365 应用 内的 Power Platform 管理中心 以完成安装过程。 最后一步，我们需要选择一个环境来安装此应用程序。 我们需要同意条款和隐私声明，然后可以点击 安装 来安装应用程序。 安装过程 大约需要几分钟时间。 。

图 9.2 – 安装目录管理器应用

安装过程会安装一个新的 Power Apps 应用程序。 安装完成后，我们需要配置目录元数据。 首先，我们需要运行目录管理器。 访问目录管理器是通过 Power Apps 完成的。 我们可以在相应环境的应用程序列表中找到此应用。 只需进入 Power Apps | 应用，将鼠标悬停在 Power Platform 目录管理器 应用名称上，点击 播放 图标运行应用程序，或者点击名称旁边的三个点，再点击 播放 以运行 应用程序。

现在我们已经启动了应用程序，可以通过打开配置组来配置元数据。 在左侧导航栏的最底部，点击 目录，这将打开一个选择区域的选项；从那里，点击 设置。这将打开配置组，我们可以在这里配置 目录， PowerApps 检查器的规则集， 静态分析策略，和 PowerApps 检查器的配置。点击 目录 将打开 目录配置，如 图 9.3所示。 在这里，我们可以更改目录名称、描述、帮助链接和图像，以帮助我们识别该目录。 在右侧的 目录配置中，我们可以启用目录、允许未管理的解决方案（未来功能计划）部署到目录，并启用在目录级别发布的目录项目的全局自动审批。 此最终设置的自动审批，如果在全局级别配置，将覆盖 发布者级别 的设置。

图 9.3 – 目录元数据和配置

要返回到主要的 目录 区域，我们可以点击左侧导航栏中的 主页 导航。 在这里，我们将看到带有操作项的单独仪表板，包含所有审批请求的 审批 部分，包含已发布目录项的 目录 部分，以及部署历史记录。 每个部分的详细信息和说明可以在 这里找到： https://learn.microsoft.com/en-us/power-platform/developer/administer-catalog。

发布新的目录项目

假设我们已经成功 构建了一个我们希望发布到目录并允许其重用的解决方案。 要将项目发布到目录，我们需要一个包含我们希望发布的项目的解决方案或包部署器包，并且还需要一个提交元数据 JSON 文件。

我们将使用 PAC CLI 来操作目录项目。 正如我们已经习惯的那样，我们将启动终端并运行 pac auth create 命令来创建一个认证配置文件（如果我们还没有的话）或重用现有的认证配置文件。 我们可以使用 pac auth list 命令检查现有的认证配置文件。 请记住，当我们需要连接到一个环境，以便在其中发布项目时，我们使用 pac auth create –-environment 或 -env 开关，并提供目录所在环境的名称或 ID。

使用 pac catalog list 将显示我们所有已发布的 目录项目。

现在，我们已经准备好将新的项目发布到目录中。 我们将使用 pac catalog create-submission 命令生成一个默认的提交元数据 JSON 文件，名为 submission.json ，该文件位于终端当前操作目录中（要更改路径，我们可以使用 --path 开关）。 我们需要编辑这个文件，为计划提交的目录项目做准备。

注意

当该预览功能接近正式发布时，这个命令也可能会发生变化。 使用 pac catalog --help 可以查看所有 可能的命令列表。

提交 元数据 JSON 文件包含我们需要更新的提交属性，以使其与我们的目录项目匹配。 使用之前的命令创建的示例文件类似于以下内容：

 {
  "modelVersion": "1.0.0.0",
  "sourcePortal": 526430000,
  "operation": "CreateOrUpdate",
  "businessJustification": "Business Justification",
  "publisherDetails": {
    "publisherId": "742d02b8-59ad-4aa4-b95a-bd41cd0459ed",
    "publisherDisplayName": "Publisher Display Name"
  },
  "catalogItemDefinition": {
    "id": "1cd8fe87-f508-42ad-8dcd-d12dda7d8668",
    "displayName": "Catalog Item Display Name",
    "description": "Catalog Item Description",
    "offer": {
      "type": "Component_Collection",
      "deploymentType": "Normal",
      "engineeringName": {
...},
      "supportName": {...}
    },
    "packageFile": {...}
  }
}

从提交元数据 文件中，提交时需要的四个属性为：发布者、目录项目、工程联系人和 支持联系人。

发布者属性位于 JSON 部分中，描述为 publisherDetails。它们是一个或多个 Microsoft Entra ID 组，这将允许属于该组的用户在未来更新目录项。 当我们提到 publisher时，这可以是一个专注于特定项目的融合开发团队，或者是组织中某个特定部门的开发人员组。 我们建议提供 publisherID 和 publisherDisplayName，因为这些用于验证发布者 是否已存在。

目录项是我们计划发布的解决方案。 我们需要提供 id 和 displayName 以及 engineeringName 和 supportName，因为这些是必需的属性。 工程联系信息帮助那些希望重用该目录项的人了解如果有任何关于该项的问题，应该联系谁。 支持名称 有助于识别谁可以提供支持，如果目录项有任何技术问题。 目录项。

属性的完整描述 可以在此文档 页面中找到： https://learn.microsoft.com/en-us/power-platform/developer/submit-catalog-items。

示例 - 提交项到目录

假设我们有一个模板 应用程序，作为 Power Apps 中的画布应用程序构建。 这将代表我们模板化的画布应用程序。 除了应用程序，我们还可以将其他组件作为解决方案的一部分，例如流程、Dataverse 表格等。 所有这些内容都被打包在 一个解决方案中。

从目录过程的角度来看，在创建阶段，我们正在处理我们的解决方案。在前面的章节中，我们已经看到如何将包创建作为 ALM 过程的一部分。现在，一旦我们准备好导出的解决方案，我们可以通过运行pac catalog create-submission命令来创建提交 JSON 文件。我们需要更新提交属性，以正确反映我们的目录项目。我们将更新业务类别，提供发布者详情，并通过提供 ID、显示名称、描述、联系人以及其他必需的属性来修改目录项定义。一个示例解决方案的提交 JSON 文件示例已上传到本书 GitHub 仓库的章节文件夹中（github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter09）。

当我们准备好 JSON 文件并希望开始提交过程时，我们使用pac catalog submit --path <提交 JSON 文件位置> --solution-zip <解决方案文件位置>。

如果我们希望提交到不同环境中的目录，可以将--environment开关添加到命令中并指定环境。这将产生类似于以下内容的输出：

 PS E:\PACKT\CH9> pac catalog submit -p .\claims-submission.json -sz .\Claims_managed.zip
Connected as <your_user@domain>
Connected to... <your environment name>
Creating package for catalog submit request... Tracking ID for this submission is 9dc32d51-9de4-ee11-904d-000d3a1e7712

我们可以使用pac catalog status --tracking-id <提交跟踪 ID> --type submit命令检查提交状态。如果我们是提交到不同的环境，则需要向命令中提供环境名称。type参数允许我们检查install和submit操作的状态。前面的命令将生成类似以下内容的输出，也展示了跟踪 ID 和类型的短别名使用：

 PS E:\PACKT\CH9> pac catalog status -id 9dc32d51-9de4-ee11-904d-000d3a1e7712 -t submit
Connected as <your_user@domain>
Connected to... <your environment name>
Status of the Submit request: Submitted

如果状态是Failed Prevalidation，我们可以在 Catalog Manager 中查看错误的详细信息，在Failed Pre-Validation下。

现在我们看到我们的状态为 已提交，目录过程的第二阶段（提交）已完成，我们正进入下一个阶段（批准和存储）。 我们的目录项已提交等待批准。 批准状态可以在目录管理器应用程序的仪表盘部分查看，位于 批准请求状态 或 批准 | 请求。

图 9.4 – 提交的目录项的批准请求

一旦目录项获得批准，它将被存储在目录中，可以通过访问目录管理器并导航到 目录项找到它。 出版商也将显示在 目录出版商 中，工程和支持联系人将被添加到 联系人 信息 列表中。

专业开发人员将在目录项详情中找到一个便捷的属性 ，该属性提供一个 代码库 链接，您可以在目录项的 链接和法律 部分找到它。 这使我们能够告知专业开发人员源代码的位置，这仅仅是之前提到的 InnerSource 方法论的进一步完善，因为现在专业开发人员也可以审查代码并参与到 开发过程中。

示例 – 从目录安装目录项

现在我们进入目录过程的发现阶段 。 在此阶段，应用开发者或专业开发人员会审查目录，或使用 PAC CLI 通过 pac catalog list 命令列出给定目录中的任何目录项。 这将返回环境中的所有目录项。 我们还可以使用 --catalog-item-name 或 --catalog-item-id 作为附加的搜索机制，通过名称 或 ID 仅查找特定的目录项。

一旦我们审查了目录项并决定在开发环境中测试它们，我们可以使用 pac catalog install --catalog-item-id <catalog-item-id> --environment <your environment guid or absolute https URL>进行安装。这将把我们带入目录过程的最后阶段， 称为获取阶段。

请记住，如果我们计划在另一个环境中安装目录项，我们需要在该环境中安装目录管理器 。

一旦我们运行该命令，我们将获得类似 这样的输出：

 PS E:\PACKT\CH9> pac catalog install -env https://<orgid>.crm.dynamics.com/ -cid 1cd8fe87-f508-51ad-8dcd-d12dda7d8668
Connected as <user@domain>
Connected to... <your environment name>
Tracking ID for this installation is 34f8e610-a7e4-ee12-904d-000d3a1d5312

要使用 UI 发现、查看和安装可用的目录项，应用程序开发者还可以前往 Power Apps 或 Power Automate 并点击 更多 | 目录 在左侧导航栏中（请注意，这项功能当前处于公开预览阶段）。 这将打开 目录 区域，在此我们可以在租户的一个或多个目录中搜索所有可用的目录项。 在这里，我们将找到所有可重复使用的已发布目录项以及关于个人活动的信息，包括获取目录项或提交新 目录项。

图 9.5 – Power Apps 中的目录区域

我们可以继续使用 获取 按钮，为我们希望在当前环境中安装的每个目录项，按照安装向导进行操作，并完成 安装过程。

现在，无论是通过 UI 还是 PAC CLI 安装的该项，我们都可以使用这个新组件。 如果该解决方案作为未管理的形式部署到开发环境，并计划进一步开发它，我们可以继续按照我们的需求进行开发，然后遵循 ALM 流程将其部署到生产环境中，带着 创建的更改。

别忘了，目录 过程是持续的，涉及到将开发和部署到目录中以便进一步重用。 作为开发人员，我们将在开发阶段花费更多时间，所以让我们来探索一些开发人员在使用 Visual Studio 时可以在 Power Platform 中使用的附加工具。

开发人员使用 Visual Studio 的附加工具

从工具的角度来看，公民开发者 专注于使用低代码/零代码 开发工具，如 Microsoft Power Platform。 尽管专业开发者在可能的情况下也应该使用与公民开发者相同的低代码/零代码工具，但集成和自定义组件则需要自定义编码，针对这些需求，IDE 如 Visual Studio 或 VS Code 将被使用。 一些开发者工具已经在前面的章节中提到并使用过，例如 Power Platform CLI 和 Power Platform Build Tools，结合 Azure DevOps 和 GitHub。 与 VS Code 的 Power Platform Tools 扩展类似，编写代码的 Visual Studio 开发者可以安装 Visual Studio 的 Power Platform Tools 扩展。

Visual Studio 的 Power Platform Tools 扩展可以在 Visual Studio Marketplace 中找到，类似于我们在 第二章 中描述的 VS Code。 作为安装的前提条件，我们需要至少拥有 Visual Studio 2019 或更高版本，并且需要 .NET Framework 4.6.2，如果我们希望构建插件或 工作流活动。

我们可以从 Visual Studio Marketplace 安装扩展（https://marketplace.visualstudio.com）或在 Visual Studio 中安装：在顶部菜单栏中，点击 Power Platform 在搜索栏中，点击 下载。当下载完成后，我们必须重启 Visual Studio，以完成计划中的扩展安装 。

图 9.6 – 为 Visual Studio 安装扩展

卸载可以像安装一样 以类似的方式进行。 进入 扩展 | 管理扩展。这时，选择 已安装 在左侧导航栏中，找到 Power Platform Tools 扩展，然后 点击 卸载。

扩展只有在我们使用 Power Platform 项目模板创建新项目或打开一个已经包含至少一个使用 Power Platform Tools 模板创建的项目时才会可见。

我们还可以在首次连接到 Dataverse 环境后显示 Power Platform Explorer 。 我们可以通过在顶部菜单栏中选择 工具 ，然后点击 连接到 Dataverse…。

图 9.7 – 从 Visual Studio 连接到 Dataverse

这将打开一个新的向导 窗口，我们将在其中使用我们的用户身份验证连接到 Dataverse 环境。 对于登录部署类型，我们选择 Office 365 ，因为这将允许我们使用 Microsoft Entra ID 作为身份验证提供者。 一旦我们通过用户身份验证，我们将被提示选择将要操作的解决方案。

如果所有步骤都成功完成，Power Platform Explorer 应出现在我们面前，并连接到所选解决方案所在的环境。 现在我们有机会探索我们的环境，并将插件添加到选定的表格中，注册 Webhooks，添加工作流活动等等。 请注意，对于开发自定义工作流活动，我们需要安装 Windows Workflow Foundation。可以通过 Visual Studio 安装程序安装，方法是选择 修改 我们用于开发的 Visual Studio 版本。 在安装程序中，打开修改安装的窗口。 在这里，我们选择 单个组件 并搜索 Windows Workflow Foundation。 我们选择它并点击 修改，这将下载并安装该功能。

图 9.8 – Power Platform Explorer

Power Platform Tools for Visual Studio 提供了一套项目模板，使我们能够使用 C# 编程语言开发前述的 Power Platform 插件、定制工作流活动、解决方案模板和用于将解决方案和自定义代码库部署到我们的 Dataverse 环境的包。

使用 Visual Studio 开发后端 API 的开发者，还可以通过 “连接服务” 扩展 Visual Studio 的功能，以便在 Power Platform 中创建自定义连接器。 为了利用此功能，我们需要至少使用 Visual Studio 2022，版本 17.7，并安装 ASP.NET 和 Web 开发工作负载。 目前，这项功能在 Visual Studio for Mac 中尚未启用。 我们的 API 应该作为 ASP.NET Core Web API 项目进行开发。

我们将在 第十章中进一步讨论自定义连接器、代码组件以及专业开发人员的扩展性。

现在我们已经准备好了所有工具，接下来可以看看 Power Platform 如何与 Azure 服务集成。

微软 Azure 和 Power Platform 携手合作

本节将重点介绍与 Power Platform 集成场景中最常用的 Azure 服务。 我们将这些服务分为按其提供的功能进行分组，并简要描述了它们。 对于每个工作负载，我们提供了如何将 Azure 服务与 Power Platform 配合使用的示例。

作为云平台，微软 Azure 使我们能够在云中运行不同的工作负载，例如将我们的应用完全托管在 Azure 中，或者将本地应用与 Azure 服务进行扩展和连接。 正如我们在前面的章节中看到的，当组织在现代化他们的应用或构建新应用时，他们总是有机会选择使用低代码/无代码开发方法来现代化现有应用或构建新应用。 然而，很多时候，场景过于复杂，需要团队作为融合团队来合作，在这个团队中，专业开发人员专注于使用 Azure 提供的服务来开发复杂的场景。 Azure 提供的服务。

微软 Azure 提供了丰富的云计算服务，可以覆盖从计算服务、网络、存储、Web 服务等多个复杂场景。 让我们来看看一些与 Power Platform 广泛集成的 Azure 服务。 我们无法涵盖所有服务，因为选择太多，因此我们建议你访问 Azure 产品 网页，进一步了解这些服务： https://azure.microsoft.com/en-us/products。

应用程序托管服务

Azure 提供了广泛的服务，可以托管应用程序。 这些服务有不同的用途，从可以运行 Spring Boot 应用程序的服务到容器托管服务，再到多用途 Web 托管服务，如 Azure App Service：

• Azure App Service 是一项托管服务，允许 我们托管 Web 应用程序，Web API 和移动后端。 由于它是托管的 PaaS 服务，云提供商负责维护操作系统和基础设施，而我们专注于构建应用程序。 它是一个可扩展的企业级服务，允许根据负载自动缩放应用程序，同时保持高度 的安全性。

• Azure Container Apps 是一个无服务器平台，专为运行 容器化应用程序而设计。 与 Azure Kubernetes Service (AKS)相比，后者是一个托管的 Kubernetes 集群，需要我们管理连接到 AKS 集群的节点。而 Azure Container Apps 则提供了一个完全托管的 Kubernetes 服务，可以自动扩展我们的应用工作负载，而无需管理 基础设施。

让我们来看一个 Power Platform 集成示例。 前面提到的两种服务用于运行前端应用程序或后端 API 端点。 我们可以使用它们来运行后台处理作业或构建并运行我们的 Web API。 当我们选择容器作为打包和部署选项时，还可以将我们的微服务部署到 Azure Container Apps 或类似的 Azure 容器运行服务上。 这些 API 将通过 Azure API Management 安全地公开，并作为我们 自定义连接器的后端。

集成服务

Azure 集成服务是一组 Azure 服务，允许组织构建连接不同系统和应用程序的解决方案。 它们可以用于提供高度安全的消息平台，构建 ETL 流程和执行数据转换，或通过 API 安全地公开后端系统供内部和 外部使用：

• Azure API 管理 (Azure APIM) 使组织能够管理 API 并将它们暴露给其他应用程序， 使得这一过程既快捷又安全。 它由三个组件构成：网关、开发者门户和管理员管理面板。 后台应用程序和数据可以驻留在 Azure 或其他环境中（包括本地环境），同时为客户端提供一个前门， 该前门可以将请求路由到后台，同时保持对请求和响应流的控制。

  Power Platform 集成示例：一旦我们准备好了 API，通过 Azure APIM 将它们暴露出来 使我们能够快速在 Power Platform 中创建自定义连接器。 自定义连接器将用于我们的应用程序 或流程。

• Azure Functions 是一个事件驱动的无服务器计算平台，允许开发人员使用 事件驱动的触发器和绑定将函数连接到其他服务并执行应用程序逻辑。 由于它是一个无服务器平台，云基础设施的管理由云提供商和平台承担， 因此无需担心管理开销。 Azure Functions 通常用于需要处理数据的场景（例如响应事件、数据库更改或读取存储在 Azure Service Bus 中的请求）， 或者当从不同的 IoT 流中捕获数据并需要实时处理时。

  Power Platform 集成示例：Azure Functions 用于处理存储在数据存储中的数据，包括 Dataverse。 它允许通过 REST 端点实现 Web API，执行特定的复杂逻辑。 这些 API 可以通过自定义连接器与我们的 Power Platform 解决方案连接，执行 API 操作。

• Azure Service Bus 是一个异步消息传递云平台， 它允许我们创建可靠的消息传递解决方案。 它的设计目标是实现应用程序解耦并构建 可扩展的系统。

  Power Platform 集成示例：它使我们能够在应用程序和后台服务之间启用异步通信，从而将应用程序和服务彼此解耦。 通过在 Power Platform 中使用 Service Bus 连接器，我们可以执行诸如发送或接收消息 到/从队列的操作。

• Azure Logic Apps 是一个云平台，用于创建 和运行自动化工作流，类似于 Power Automate，但更侧重于专业开发人员和 IT 专业人士。 它具有 Power Automate 没有的一些独特功能，比如利用 Visual Studio 和 VS Code 通过扩展来开发和审查工作流 代码。

  Power Platform 集成示例：它可以用于自动化与 Azure 相关的任务或更 复杂的流程，这些流程不一定与 Power Platform 解决方案相关。 我们可以构建自定义连接器，连接到 Logic Apps 工作流，并通过 Power Automate 或 Power Apps 中的自定义连接器运行该工作流。

数据分析

Azure 提供了一套数据分析 服务，帮助我们获取存储在任何地方的数据洞察，支持来自 IoT 设备的实时数据流，处理遥测数据的摄取， 等等：

• Azure Event Hubs 为集成提供了一个共同的点 ，适用于应用程序需要响应实时事件的场景。 它允许从不同来源摄取实时事件数据。 在处理 IoT 场景或应用程序监控时，使用它非常常见。 由于 Power Platform 包含了 Azure Event Hubs 的连接器，我们可以更容易地构建集成。

  Power Platform 集成示例：当 IoT 设备将数据发送到 IoT Hub 时，数据会被 Azure Functions 处理并发送到 Azure Event Hubs。 当事件在 Event Hubs 中可用时，Power Automate 流程会被触发并执行 相应的逻辑。

• Microsoft Fabric 是一个统一的分析平台 ，连接了如 Azure Data Factory、Azure Synapse Analytics 和 Power BI 等工具。 Fabric 包括 一个多云数据湖，称为 OneLake，它位于上述 Fabric 工具下方，帮助消除数据孤岛。 OneLake 作为一个单一的存储系统，允许组织将来自不同数据源的数据结合起来，包括 Dynamics 365 数据。 一旦数据被表示在 OneLake 中，组织就可以在 Microsoft Fabric 中执行不同类型的分析。

  Power Platform 集成示例：最近，Power Platform 引入了与 Microsoft Fabric 的 Dataverse 集成。 它开启了将 Dataverse 连接到 Fabric 的可能性，使用 Link to Fabric，以及一个将 Fabric 连接到 Dataverse 的场景，利用虚拟表。 Link to Fabric 允许组织将数据保留在 Dataverse 中，同时启用 Fabric 中的分析功能，以发现数据中的洞察。 这些洞察可以以虚拟表的格式返回到 Dataverse，这使得开发人员能够在业务流程中利用这些发现。 与之前数据停留在 Dataverse 中类似，在这里，数据驻留在 OneLake 中。

AI 服务

Azure AI 服务 是一组 REST API 和客户端库 SDK ，使专业开发人员能够使用预构建和可定制的 AI 模型创建智能应用，这些模型具有自然语言理解、语音能力、视觉能力等认知功能。 Azure AI 服务是如 Azure OpenAI、Azure AI 搜索、视觉、语音等服务的总称。 以及更多服务。

让我们来看一个 Power Platform 集成的示例。 尽管 Power Platform 包括 AI Builder，利用了一些预构建的模型，Azure AI 服务提供了额外的功能，例如集成语音转文本和文本转语音功能，或者利用其他 AI 模型 在我们的 业务应用中。

数据存储

Azure SQL 数据库 是一个完全托管的关系型数据库。 它是 Azure SQL 的 PaaS 部署，支持 超大规模（无限的数据库存储）和自动扩展。 由于许多组织已经在使用 SQL Server 作为他们的数据库系统，这样的选项使他们能够现代化其数据库，并消除管理 基础设施的需求。

让我们来看一个 Power Platform 集成的示例。 Power Platform 根据客户的数据需求提供支持。 这就是为什么 Power Platform 中有超过 1,000 个连接器，其中之一也是用于连接 SQL 服务器。 这使我们能够构建连接到现有 数据源的应用和流程。

Azure 提供了额外的数据库服务。根据项目的需求，我们可以使用其他关系型数据库，如 PostgreSQL、MySQL 或 MariaDB，或者非关系型数据库服务，如 Cosmos DB。对于这些数据服务中的每一项，都有一个连接器，我们可以使用它来构建我们的自动化流程或业务应用程序，利用现有的数据库。

上述服务只是 Azure 所提供的众多选项中的一小部分。在规划项目时，请咨询具有云计算知识的解决方案架构师或企业架构师，以确定哪些服务最适合计划中的项目。

Azure 和 Power Platform 集成场景示例

本节聚焦于一个实践案例，展示了融合团队如何协同工作。该案例展示了通过使用自定义连接器和 Azure 服务（如 Azure API 管理）将 Power Platform 与 Azure 连接起来。

本章中的示例聚焦于将用 C# 编程语言编写的 Web API 模板与 Power Platform 作为自定义连接器集成，使用 Visual Studio 2022。我们在上一章中已经安装了 Power Platform 工具在 Visual Studio 2022 中。本示例将展示如何通过现代工具，帮助专业开发者构建和测试支持 Power Apps 业务应用程序的 Web API。Web API 将部署到 Azure 服务并通过 Azure API 管理进行暴露。

在这里，我们将介绍两种创建自定义连接器的方法：一种是借助 Visual Studio 2022，另一种是借助 Azure API 管理。

一旦创建了自定义连接器，我们的公民开发者就可以在 Power Platform 中使用这些操作来开发他们的业务解决方案。

下一章将重点介绍 Power Platform 各个组件的 ALM 流程，因此在这里我们将展示融合开发方法的概念。

让我们先从创建 Web API 开始。

使用 Visual Studio 2022 创建 Web API 和 Power Platform 自定义连接器

我们将戴上专业开发者的 帽子，并使用 Visual Studio 2022 中的 ASP.NET Core Web API 模板创建我们的示例 API。 我们这样做是为了展示专业开发者在融合开发团队中使用 Visual Studio 开发项目时所获得的能力，该项目主要部署在 Power Platform 服务上。

当 Visual Studio 启动时，它会欢迎我们进入一个窗口，在这个窗口中，我们可以通过点击 web api来创建一个新项目，选择 C# 语言中的 ASP.NET Core Web API 模板，然后点击 Next，如以下图所示：

图 9.9 – 创建一个新的 Web API 项目

在接下来的 界面中，我们将 提供我们的 GET 操作，名为 WeatherForecast，它已经是 模板的一部分。

作为 DevOps 经验的一部分，我们的任务是对代码进行版本控制，这意味着我们要么在 Azure DevOps 或 GitHub 上创建一个新项目，要么使用现有项目来进行这一部分工作，然后将我们的代码提交到代码库，并进行首次提交。 我们在 main 分支上启用分支保护，并配置其他策略，正如我们在前面的章节中学到的那样。 此时，我们的 API 开发者可以按照 DevOps 最佳实践继续他们的工作。

回到我们的示例，我们可以测试新创建的项目，或者继续开发并删除现有的 WeatherForecast 操作，继续开发业务项目要求的 API 操作。

当我们想测试 已开发的 API 时，我们可以简单地按下 F5 键启动调试过程，或者前往顶部导航栏，展开 调试，并选择 开始调试 以在浏览器中启动我们的 API。 这将打开 Swagger UI，显示我们的 Swagger 文件，其中包含 Web API 中所有存在的操作。 Swagger 提供了一种方便的方式来设计、文档化并使用我们的 API。 它使用 OpenAPI 规范，并提供了一组开源和商业工具来处理 Swagger 文件，该文件采用 JSON 格式描述我们的 API 操作。 OpenAPI 定义在创建自定义连接器时也被 Power Platform 使用 ，并且它必须采用 OpenAPI 2.0（之前称为 Swagger）格式。

当我们准备好 API，并希望在 Power Apps 应用程序或 Power Automate 流程中测试它时，我们可以将 Power Platform 添加为连接的服务。 这样，Visual Studio 将自动为我们在 Power Platform 中创建一个自定义连接器。 为此，我们前往 Visual Studio 中的 Web API 项目。 在 解决方案资源管理器中，我们展开项目，以便看到 连接的服务 | 添加 | Microsoft Power Platform。这将打开一个新标签页，并显示在 连接的服务 部分，出现一个 连接到 Microsoft Power 平台 的窗口：

图 9.10 – 将 Power Platform 添加为连接的服务

这个新窗口包含所有用于创建新自定义连接器的参数。 在创建之前，我们需要确保已经登录。 如果没有，在右上角，我们可以登录并提供正确的用户凭据。 身份验证通过后，我们选择一个 Power Platform 环境，将自定义连接器部署到其中。 在 Power Platform 解决方案 下拉菜单中，我们选择要部署连接器的解决方案。

接下来，我们连接 到自定义 连接器。 在我们的案例中，由于我们第一次创建它，因此我们将点击 + (加号图标)来创建一个新的自定义连接器。 我们将勾选 自动生成 OpenAPI V2 规范 ，以便 Visual Studio 为我们生成 OpenAPI 定义。 最后，我们将通过点击 + （加号图标）创建一个 公共开发隧道 ，点击 选择公共开发隧道，该隧道将用于在自定义连接器与我们实例中的 Visual Studio 之间进行调试。

开发隧道

Visual Studio 中的开发隧道提供了一种快速、安全的方式来测试互联网中的 Web API。 在我们的案例中，Power Platform 服务将创建一个连接，连接我们本地运行 Visual Studio 的机器和一个使用自定义连接器的 Power Platform 服务（即使用自定义连接器的 Power Apps 应用程序）。 这种方法旨在为开发和测试目的创建临时连接，不适用于 生产工作负载。

以下截图展示了 我们如何在连接到 Microsoft Power Platform 后创建一个公共开发隧道。 当我们点击 下一步时，我们会看到 更改摘要 页面，通知我们将在 Microsoft Power Platform 中创建一个自定义连接器。 我们通过点击 完成来确认这一操作。该过程将构建我们的项目，配置开发隧道，生成 Swagger JSON 文件（OpenAPI 规范文件），并在我们选择的 Power Platform 环境中创建一个自定义连接器：

图 9.11 – 创建自定义连接器

现在开发隧道和自定义连接器已创建，如果我们现在运行我们的 API（通过按下 F5 或点击 调试 | 开始调试），我们将看到 Visual Studio 使用 开发隧道 功能，并将我们的 Web API 暴露到公共端点，通知也会在 Web 浏览器中弹出，告知我们这一点。 确认后，开发隧道建立成功，我们可以在 Power Platform 中使用这个自定义连接器，它现在已连接到我们的 Visual Studio 开发环境。 这是调试我们的 Web API 和自定义连接器的非常便捷的方法。 我们现在可以在任何 Power Apps 应用程序或其他 Power Platform 服务中使用这个自定义连接器，并在 Visual Studio 中的 Web API 源代码中设置断点进行调试。 一旦 API 操作被执行，我们就能在 Visual Studio 中看到调试引擎已触发我们设置的断点。 这将帮助我们继续进行 调试/测试过程。

作为一名公民开发者 或应用程序开发者，我们现在可以 在 Power Apps 中看到新创建的自定义连接器。 导航到 Power Automate 或 Power Apps。可以点击左侧导航栏中的解决方案 ，并打开用于从 Visual Studio 部署自定义连接器的解决方案，或者进入 自定义连接器 并找到我们的自定义连接器，然后点击 编辑 (铅笔图标)：

图 9.12 – 打开自定义连接器定义

我们可以看到 API 操作定义中的主机和 URL 正指向 开发隧道（dev tunnel）。

我们可以在 Power Platform 中创建 Power Apps 应用程序、流或其他任何内容，并利用自定义连接器。 只要 Visual Studio 中的开发隧道连接处于活动状态，我们的自定义连接器就能够获取我们将要调用的 API 操作的结果。 使用 pac connector list 命令，我们将能够看到所有在 Dataverse 中注册的自定义连接器及其显示名称和 ID。 例如，我们可以使用关于连接器的信息，从 PAC CLI 创建一个示例画布应用。 该应用 是基于 来自自定义连接器的 OpenAI 定义生成的： 自定义连接器示例：

 pac canvas create --msapp <new-msapp-file> --connector-id <connector-id>

使用 Azure APIM 创建 Power Platform 自定义连接器

让我们继续举例。 假设 我们的专业开发人员 正在推进他们的新 Web API。 他们正在使用 DevOps 原则来构建、测试并将 Web API 部署到测试环境中。 测试环境不同于本地开发机器，因为此环境现在已在 Azure 中进行配置。 为了托管我们的 Web API，我们可以选择 Azure 中提供的众多应用托管服务。 我们将使用 Azure 应用服务，这是一个能够托管 Web API 的 PaaS 服务。

与 DevOps 最佳实践一样，我们遵循 IaC 方法，并在 Bicep 或 ARM 模板文件中描述环境。 此 IaC 定义文件也在我们的 Azure DevOps/GitHub 仓库中进行版本控制，因此我们可以跟踪更改并对模板文件执行验证检查。 模板文件。

CI/CD 流水线确保我们的 Web API 作为构件是可部署的，并且我们将其自动部署到新配置的测试环境中。 一旦我们的 API 部署到托管平台，我们就准备好将 Web API 连接到 Azure API 管理。

Azure 服务，如 Logic Apps、App Service、Functions 和 Container Apps，提供了 Web API 与 Azure APIM 之间的无缝集成，用于在 APIM 中注册 API。 然而，Azure APIM 也提供了通过提供定义文件（如 OpenAPI、WSDL、OData 和 WADL）来添加 API 的选项。 当然，我们也可以完全从头开始，手动添加 API 的所有属性和操作。 API。

图 9.13 – 在 APIM 中创建新 API

APIM 提供了一种便捷的 配置 模拟响应的方式。这有助于加快开发进度，因为专业开发人员 可以将所有操作添加到 Azure APIM 中并模拟响应，而 Power Platform 中的应用开发人员则使用这样的 API 并在 Power Platform 中构建其余服务。 例如，公民开发人员使用已包含所有操作的自定义连接器，但响应是由 APIM 模拟的。 一旦后端 Web API 开发完成并准备好使用，专业开发人员会禁用操作上的模拟响应，将逻辑交由 Web API 执行并返回正确的响应。 另一方面，由公民开发人员开发的前端并不会看到任何差异——只有从 API 返回的数据 有所不同。

一旦我们的 API 准备好被使用，我们可以直接在 Power Platform 中从 Azure APIM 创建一个连接器：

图 9.14 – 从 Azure APIM 创建自定义连接器

当我们点击 创建连接器 按钮时，接下来的步骤要求我们提供 API 名称，该名称将用于 自定义 连接器。 我们需要选择我们正在使用的那个。 接下来，我们需要提供 Power Platform 环境和 API 显示名称，因为这将代表将部署到所选环境的自定义连接器。 一旦我们提供了这些信息，就可以通过点击 创建 按钮继续。 之后，一个新的自定义连接器将在选定的 Power Platform 环境中出现，并将准备好供任何 Power Platform 中的应用开发人员使用。

将 ALM 应用于自定义连接器

前面的示例 展示了如何通过 Visual Studio 或 Azure APIM 创建自定义连接器。 然而，如果我们希望使用 CI/CD 流水线将我们的自定义连接器部署到不同的环境，了解如何采用代码优先的方法来操作自定义连接器，并将其部署到不同的目标环境是很有帮助的。 我们将使用 Power Platform CLI 命令来实现 这些目的。

为了使用 PAC CLI 创建自定义连接器，我们需要获取 API 定义文件并生成支持的属性文件。 API 定义文件是一个 OpenAPI 2.0（Swagger）定义文件，描述了 API 及其操作。 我们可以从头开始创建 Swagger 定义文件，或者从我们在 前一个练习中创建的自定义连接器中获取它。

与 API 定义文件一起，我们还需要 API 属性文件。 API 属性文件是一个 JSON 文件，包含我们连接器的支持信息，如认证信息、品牌颜色、发布者信息等。 等等。

可选地，我们可以使用附加文件，如图标文件、脚本文件（CSX 文件）和 设置文件。

我们可以使用 pac connector init 命令从头开始创建一个自定义连接器，并附加其他参数来生成自定义连接器所需的附加文件。 接下来，我们可以看到一个示例，生成一个带有 API 密钥的 API 属性文件，用于验证针对自定义连接器的请求。 它还会生成设置文件、属性文件和脚本文件，所有这些都位于一个单独的 DemoBankAPI 文件夹中：

 pac connector init --connection-template "ApiKey" --generate-script-file --generate-settings-file --outputDirectory "DemoBankAPI"

如果我们想从之前创建的自定义连接器生成 API 定义文件，可以使用 pac connector list 命令获取当前环境中所有连接器的列表及其连接器 ID。

找到自定义连接器的连接器 ID 信息后，我们可以使用 pac connector download --connector-id <CONNECTOR-ID> 下载 apiDefinition.json 和 apiProperties.json 以供所选 自定义连接器使用。

此时，我们应该已经将文件提交到仓库，以便任何修改都能进行版本控制。 我们将对文件进行更改，以使其反映目标环境的正确值。 这意味着更改 host 值，该值是我们自定义连接器指向的端点，以及任何其他 属性值。

当我们想要在目标 环境中创建自定义连接器时，可以使用简单的 pac connector create --settings-file .\settings.json 命令，因为设置文件中已包含有关所有支持文件的信息，以及部署到目标环境的环境值。 接下来，我们可以看到一个示例 settings.json 文件：

 {
  "connectorId": null,
  "environment": "1f9283b6-deea-eed7-899c-4da273a3f957",
  "apiProperties": "apiProperties.json",
  "apiDefinition": "apiDefinition.json",
  "icon": null,
  "script": "script.csx"
}

在 settings.json 以及任何支持文件（如用于身份验证的 API 属性文件）中的值，应该进行更改和参数化，以确保文件中不会硬编码值，而是只使用变量名，这些变量在 CI/CD 流水线 中根据实际值进行更改。

另一种使用手动定义值的 create 命令变体如下：

 pac connector create --environment 1f9283b6-deea-eed7-899c-4da273a3f957 --api-definition-file .\apiDefinition.json --api-properties-file .\apiProperties.json

当我们需要更新目标环境中的自定义连接器时，我们应该使用 pac connector update --``settings-file .\settings.json。

一旦我们在目标环境中创建了自定义连接器，就可以使用它来测试现有应用程序中的操作，或者使用 pac canvas create --msapp <new-msapp-file> --connector-id <connector-id>创建一个新的虚拟应用程序。我们现在准备好 测试我们新部署的 连接器。

总结

本章介绍了采用协作、敏捷和创新方法的重要方面。 组织应该认识到，融合团队可以缩短解决业务挑战的时间，因为这些团队打破了商业用户、专业开发人员和 IT 专业人员之间的传统障碍，通过敏捷的方法 和协同效应。

组织还应该采纳来自开源开发的最佳实践，这些实践增强了组织内部应用开发者的可能性，因为我们赋予开发者发现和重用已有成果的能力。 与传统软件开发工具类似，Power Platform 提供了支持这一体验的所有工具，如目录管理器和与 Azure 的集成。

对于已经在 Azure 上注册并在该公共云上运行业务工作负载的组织来说，Azure 集成更加重要。 考虑到集成，我们调查了 Power Platform 如何与 Azure 服务进行连接的一些常见案例。

我们通过一个专业开发人员在构建 Web API 的示例结束了本章，Web API 将作为 Power Platform 服务的后端使用，并且展示了 Visual Studio 如何促进更快的开发和高效的测试体验。 当 Web API 准备就绪时，我们展示了 Azure APIM 与 Power Platform 服务之间的集成是多么快速和顺畅 。

下一章将聚焦于 Power Platform 中的专业开发人员扩展性。 我们将继续探索专业开发人员在连接器、代码组件等方面的可能性，并通过可在 DevOps 流程中重用的示例。

进一步阅读

• InnerSource 基础知识： https://resources.github.com/innersource/fundamentals/

• 在 Microsoft Fabric 中查看 Dataverse 数据： https://learn.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-view-in-fabric

• Azure 和 Power Platform 架构 示例： https://learn.microsoft.com/en-us/azure/architecture/browse/?products=power-platform

• Visual Studio 中的开发隧道： https://learn.microsoft.com/en-us/connectors/custom-connectors/port-tunneling

• 从 Azure APIM 导出 API 到 Power Platform： https://learn.microsoft.com/en-us/azure/api-management/export-api-power-platform

• 与 PAC 的自定义连接器 CLI: https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/connector

第十章：在 Power Platform 中启用专业开发人员扩展性

本章重点介绍了 Power Platform 为专业开发人员提供的能力，以扩展在 Power Platform 上构建的业务解决方案的体验。 我们将探讨 Power Platform 如何确保这些扩展选项与 ALM/DevOps 流程的顺利集成，以支持这些组件的软件开发生命周期。 这些组件。

我们将通过了解连接器开始本章内容，并继续研究自定义连接器。 在上一章中，我们展示了专业开发人员如何从 Visual Studio 构建 Web API 并直接部署到 Power Platform；在本章中，我们将探讨使用 PAC CLI 的概念，以确保我们为自定义连接器启用 ALM。 我们还将探讨自定义连接器的其他方面，如环境变量和连接引用，并解释它们在跨不同目标环境移动解决方案时的作用。 目标环境。

之后，我们将讨论 Power Apps 中的 Canvas 组件以及使用它们的主要优势。 接下来，我们将深入研究 Power Platform 的代码组件，特别是 Power Apps 组件框架。 对于 Canvas 组件和代码组件，我们将解释如何将它们包含在 ALM 流程中。

我们将在本章结束时介绍 Power Pages，专业开发人员如何通过自定义代码扩展 Power Pages，以及如何实现 ALM 流程。 实现。

我们将涵盖以下 主要主题：

• 启用集成的力量 – 连接器

• Canvas 组件概览及 组件库

• 了解 代码组件

• Power Pages 的 ALM

技术要求

要跟随本章内容，您需要 以下内容：

• Power Platform 订阅：如果您已经拥有 Microsoft Entra ID 工作帐户，您可以注册 Power Platform 开发计划（https://powerapps.microsoft.com/en-us/developerplan/），或者您可以加入 Microsoft 365 开发者 计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。

• Visual Studio Code：我们建议使用 Visual Studio Code 或带有 Power Platform Tools 扩展的 Visual Studio，或者你选择的 IDE。 可以在此找到 Visual Studio Code： https://code.visualstudio.com/。Visual Studio 也可以作为免费的 Community 版获取： https://visualstudio.microsoft.com/vs/community/。

• Power Platform CLI：我们将在命令行或终端中使用 PAC CLI。 安装指南可以在此找到 ： https://learn.microsoft.com/en-us/power-platform/developer/cli/introduction?tabs=windows。

• Azure DevOps 或 GitHub：我们可以随时创建一个 Azure DevOps 服务组织 免费 （https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates）。 我们还可以创建 GitHub 账号和公共仓库（https://github.com/signup），这对于 公共仓库 也是免费的。

• Node.js：要构建 PCF 代码组件，你需要 Node.js。 推荐使用 LTS 版本 （https://nodejs.org/en）。

• msbuild （Visual Studio 的一部分）或 dotnet build 工具（.NET SDK 的一部分： https://learn.microsoft.com/en-us/dotnet/core/sdk）。

启用集成功能——连接器

本节将深入探讨如何借助 ALM 在不同环境中复用连接器和自定义连接器。 我们将了解环境变量和连接引用的概念，这两个概念对于我们计划进行扩展时至关重要。 我们将学习如何通过解决方案将连接器封装，以便在 不同环境中进行潜在复用。

连接器

我们在 第二章中介绍了连接器。 到目前为止，我们讨论的连接器使我们能够从我们的应用程序、流程和聊天机器人中连接到不同的服务和数据源。 连接器可以是认证的，连接到第一方或第三方服务，也可以是自定义的。 认证的连接器是预构建的，不能更改，而自定义连接器则使我们可以自由创建连接到我们自己的自定义服务/API 或其他服务的连接器，即使预构建的连接器尚未存在。

连接器作为 API 操作集的包装，按触发器 或操作分类。

触发器 是 连接器中响应某个事件的操作，例如创建 SharePoint 列表项。 存在两种类型的触发器：轮询触发器 和推送触发器。 轮询 触发器 主动检查更改。 它们定期执行指定服务端点的调用，以查找新数据。 推送 触发器或 Webhook 触发器能够对外部事件做出反应。 当发生某个特定事件时，服务端点通过 回调 URL 通知触发器。

操作 是 帮助我们执行在 API 定义文件中指定的方法（检索、创建、更新和删除）的操作。 操作是在连接器连接的服务中的数据上执行的，例如从 站点获取所有 SharePoint 列表。

我们在 第九章中使用了自定义连接器。 它们使我们能够根据我们服务的 API 操作定义自己的触发器和操作。

Microsoft Power Platform 的开源存储库

Microsoft 发布了一个开源存储库，允许任何人查看现有的认证和自定义连接器，并通过向存储库提交新连接器来进行协作。 预定义连接器和带有相应定义文件的自定义连接器的列表已发布在 Microsoft 的 GitHub 存储库中，任何人都可以参与 贡献： https://github.com/microsoft/PowerPlatformConnectors/。

任何想要认证连接器的人都可以按照这里描述的逐步方法进行： https://learn.microsoft.com/en-us/connectors/custom-connectors/submit-certification。

在计划将应用程序部署到不同目标环境时，我们必须确保我们的连接器使用存在于目标环境中的连接。 为了能够通过管道自动切换到目标环境中的正确连接，我们建议使用连接引用。 现在，让我们来看看什么是连接引用以及它们如何 使用。

连接引用

当连接器在应用程序或流程中用于执行某个连接器操作时， 连接 将在特定环境中为连接器创建。 连接绑定到环境，并存储用于执行 操作的身份验证凭据。

由于连接不是解决方案感知的，并且不提供将我们的业务解决方案与连接解耦的选项， 因此引入了连接引用。

连接引用 是 指向特定连接器连接的解决方案组件。 使用连接引用使我们能够构建灵活的解决方案，允许我们在应用程序和流程中通过编程方式更改连接信息。 这简化了使用 DevOps 方法将解决方案部署到不同目标环境时的工作，因为它允许我们连接到与 目标环境相关的资源。

让我们探索另一种参数化解决方案配置的方法： 环境变量。

环境变量

环境变量充当 解决方案组件的配置参数，允许我们动态更改特定于目标环境的配置值。 环境变量在传统应用程序开发中非常常见，开发人员使用它们将配置与应用程序解耦。 这使开发人员可以在不更改应用程序代码的情况下，使应用程序适应目标环境。 在 Power Platform 中，我们遵循相同的概念，通过仅更改环境变量来在不同目标环境中使用应用程序组件。 这样，我们可以连接到特定于 目标环境的数据源或一组 API。

环境变量通常以键值对的格式存储，值存储在应用程序源代码之外的安全位置，如 Azure 应用配置 或 Azure 密钥保管库，以防止值被轻易访问。 在应用程序 运行时或 CI/CD 流水线执行过程中，这些值会从这些服务中检索并 按需使用。

使用这种方法使我们能够实现 DevOps 最佳实践之一：尽可能参数化，以增强应用程序的灵活性。 在应用程序源代码中硬编码值不仅可能导致维护问题，还可能带来潜在的 安全漏洞。

总之，使用环境变量的一些 好处包括 以下几点：

• 我们可以将应用程序与配置解耦，从而轻松更改数据源和其他机密的配置值。 例如，我们可以在将应用程序部署到不同的 目标环境时，改变与数据源的连接，例如 API 密钥和服务器 URL。

• 我们可以在其他解决方案组件之间复用环境变量。 例如，我们可以创建一个环境变量，在 Power Automate 和 Power Apps 中都使用，从而 简化配置。

• 通过将机密与解决方案组件分离并 将其存储在密钥保管库中，我们可以提高安全性，减少 滥用的风险。

当我们将环境变量添加到解决方案时，Power Platform 会自动在两个 Dataverse 表中创建条目： 环境变量值 和 环境变量定义。要在 Power Apps 应用程序中使用环境变量，我们应该使用查找函数来查询这两个表，并根据我们创建的环境变量名称获取值，如在 引入功能标志 练习中所示 第八章。在 Power Automate 中，我们可以通过使用动态 内容选择器来访问环境变量。

为了更好地理解如何简化此操作并遵循 DevOps 最佳实践，我们将通过 一个示例来进一步了解这种方法。

示例 - 将配置与应用程序解耦

在这个例子中，我们将 利用连接引用和环境变量来将配置从我们的 业务解决方案中解耦。

首先，我们需要创建一个解决方案并添加所有属于我们业务解决方案的组件，包括新的环境变量和连接引用。 然后，我们将创建一个部署设置文件，该文件将把配置设置与实际应用程序解耦。 这将使我们能够配置特定于目标环境的值。 我们将使用部署设置文件将解决方案导入到目标环境中，并带有相关的 配置值。

准备解决方案

让我们来探索准备解决方案与 配置设置的第一步：

1. 在 Power Apps（https://make.powerapps.com）或 Power Automate（https://make.powerautomate.com）主页上，我们可以在左侧导航栏中找到 解决方案 选项。 选择该选项将打开一个屏幕，显示当前环境中所有解决方案的列表。

2. 我们可以点击 pac solution init 和 pac solution import 命令。

3. 当我们进入解决方案对象资源管理器时，我们可以通过点击 新建 | 更多 | 连接引用来添加新的连接引用。

   要添加一个 现有的连接引用，我们点击 添加现有 | 更多 | 连接引用，选择现有的连接引用，然后点击 下一步，正如我们在 图 10**.1. 中看到的。 这将把任何现有的组件添加到 解决方案中：

图 10.1 – 在解决方案对象资源管理器中添加组件

1. 每当我们创建新的连接引用时， 新建连接引用 屏幕将会打开，正如在 图 10**.2中所见。

   在这里，我们必须提供 显示名称， 名称， 连接器 的值，以及 连接 值用于所选连接器。 提供描述是可选的，但建议提供，以便更好地理解 连接引用的用途：

   • 如果在环境中没有所选连接器的连接，我们需要通过选择 + 新建连接来创建一个新连接，这将打开一个新连接屏幕，弹出框中显示我们所选的连接器。 我们需要提供所有必需的连接参数，并点击 创建 来创建 一个连接。

2. 返回 到之前的 新建连接引用 屏幕，我们现在可以点击 刷新 按钮，位于连接下拉列表旁边，如 图 10**.2所示，这将更新连接列表并显示新创建的连接。 我们可以选择它并点击 创建，这将在 我们的 解决方案中创建一个新组件。

图 10.2 – 创建新的连接引用

1. 要添加一个 环境变量，我们遵循类似于 步骤 3中提到的步骤。这次，我们选择 新建 | 更多 | 环境变量。

2. 将出现一个新屏幕，我们需要提供更多关于环境变量的信息，例如 显示名称， 名称， 描述，以及 数据类型：

   • 数据类型 指定了我们环境变量的类型。 这可以是 十进制数， 是/否， 文本， 数据源， 机密，等等。 选择数据类型后，我们可以配置默认值和当前值，如在 图 10.3中所示。如果我们正在创建一个类型为 数据源的环境变量，我们可以选择 连接器**。

图 10.3 – 添加新环境变量

• 默认值 不是必填项；然而，当没有 当前值 设置时，它是会被使用的。 当前值 会覆盖 默认值 ，并且在部署到不同的 目标环境时非常有用。

一旦我们按需要配置好环境变量后，可以点击 保存 来存储配置，这将会将一个新组件添加到 我们的解决方案中。

如果我们需要将现有的环境变量添加到我们的解决方案中，可以通过点击 添加现有| 更多 | 环境变量 在解决方案对象资源管理器中，选择列表中的现有变量，然后点击 下一步。接下来的页面会显示我们选择的环境变量，对于每个变量，我们可以选择 包含定义 和 包含当前值 复选框。 我们可以审查已选择的现有 环境变量，并点击 添加 将其添加到 我们的解决方案中。

环境变量的当前限制

在使用环境变量时仍然存在一些限制；例如，目前无法使用 Microsoft Power Platform Build Tools 管理数据源环境变量。 请确保查看限制并相应地使用环境变量。 有关限制的更新信息，请参考 这里： https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables。

现在我们已经准备好了解决方案，可以将其部署到不同的环境中。 手动导入解决方案时，导入过程会检查环境中是否已经存在定义的连接引用。 如果存在，导入过程将其与该连接关联；如果不存在，它将提供自动创建并关联连接的机会。 一旦连接配置完成，下一步将允许我们使用目标环境的实际值更新环境变量。

为了将设置解耦并允许我们的解决方案以更具程序化的方式导入，我们将查看如何生成并使用部署设置文件。 和使用。

构建部署设置文件

一个 部署设置文件 是一个 存储关于连接引用和我们解决方案中使用的环境变量信息的 JSON 格式文件。 同一个文件将在使用 Power Platform Build Tools 或 PAC CLI 进行解决方案导入时使用。 我们在 第八章中简要提到过它：

1. 我们应该导出我们的解决方案或克隆它。 我们需要 拥有一个解决方案 ZIP 文件或一个未打包的解决方案文件夹，我们可以通过它来生成设置文件。 我们可以通过 两种方式来实现：

   • 选择解决方案，点击 pac solution clone --name <solution-name> 或 pac solution export --name <name>，这意味着解决方案文件夹将被本地克隆，或解决方案 ZIP 文件将被 本地下载

2. 现在我们 已经导出了解决方案包 文件，我们准备好按照以下方法创建部署设置文件。

   生成部署设置文件可以使用以下 PAC CLI 命令：

    pac solution create-settings --solution-zip <solution-file.zip> --solution-folder <unpacked-solution-folder> --settings-file <JSON-file-name>
   deploymentSettings.json file in the current folder.
   

   下面是 deploymentSettings.json 文件结构的示例，位于本书 GitHub 仓库的 第十章 文件夹中。 在该文件中，我们可以看到环境变量和连接引用的结构，并包含相应的值。

   文件中的每个环境变量都有一个 Value 属性。 初始时，它是一个空字符串，我们将其更新为目标环境的值。 对连接引用也应进行相同的操作，其中 ConnectionId 属性最初为空，需要 提供。

   要更新连接引用值，我们可以使用 PAC CLI 连接到目标环境并列出所有连接。 这将使我们看到给定连接器的连接是否已存在于目标环境中。 当我们将 PAC CLI 指向目标环境时，可以使用 pac connection list 命令列出在选定环境中建立的所有连接。 如果连接已存在，请将该连接的 Id 值复制到部署设置文件中的正确连接引用 ConnectionId 值下，如 第八章 所示；否则，创建一个新的连接。

3. 现在我们已经为解决方案准备了部署设置文件，可以继续进行解决方案导入过程，包括指定的部署设置文件。 如果命令中未提供环境值或路径，将使用当前环境和当前文件夹结构进行 解决方案 导入：

    pac solution import --path <path_to_zip_file> --settings-file .\deploymentSettings.json
   

上述方法提供了一种编程方式来生成部署设置文件、编辑它并将解决方案导入目标环境。 为了遵循 DevOps 方法，我们可以在流水线中使用额外任务来管理部署设置文件并部署到 目标环境。

部署设置文件和 DevOps 方法

在 第八章中，我们看到如何在 DevOps 中使用部署设置文件。 为了保持自动化，我们可以在管道中添加一个额外的任务，该任务将创建一个部署设置文件并将其存储在与我们导出解决方案相同的仓库中。 我们可以使用 PAC CLI 来实现。 我们必须确保在导出管道中使用 Power Platform Tool Installer 任务时，将 PAC CLI 添加到 PATH 环境变量中。 以下示例演示了如何在 Azure DevOps 中完成这项操作：

 - task: PowerPlatformToolInstaller@2
  inputs:
    DefaultVersion: true
    AddToolsToPath: true

为了生成部署设置文件，我们将使用一个 命令行 任务，使用我们现在 已经熟悉的命令：

 - task: CmdLine@2
  inputs:
    script: |
      echo 'Create Deployment Settings File'
      pac solution create-settings --solution-zip '$(Build.ArtifactStagingDirectory)/$(SolutionName).zip' --settings-file '$(SolutionName).json'

我们在导出管道中使用的 git commit 命令 将确保这个新的部署设置文件会被添加到我们的仓库中。 如果我们在导出管道中创建一个制品，我们应该确保使用管道中的 复制文件 任务将部署设置文件添加到制品中。

现在我们已经在仓库中有了部署设置文件，接下来就是更新文件中的值。 由于我们不希望在源代码中保留任何敏感信息，而这些值可能是可读的，我们建议将环境变量和连接参考的连接 ID 的值参数化。 例如，在部署设置文件中，我们可以将环境变量的值写成如下形式： „Value": „#{ENV_NAME}#"，连接参考的连接 ID 值则可以写成如下形式： „ConnectionId": „#{CONN_O365OUTLOOK}#。类似的方法在 第八章中有展示。

作为我们 部署管道的一部分，在将解决方案导入到环境中的过程中，我们可以更新这些值以确保其正确。 我们可以使用 DevOps 管道中的一个任务/操作，搜索具有正确前缀和后缀的令牌，在我们的案例中是 #{ … }#，并用存储在 DevOps 工具或安全密钥库中的实际值替换这些令牌。 例如，在 Azure DevOps 和 GitHub 中，我们可以通过一个 替换 令牌 任务/操作来实现这一点。

一旦在部署管道中将令牌替换为实际值，下一步是使用 Power Platform 导入解决方案 任务导入解决方案，该任务是 Power Platform 构建工具的一部分。 这 使我们能够在导入解决方案时引用部署设置文件。 在这里，我们可以看到一个这样的任务在 Azure DevOps 管道中的示例：

 - task: PowerPlatformImportSolution@2
  inputs:
    authenticationType: 'PowerPlatformSPN'
    PowerPlatformSPN: '<PP-SPN>'
    SolutionInputFile: '$(Build.ArtifactStagingDirectory)/$(SolutionName).zip'
    UseDeploymentSettingsFile: true
    DeploymentSettingsFile: '$(SolutionName).json'
    AsyncOperation: true
    MaxAsyncWaitTime: '60'

现在，我们更清楚地了解了我们的解决方案如何拥有配置设置文件，使其能够在不同的环境中重用，这也将帮助我们构建其他组件，如画布组件和代码组件。 我们将从画布组件和 组件库开始。

画布组件和组件库概述

在 Power Apps 中开发应用时，应用开发者使用各种控件来构建应用的基础模块。 为了避免重复，并构建可重用的应用部件，这些部件可以在同一个应用或多个应用中使用，开发者应考虑使用画布组件。 本节介绍了画布组件以及组件库，并帮助你理解它们之间的区别以及它们如何融入 ALM 过程。

画布组件

画布组件 作为 独立的模块化构建块，封装了特定的功能或用户界面元素。 画布组件可以在 Power Apps 画布应用和基于模型的应用中重用。 这些组件不仅在创建更大、更复杂的企业级应用时起着至关重要的作用，而且在多人协作开发环境中也非常重要，因为开发人员可以分配任务，并在构建业务解决方案时专注于每个单独的组件。 创建画布组件的另一个好处是，它们可以在一个地方集中更新，所有更新都会在应用中的所有实例中反映出来。 该应用。

创建画布 组件是在 Power Apps Studio 中构建画布应用程序时完成的。 在左侧导航栏中，点击 树视图，我们可以看到应用程序中所有的屏幕和组件。 点击 组件 可以查看所有现有的组件，并通过点击 新建组件来创建新的组件。这会创建一个空白的画布组件，我们可以 添加控件：

图 10.4 – 在 Power Apps 中创建画布组件

每个组件都可以拥有自定义属性。 自定义属性允许组件接收应用程序传递的值（称为输入属性），或者将数据或状态从组件发送到应用程序（称为输出属性）。 无论属性类型是输入还是输出，自定义属性都可以保存任何数据类型的数据，涵盖从传统的数据类型，如文本和数字，到更符合 Power Apps 特性的类型，如屏幕、颜色和表格。 使用自定义属性可以在组件与应用程序主机之间共享信息。 在画布组件层级还有一个设置， 访问应用程序范围，可以在组件的属性中找到。 它可以打开或关闭，以允许访问应用程序内更广泛的信息 ，例如全局变量、集合和应用程序中的控件。 这仅适用于应用程序内的画布组件，而不适用于组件库中的组件。 我们可以关闭此设置，并通过 自定义属性 将信息传递给组件。

组件库

由于画布组件只能在一个应用程序内使用，为了在环境中跨应用程序重用组件，我们可以创建组件库。 一个 组件库 作为组件定义的存储库。 这使得应用程序可以管理其所依赖的组件，这意味着每当组件更新可用时，应用程序开发者将被通知。 可用更新的信息会在 Power Apps Studio 中编辑应用程序时显示，或者通过手动点击刷新按钮来检查组件 库更新。

创建组件库与创建 画布组件不同：

1. 可以通过导航到 Power Apps 主屏幕并从左侧导航面板中选择 组件库 来找到组件库。 如果在左侧导航面板中看不到此选项，请点击 更多 | 查看全部，在这里可以找到 应用增强：

图 10.5 – 访问组件库

1. 一旦我们在 组件库屏幕上，我们可以点击 + 新建组件库 来创建一个空白的画布，用于添加 应用程序组件。

2. 在这里，我们可以按照与常规画布组件相同的过程导入现有组件或创建新组件。 在组件库中创建或导入的每个组件都允许制作者在目标环境中进行自定义。 允许自定义 是 Power Apps Studio 内部组件的属性。 如果允许自定义，则一旦应用制作者开始在应用程序中对组件进行更改，这将打破对组件库的引用并创建组件的本地副本。 为了保持对组件的控制并仅允许从组件库内部进行组件更改，关闭此组件设置是 一个良好的实践。

3. 一旦所有组件添加到组件库中，我们需要发布这些更改。 发布过程与任何其他画布组件或画布应用相同。 如果组件库没有发布，则无法 重复使用。

4. 发布后，我们可以在应用程序中重新使用库中的组件。 为此，我们在 Power Apps Studio 中打开我们的画布应用，在左侧导航面板中点击 插入，这将打开添加控件的选项 和组件。

   我们点击代表目录搜索的图标，这将打开一个 导入组件 屏幕。 在这里，我们可以找到我们的组件库以及库中的所有组件。 我们可以选择需要的组件然后 点击 导入：

图 10.6 – 从组件库导入组件

1. 组件库中的组件将出现在左侧导航面板的 插入 选项下。 我们可以在 库组件 组中找到它们，位于 自定义 类别下方，该类别包含本地创建的画布组件，如 下图所示：

图 10.7 – 从添加的组件库中访问组件

现在我们已经学习了如何构建画布组件和组件库，这些组件库支持在环境中跨画布应用程序的组件可重用性，让我们来探讨如何管理组件库的 生命周期。

管理组件库的生命周期

正如我们之前所看到的， 为了在多个应用程序之间重用组件，它们需要被添加到组件库中。 一旦添加到库中，它们就可以被插入到应用程序中。 这样，应用程序就会创建一个来自组件库的选定组件的依赖关系，并简化我们的 解决方案管理。

为了将带有组件依赖关系的应用程序部署到不同的环境中，我们必须确保在部署应用程序之前，目标环境中存在该组件库。 否则，导入解决方案的过程将无法成功。 我们需要确保组件库要么与应用程序一起打包在解决方案中，要么在部署带有 组件依赖关系 的应用程序之前，将其移至目标环境的单独解决方案中。

我们可以通过导航到 解决方案，选择我们的解决方案，点击 对象，点击应用程序名称旁边的三个点，点击 高级，然后点击 显示依赖关系，如 图 10.8所示：

图 10.8 – 检查应用程序的依赖关系

在这里我们会找到一个标签 叫做 使用，它显示了哪些对象正在被我们的应用程序使用。 选择组件库名称旁边的三个点将会引导我们到 默认解决方案。需要注意的是，组件库会被放置在环境中的默认解决方案中。 当我们迁移到目标环境时，只要该环境已启用 Dataverse，情况将保持不变。

将组件库添加到包含我们应用程序的解决方案中，可以通过进入我们的解决方案，点击 对象，然后创建一个新的组件库或添加一个现有的组件库。 创建新组件库的方法是点击 新建 | 更多 | 组件库。添加现有组件库的方法是通过 添加现有 | 更多 | 组件库。将组件库添加到解决方案后，我们可以启用/禁用允许在目标环境中进行自定义的选项。 该设置可以在解决方案资源管理器中找到。 我们选择组件库，点击其名称旁边的三个点，然后点击 高级 | 托管属性。这将打开一个编辑组件库托管属性的界面。 在这里，我们可以切换启用或禁用允许在 目标环境中进行自定义的选项：

图 10.9 – 在目标环境中启用/禁用自定义

一旦我们将包含所有组件的组件库添加到解决方案中，就可以按照我们已经熟悉的 ALM 流程进行操作：通过导出管道从 Power Apps 导出解决方案，然后通过导入管道将其导入目标环境，并在中间执行所有其他相关步骤 用于测试。

如果我们希望 单独更新组件库，而不是与应用程序一起更新，那么拥有一个专门用于更新组件库的管道过程是有意义的。 我们可以创建一个单独的解决方案，并添加一个或多个我们希望单独管理其应用生命周期的组件库。 我们需要记住，组件库必须在导入引用该组件库的解决方案之前部署到目标环境。 一旦组件更新，应用程序创建者将通过组件更新过程（自动或主动）收到更新通知。

现在我们已经学习了画布组件及其可重用性，接下来我们将进一步探讨在 代码组件中可以进行哪些额外的自定义。

了解代码组件

在专业开发者可扩展性的基础上再进一步， Power Apps 组件框架 (PCF) 使得专业开发者可以创建代码组件，在内置组件的外观和体验不足时，提升用户体验。 PCF 是一个非常庞大的话题，足以在本书中单独开设一章。 在本节中，我们将尽量为你提供对 PCF 的初步理解，了解 PAC CLI 如何帮助我们构建代码组件，以及如何使用 DevOps 工具执行 ALM。

PCF 是一个统一的框架，允许开发人员构建可在 Power Apps 和 Power Pages 网站中跨应用重用的自定义代码组件。 这为组织提供了一个绝佳的机会，可以构建代码组件，并在业务解决方案中加以利用。 通过使用 PCF，我们可以开发代码组件，这些组件不仅包含关于组件外观的信息，还包括业务逻辑。 这使得我们能够让应用程序和网站在视觉上更具吸引力，并且根据业务需求进行定制。 PCF 是 HTML Web 资源的继任者，HTML Web 资源曾用于在 PCF 之前，在模型驱动应用中渲染自定义 UI 组件。 与 HTML Web 资源相比，PCF 在性能方面得到了更多的优化，使其更适用于复杂的 业务解决方案。

模型驱动应用中的自定义页面

自定义页面 是模型驱动应用中的一种灵活而强大的页面类型，允许我们将构建画布应用的体验带入模型驱动应用。 我们可以向自定义页面中添加画布和代码组件，这些组件可以作为主页面、中心对话框屏幕或侧边对话框视图显示在模型驱动应用中。 这为我们构建业务应用的体验提供了极大的灵活性。

目前，我们知道有两种类型的 PCF 组件： 标准 和 虚拟。这两种组件都利用了 HTML、CSS 和 TypeScript。 然而，虚拟组件使用了两个平台提供的库，React 和 Fluent UI。 它们被添加到父虚拟 文档对象模型 (DOM)，这意味着不需要为每个组件单独实例化一个 React 虚拟 DOM。 尽管 React 和 Fluent UI 可以与标准 PCF 组件一起使用，但这样做需要开发者将库单独打包到组件中。 对于虚拟组件，我们能够使用平台提供的库，这使得我们可以在使用这些代码组件时提升应用的性能。 需要注意的是，即使我们开始时使用标准代码组件，后续也可以将其转换为 虚拟组件。

根据组件的使用方式，我们可以区分两种类型的 PCF 组件：

• 字段，在这里，代码组件可以绑定到 表单中的字段

• 数据集，它是一个绑定到视图、数据集或画布应用中的集合的代码组件，可以与来自 数据集 的数据行一起工作

使用这两种类型的 PCF 组件，开发人员可以在数据集和仪表板上构建自定义字段、列和视图，进而替换我们业务应用中的内建组件。

PCF 的社区资源

对于那些愿意学习 更多关于 PCF 的内容，并希望查看更广泛社区使用 PCF 开发的一些示例，微软提供了一系列链接（视频、博客和代码组件库），可以用于此目的。 欲了解更多信息，请访问 ： https://learn.microsoft.com/en-us/power-apps/developer/component-framework/community-resources。

代码组件的组成

无论我们决定构建哪种控制类型或组件类型，代码组件由三个主要元素组成——清单文件、组件实现和 资源文件。

清单文件

控制清单 是一个用于注册和管理代码组件的 XML 文件。 清单文件的 名称 是 ControlManifest.Input.xml。

它包含了关于代码组件的所有信息，例如 以下内容：

• 组件 元数据

• 关于控制类型的信息（标准 或虚拟）

• 是否将使用任何外部服务（这将需要 高级许可）

• 可用的属性 供使用

• 已使用的资源

• 其他 元数据和 配置信息

代码组件中可用的属性可以手动输入或动态设置为来自 应用程序中其他组件的值或数据。

组件实现

代码组件的逻辑在一个名为 index.ts的文件中实现。在这里，我们可以放置定义代码组件行为的代码。 这是我们可以找到控制代码组件生命周期方法的地方。 代码组件。

代码组件的生命周期可以分为四个 主要方法：

• init：此方法用于初始化组件实例。 此功能不仅配置组件，还可以注册任何事件监听器或添加其他功能，以确保组件正确运行。 此方法需要在代码 实现文件中实现。

• updateView：当组件的属性或组件元数据中的任何值发生变化时，会调用此方法。 它用于反映组件 UI 中的变化。 此方法需要在代码 实现文件中实现。

• 资源文件

• getOutputs：此方法在组件接收新数据之前调用。 此方法在代码 实现文件中是可选的。

前提条件

在清单文件中，定义代码组件的节点之一是 resources。该节点包含关于代码资源的信息，也就是我们的 index.ts 文件，其中包含代码逻辑。 在 代码 资源旁边，我们有静态文件，定义了代码组件的视觉外观。 这里我们可以找到一个 层叠样式表 (CSS) 文件 ，其中包含控制组件视觉表现的代码。

由于代码组件可以在不同的应用和环境中重用，因此支持本地化非常有利，因为它允许我们在有其他语言需求的应用之间共享组件。 PCF 支持本地化。 本地化字符串可以存储在 RESX Web 资源文件中，并在清单文件中注册。 其他文件，如图像、图标或任何其他需要的文件，都可以添加。 文件通常存储在一个单独的文件夹结构中，注册在清单文件中，并在 代码逻辑中引用。

现在我们已经了解了代码组件的文件结构，接下来让我们创建一个简单的 代码组件。

创建代码组件

在这个练习中，我们将创建一个 虚拟（React）控件类型，因为这是未来推荐的控件类型。

destroy：当组件从 DOM 树中移除时，会调用此方法。 它应被用于执行任何清理操作，并释放组件所使用的任何内存。 此方法需要在代码 实现文件中实现。

为了构建代码 组件，我们需要安装在 技术 要求 部分中提到的工具。

要获取 .NET 构建工具，应安装 Visual Studio 2019 或更高版本（Visual Studio 2022）。 我们可以选择仅在安装向导中选择 .NET 构建工具作为工作负载，而不是安装完整的 Visual Studio。 另一种选择是安装 .NET 8.0 SDK。 目前，.NET 8.0 是最新的长期 支持版本。

初始化项目

首先，我们需要初始化 项目。 为此，我们将使用 PAC CLI 以及其特定于 PCF 的命令集。 我们可以使用以下命令来实现这一点：

 pac pcf init --name <COMPONENT_NAME> --namespace <COMPONENT_NAMESPACE> --template <COMPONENT_TYPE> --framework <RENDERING_FRAMEWORK> -npm

有两个参数非常突出— template 和 framework。现在， template 描述我们是否会创建一个用于字段或数据集的代码组件。 framework 定义了我们将使用的框架。 如果使用 React，那么它将标记为虚拟控制类型；否则，它将是标准控制类型。 如果我们没有在命令中提供 --run-npm-install 或 --npm 开关，我们将需要单独运行 npm install 命令，以安装 项目依赖。

在我们的示例中，我们使用了 以下命令来初始化一个包含一些 支持文件的文件夹结构的项目：

 pac pcf init --name SimpleReactPCF --namespace SimpleReactNS --template field --framework react -npm

以下是 文件夹结构：

图 10.10 – PCF 初始化项目的文件夹结构

现在，我们已经初始化了项目，并且有了文件和文件夹结构，接下来可以开始实现 代码逻辑。

实现代码组件

正如我们在 代码组件的文件夹结构中看到的那样，我们的清单文件也存在于 PCF 项目中。

在 ControlManifest.Input.xml 文件中，我们可以看到 control 元素，其中包括关于我们的代码组件的信息，包括控制类型设置为 virtual：

 <control namespace="SimpleReactNS" constructor="SimpleReactPCF" version="0.0.1" display-name-key="SimpleReactPCF" description-key="SimpleReactPCF description" property node, where we can have multiple properties for our code components.
			We will change the property from `SingleLine.Text` to a number (`Whole.None`) by changing the highlighted property:

			During this step, extensive coding may be done to develop the PCF component. Making changes to the code of the component requires knowledge of TypeScript and React.
			Debugging a developed code component
			With a simple `npm start watch` command, we can run the project in debugging mode, which opens a browser with our local PCF test environment. On the right side of the test application, we can see all the configured data properties that are specified in the manifest file, as shown in *Figure 10**.11*. Here we can adjust the values of the properties and check whether the state of the code component reflects the desired behavior.
			Additionally, we can use the test environment to understand how our code component adjusts to different screen sizes. We can use the **Form Factor** settings as well as **Component Container Width** and **Component Container Height** to adjust the screen size:
			![Figure 10.11 – The PCF test environment](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_11.jpg)

			Figure 10.11 – The PCF test environment
			Packaging the code component
			Code components can be added to solutions to enable reusability across environments. If we already have solutions available, we can simply upload the code component to the solution using the `pac pcf push` command, as shown in the next section. In other cases, we can utilize a set of commands to first create a solution and then add a reference to that solution.
			We will be adding a reference for our code component project to a newly created solution project. The solution project (`cdsproj`) can contain multiple code component references, while the code component project can only contain a single code component. Adding references to multiple code components within a single solution project allows us to reference all the code components required for a particular business solution. They can also be packaged together with other solution objects if needed.
			First, we will initialize a solution using the following command:

pac solution init

			Then we will add a reference to the code component project:

pac solution add-reference --path <LOCATION_TO_PCFPROJ_FILE>

			This will create a reference inside the `.cdsproj` file, like this:

<ProjectReference Include="..\SamPCF\SamPCF.pcfproj" />

			When we are ready to generate a ZIP file from the solution project, we can use the following:

dotnet build /t:build /restore

			This will restore all code component projects that are referenced in the solution project and build the project. The final outcome of the process is a ZIP package artifact that can be imported with the code components solutions. Such a solution can now be imported into the downstream environment.
			If we have a business application in another solution that is referencing our code components, we need to make sure that the solution with the code components is deployed to the environment first, before importing the business application that references them.
			Importing the solution into Power Platform
			Importing the solution into Power Platform (Dataverse) can be done manually using the Power Platform web portal or the `pac pcf push` command. It can also be done automatically using Power Platform Build Tools and the DevOps tool of choice. In the next section, we will take a look at how this can be done automatically. In this section, we will complete the process manually.
			First, we should make sure that we are in the right Dataverse environment. To select the right environment, we can proceed with `pac env list` and `pac env select -env <ENVIRONMENT_ID>`. After confirming the environment, we can proceed with the `push` command.
			It is worth noting that the `pac pcf push` command also has a `-env` setting, which allows us to push to a selected environment if we are operating across multiple environments.
			As we are still in the folder of our code component, we can run the command, in which we can either use a publisher prefix from our environment or the unique name of our solution. In both cases, the PAC CLI will check whether the publisher or solution already exists. If it does, it will use it to push the component – here is one option:

pac pcf push –solution-unique-name <SOLUTION_NAME>

			Here is the other:

pac pcf push -pp <PUBLISHER_PREFIX>

			Without the name of the solution, this code component will be imported to a temporary `PowerAppsTools_<prefix>` solution.
			Preparing the component for release
			When preparing our code component for release to the production environment, we should add the `<PcfBuildMode>production</PcfBuildMode>` property inside the `pcfproj` file underneath `OutputPath`, as in the following example:

<Name>PCF</Name>

<ProjectGuid>e71d2e10-908c-4123-9f29-3283cbd224ab</ProjectGuid>

<OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>

<PcfBuildMode>production</PcfBuildMode>

			Development mode produces a larger bundle that holds debugging information, which might impact performance in production. This is why the change should be made to the `pcfproj` file before building and deploying to production.
			Additionally, when preparing the solution project, `SolutionPackagerType`, which is part of `PropertyGroup` in the `cdsproj` file, defines the solution type, stating whether we would like to go for managed, unmanaged, or both solution types:

<SolutionPackageType>Managed</SolutionPackageType>

			When running the `dotnet build` command, this information will be taken to generate a ZIP file of the defined solution type. When we are preparing for release to production, we can use `dotnet build /p:configuration=Release` to create a release build for the selected solution type.
			Adding code components to applications
			Code components can be used across canvas applications, model-driven apps, and websites. The following are some examples of adding components to apps.
			Model-driven apps
			Adding components to model-driven apps is very easy:

				1.  When editing the form, click on **Components** in the left navigation bar and click **Get** **more components**.
				2.  This will open a **Get more components** sidebar, where newly created code components will appear. Select the necessary components and click **Add**, as can be seen in *Figure 10**.12*:

			![Figure 10.12 – Adding code component to a form in a model-driven app](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_12.jpg)

			Figure 10.12 – Adding code component to a form in a model-driven app

				1.  After adding the code components to the list of components, they appear under the **More components** group inside the **Components** option. Simply drag and drop the components to the right places in the form and connect the component values with the correct values.

			Canvas apps
			Adding code components to canvas applications has to be enabled before it’s possible. The setting for enabling it is currently available in the Power Platform admin center:

				1.  Go to **Environments**, select the environment, and then click **Settings** | **Product** | **Features**.
				2.  Here we will find the **Power Apps component framework for canvas apps** setting, which is turned off by default. If needed, enable it.
				3.  Once done, we can go to our canvas application and click **Insert** to see a list of all controls. Then we can proceed to the **Code** tab, select the components, and click **Import**, as shown in *Figure 10**.13*.

			![Figure 10.13 – Adding a code component to the canvas app](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_13.jpg)

			Figure 10.13 – Adding a code component to the canvas app
			Power Pages
			Adding code components to Power Pages is similar to the process of doing so for model-driven apps:

				1.  Your components can be found by going to **Data** in the left navigation bar.
				2.  Select the table of choice, click **Forms** (or **Views**, depending on the use case), and click **Get** **more components**.

			![Figure 10.14 – Adding code components in Power Pages](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_14.jpg)

			Figure 10.14 – Adding code components in Power Pages

				1.  This will open a sidebar to help you find a custom code component. Select the one you require and click **Add**, as can be seen in *Figure 10**.14.*

			Now that we have learned how code components are created and added to an application, let’s understand how the application life cycle is managed for these components.
			ALM for code components
			As we saw in the previous section, the development life cycle of a code component consists of the following steps:

				1.  The initialization of the PCF project
				2.  Working on the code component’s implementation
				3.  Testing/local debugging of the developed code component and pushing it to the Power Platform development environment
				4.  Adding the component project reference to the solution in the development environment
				5.  Testing the business solution with the included code components
				6.  Preparing the code component for release
				7.  Importing the solution to other environments and testing

			We recommend building automated pipelines by leveraging Power Platform Build Tools in Azure DevOps or GitHub, together with the PAC CLI, to perform these tasks automatically.
			As with any other development project, when developing code components, it is also recommended that developers use a source code repository, such as GitHub or Azure DevOps, from the beginning, in which to collaborate. Using `pac pcf init` also creates a `.gitignore` file, which instructs the version control system as to which files and folders should be left out since they will be either created or restored during the build process.
			It is worth noting that when we have a code component in a solution, we can export the solution together with the code component using Power Platform Build Tools or `SolutionPackager /action: Extract`, which incrementally exports changes to the solution metadata. When a code component is extracted from a solution package, a `Controls` subfolder will be created for each code component that is included in the solution.
			Using `pac pcf push` to push a code component to an environment, and then using commands such as `msbuild` and `SolutionPackage /action: Pack` to build a solution, allows us to build and repack the solution and make it ready for import.
			Solution strategy for code components
			Another consideration with code components is the solution strategy. As we have learned, our business applications can have dependencies on various solution components. Power Platform allows us to deploy components together, as part of a **single solution**, or separately, in **segmented solutions**, where functionalities of our business applications are split between multiple solutions.
			The segmented approach allows us to be more agile with the development approach of our business solution. Teams can each focus on their own parts of the business solution and can develop and test independently of the final solution. Such an approach allows us to decouple and share code components between multiple applications and across environments. Single solutions have everything in one solution, which means that it is important to follow a good branching strategy if you want to have control over updates to the complete solution.
			Versioning and updates to code components
			Whenever we deliver changes to our code components that should be pushed to our business applications, we should make sure that we follow the standard versioning strategy (`MAJOR.MINOR.PATCH`), which will ensure that Power Apps applications detect and update dependencies to the latest version.
			Inside the manifest file (`ControlManifest.Input.Xml`), under the `control` element, there is a `version` property that should get at least a `PATCH` version increase whenever an update to a code component is deployed. This will ensure that the change can be detected and that both canvas and model-driven apps will receive the latest version of the component:

			An increase of the version can be done manually by changing the number in the manifest file, or it can be done automatically with the following command:

pac pcf version --strategy manifest

			There are also other strategies, such as `gittags`; however, the manifest strategy is by far the simplest, since it does everything automatically.
			If we would like to specify the exact value of a version, we can do the following:

pac pcf version --patchversion

			`MAJOR` and `MINOR` versions should be aligned with the version of our Dataverse solution. If a significant change is made to a solution, then the `MAJOR` and/or `MINOR` version of the Dataverse solution should be incremented, which should lead also to incrementing the `MAJOR` and/or `MINOR` version of the code component.
			Code component updates for canvas apps
			In order to update a code component to a newer version inside canvas applications, app makers must open the canvas app in Power Apps Studio and click **Update** on the **Update code components** popup. If the update is not done, then the canvas app will continue to use the old version of the code component.
			Automated build pipelines for segmented solutions
			To create a code component from scratch and keep control over it, we start by creating the code component locally and committing the changes to the Git repository:

				1.  Using the `pac pcf init` command, we will create a `pcfproj` folder. Once the project is created, we will be committing the changes to the Git repository. Using `pac pcf push`, we will deploy our code component to the environment.
				2.  Separately, we will be creating a solution project using `pac solution init`, to create a new blank solution, or `pac solution clone`, if we already have a solution that we would like to reuse. The solution is also version-controlled in the Git repository.
				3.  Next, we need to add a reference to the solution using the `pac solution add-reference` command with the path to our PCF component project.
				4.  Now we need to update the solution version in `Solution.xml` to reflect the version of the current build. This can be done by formulating the `MAJOR.MINOR.BUILD.REVISION` version with the variables in Azure DevOps/GitHub. For `MAJOR`, we can create `$(majorVersion)` variables; for `MINOR`, we can create `$(minorVersion)` variables; for `BUILD`, we can use the predefined `$(Build.BuildId)`; and for `REVISION`, we can use `$(Rev:r)`.
				5.  We will also need to change the version value inside `ControlManifest.Input.xml`.
				6.  Once the version numbers are updated, we can run a task, as part of our build pipeline, using the `dotnet build /restore /p:configuration=Release` command (or `msbuild`, depending on what tools are we using). We configure the task in a way that means it builds only the `cdsproj` project. We can achieve this by setting the `*.``cdsproj` wildcard.

			Once the build has been completed, we will store the produced ZIP file in the pipeline release artifact using a **Copy file** task, which can be used for deployment. The deployment process is the same as with other solution import processes.
			Automated build pipelines for single mixed solutions
			The single mixed solutions approach needs to be configured in the solution object explorer, where all the required solution components are added. Then, we utilize `SolutionPackager /action: Extract` to extract the components into the source control system. Just as earlier, we need to update the solution version in `Solution.xml` to reflect the version of the current build. We also need to change the version value inside `ControlManifest.Input.xml`.
			We will add a task to the pipeline called **Power Platform** **Tool Installer**.
			Next, we will restore `node_modules` using `npm task` with the `npm ci` command. For the production release mode, we will use `npm task` with a custom command parameter: `npm run build -- --buildMode release`. The output of the build needs to be stored separately in a folder. Then we will use a `SolutionPackager /action: Pack` to package the files and collect the built solution ZIP in the pipeline artifact.
			More information on ALM for PCF components
			To support this section, we recommend visiting the documentation on ALM for PCF components here: [https://learn.microsoft.com/en-us/power-apps/developer/component-framework/code-components-alm](https://learn.microsoft.com/en-us/power-apps/developer/component-framework/code-components-alm).
			We have mentioned many times that code components can also be used with Power Pages. Since Power Pages allows developers to extend websites greatly with custom code, it is important to take a look at how we can apply ALM to Power Pages.
			ALM for Power Pages
			Power Pages allows app makers and professional developers to build engaging, scalable, and secure websites. Since Power Pages websites are built using the HTML, CSS, JavaScript, and Liquid templating languages, developers can follow common web development practices and use known tools, such as Visual Studio Code. Once changes are made to their websites, developers should follow a process of committing those changes to the repository and applying them to different environments. This section focuses on describing how ALM is applied to Power Pages websites. We will take a look at how Power Platform pipelines enable easier and faster configuration of deployment pipelines and how to use Power Platform Build Tools in Azure DevOps to create the pipelines necessary for exporting and importing solutions into different environments.
			Power Pages was previously known as Power Apps Portals. The older data model, known also as the standard data model, used custom tables to store the configurations of Power Apps Portals websites. As configurations were stored separately, this prevented us from using solutions as was possible with other Power Platform services. However, in the second half of 2023, Microsoft introduced a new and enhanced data model that was built on system tables, non-config tables, and virtual tables. This new approach allows us to contain website configurations in solutions, which simplifies the ALM approach.
			Information about each site, including whether it uses the enhanced or standard data model, can be found inside the **Site details** | **Data model** setting for each website in Power Pages. The same website information can also be found on **Power Platform Admin center** | **Resources** | **Power Pages sites**, where you can select a site and then click **Manage**. The information about the data model is found under **Site Details**.
			Migrating from the standard model to the enhanced data model
			Although all newly created sites in Power Pages use the enhanced data model by default, you might still come across legacy Power Pages websites that are built on the standard data model. Customers who have websites that use the previous data model should consider migrating their websites to the new model. The enhanced data model provides benefits over the standard one, such as faster website provisioning, solution support, and ALM.
			Microsoft has introduced a migration guide that helps customers to migrate from one data model to the other: [https://learn.microsoft.com/en-us/power-pages/admin/migrate-enhanced-data-model](https://learn.microsoft.com/en-us/power-pages/admin/migrate-enhanced-data-model).
			Now that we’ve had a short introduction to Power Pages, we can take a look at how the PAC CLI can support website life cycle management.
			Use of the PAC CLI for Power Pages
			The PAC CLI offers tools for managing the configuration of Power Pages websites, which includes downloading and uploading website content from and to Power Pages.
			There are two specific commands that we will be using in this section. The first one is the `pac pages download` command, which is able to download website content from Dataverse. The other one is the `pac pages upload` command, which can upload website content together with all the manifest files and the deployment profile that is appropriate for the target environment.
			These two commands support ALM for Power Pages and can be used together in our CI/CD pipelines, wherever we are not using Power Platform Build Tools.
			Deployment profiles
			A deployment profile is a file in YAML format that holds a set of values and settings that are relevant to the target environment. Deployment profiles are used in a similar way as deployment settings files are in Power Apps. It is possible to have a deployment profile file for each target environment that we are deploying a website to. Each of these files contains values that match the configuration settings of the target environment.
			Deployment profiles should be added in the `deployment-profiles` folder, in the root of the downloaded website folder. A new folder will need to be created if it has not been created yet. There we can add the `<``profileTag>.deployment.yml` files.
			These files will then be used later on, during the upload process, with a `--deploymentProfile` `test` argument:
			![Figure 10.15 – Deployment profiles and manifest files in Power Pages](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_15.jpg)

			Figure 10.15 – Deployment profiles and manifest files in Power Pages
			Manifest files
			When downloading a website from Power Pages, the PAC CLI creates two additional manifest files: an environment manifest file (`org-url-manifest.yml`) and a delete-tracking manifest file (`manifest.yml`). Both files are in YAML format and stored with the `.portalconfig` root folder structure of the downloaded website.
			The environment manifest file is created with the purpose of optimizing the upload process. After each download method is run with the PAC CLI, the download method creates a new manifest file, in case one doesn’t exist yet. If the manifest file exists, it reads the existing manifest file and updates the changes, such as any entries that were removed. When uploading content, only the updated and new entries are uploaded to Power Pages.
			The environment manifest file is environment-specific, intended mainly for development environments, and it should be added to the `git` `ignore` list.
			The delete-tracking manifest file is used to keep track of entries removed from the environment. Whenever a download method is called, all the deleted entries are added to the delete-tracking manifest file. Once an upload method is called, the method removes the unnecessary entries from Power Pages. This file is important and should be added to the source control system and transferred to the target environment.
			Example of using the PAC CLI for Power Pages
			We will take a look at the example of using the PAC CLI for the download and upload of Power Pages content:

显示所有 Power Pages 网站

pac pages list

下载 Power Pages 网站的内容并将其传输到选定位置。 pac pages download -id <PAGES_WEB_ID> -p <DOWNLOAD_LOCATION>

我们对文件进行更改，并决定上传这些更改，使用部署配置文件。 pac pages upload –path <PATH_LOCATION> --environment <ENVIRONMENT_ID> --deploymentProfile

			Using Power Platform Build Tools with Power Pages
			Power Platform Build Tools offers two tasks that we have not yet explored: **Power Platform Download PAPortal** and **Power Platform Upload PAPortal**. Both tasks are intended to operate with Power Pages.
			We will first create an export pipeline that will download the website content and commit everything to the main branch. The following is a snippet of steps with the tasks needed to enable such a pipeline:

步骤:

• 任务: PowerPlatformToolInstaller@2

inputs:

默认版本: true

• 任务: PowerPlatformDownloadPaportal@2

inputs:

认证类型: 'PowerPlatformSPN'

PowerPlatformSPN: 'PP-DevUS-SPN'

下载路径: 'Portal/'

WebsiteId: '$(WebsiteID)'

• 任务: CmdLine@2

inputs:

脚本: |

echo 提交所有更改

git config user.email "<EMAIL@DOMAIN.COM>"

git config user.name "<USER_NAME>"

git init

git checkout -B main

git add --all

git commit -m "代码提交"

git push --set-upstream origin main

git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" push -f origin HEAD:main

			After running the export pipeline, we now have the source code in Azure Repos.
			As a next step, we should create deployment profiles with the necessary configuration values, as mentioned in the previous section (on creating a `deployment-profiles` folder with corresponding deployment YAML files). The deployment profile files might not change that often, as they might be environment-specific, but it is worth setting them up and updating them when necessary; it is a good practice to use them from the beginning in order to keep the configuration settings separate between environments.
			![Figure 10.16 – Deployment profiles in Azure Repos](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_16.jpg)

			Figure 10.16 – Deployment profiles in Azure Repos
			Whenever developers have to work on their website, we recommend using a branching strategy and pull request mechanism, in order to keep the main branch protected and always in a deployable state.
			After the pull request is validated and approved, branches can be merged to the main branch.
			Merging branches can automatically trigger the deployment pipeline. The following is a snippet of tasks from the deployment pipeline:

步骤:

• 任务: PowerPlatformToolInstaller@2

inputs:

默认版本: true

• 任务: PowerPlatformUploadPaportal@2

inputs:

认证类型: 'PowerPlatformSPN'

PowerPlatformSPN: 'PP-DevUS-SPN'

上传路径: 'Portal/$(WebsiteName)'

DeploymentProfile: '$(profileTag)'

			Here we have two variables, `WebsiteName` and `profileTag`. The first is the name of our Power Pages instance as it appears in our Azure Repos; `profileTag` should match the tag of the deployment profile.
			We should not forget to perform proper testing of our Power Pages websites in order to validate our work and confirm the rollout to our target environment.
			We familiarized ourselves with Power Platform pipelines in *Chapter 5*, where we talked about managed pipelines. Let’s take a look at how we can utilize Power Platform pipelines to deploy our Power Pages websites.
			Using Power Platform pipelines with Power Pages
			**Power Platform pipelines** allow the quick and easy configuration of deployment pipelines that enable organizations to automate the release of a build from the development environment to other environments, such as test and production.
			In order to utilize Power Platform pipelines, all target environments must be enabled as **Managed Environments**, and all environments that are used in pipelines must be Dataverse-enabled. All websites have to be created using the enhanced data model.
			Once the prerequisites are met, we are able to proceed with deploying our websites to target environments.
			First, we need to prepare the solution. In Power Apps, we open **Solutions**, where we either create a new solution or open an existing one. Then, we open the solution and add our existing website to the solution by selecting **Add existing** | **Site**. In the sidebar that opens, we select the website that we would like to add to the solution. Once the solution objects are added to the solution, we can proceed with setting up the pipeline. While still in the newly created solution, we click **Pipelines**, which can be found in the left navigation bar. In **Pipelines**, we can select existing pipelines that the DevOps or IT operations team has created for us in advance, or we can click **Create new pipeline**. The new popup screen allows us to define the deployment pipeline, which will take our solutions from the source to the target environment:
			![Figure 10.17 – Power Platform pipelines](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_17.jpg)

			Figure 10.17 – Power Platform pipelines
			Once the pipeline is configured, we can press the **Deploy here** button and the deployment process will start.
			This is a more simplified kind of deployment process. Still, it is suitable for many scenarios. It opens the door for app makers who might not be skilled in DevOps processes and CI/CD pipelines but are still aware of the importance of the automated approach of deploying business solutions and keeping environments separate.
			Summary
			This chapter continued building on the possibilities that Microsoft Power Platform provides to pro-developers. The platform definitely shouldn’t be taken lightly, even though it is a part of the low-code development toolset. As we have seen, it offers many opportunities for pro-developers to extend the user experience and integrate solutions with complex backend and legacy systems. Now we can see how important it is to form agile fusion teams where pro-developers have the ability to customize solutions using different custom components, in order to deliver on project requirements.
			We looked at examples of how connection references and environment variables can be used together with the DevOps approach. We continued with a look at canvas components and component libraries. We then covered the Power Apps component framework and code components. All these components can be added to solutions as solution objects, and DevOps pipelines can be used to deploy them securely to other environments as development progresses. We closed this chapter by taking a look at Power Pages ALM. We have investigated how we can use Power Platform Build Tools to support ALM process for our websites, as well as checked a simpler approach using managed pipelines in Power Platform.
			The next chapter will focus on best practices for managing environments in a governed and secure way and how the IT operations team can describe environments using code. This is a very important part of the DevOps life cycle that we have to address, even though it is not very pro-dev-oriented.
			Further reading

				*   Connectors architecture: [https://learn.microsoft.com/en-us/connectors/connector-architecture](https://learn.microsoft.com/en-us/connectors/connector-architecture)
				*   Connection references: [https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-connection-reference](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-connection-reference)
				*   Environmental variables: [https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables)
				*   Component library: [https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/component-library](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/component-library)
				*   Power Apps component framework: [https://learn.microsoft.com/en-us/power-apps/developer/component-framework/overview](https://learn.microsoft.com/en-us/power-apps/developer/component-framework/overview)
				*   Power Pages ALM: [https://learn.microsoft.com/en-us/power-pages/configure/portals-alm](https://learn.microsoft.com/en-us/power-pages/configure/portals-alm)

第十一章：通过设计最佳实践管理环境生命周期

每个组织在开发任何类型的业务应用程序时，都应优先在受治理和安全的环境上构建弹性解决方案。 在没有管控和治理的环境中实施 DevOps 可能会导致不合规和不一致的流程，从而影响应用工作负载的效率和可靠性。 缺乏治理的环境更容易受到漏洞的攻击，即使潜在的危害是内部员工无意造成的。 内部员工。

本章重点探讨经过验证的最佳实践和指南，这些实践和指南可以帮助组织构建有助于负责任创新的环境，同时确保合规性和安全性。 我们将深入研究触及治理、合规、安全性和自动化等领域的不同设计原则，并探讨如何自动配置 Power Platform 环境，从而使其减少 配置错误的风险。

我们将研究 Power Platform 良构架框架 以及 Power Platform 着陆区 并解释如何在组织中部署着陆区。 接下来我们将继续探讨如何通过代码描述应用工作负载，以及如何采用自动化方法管理环境，而不是手动管理。 由于运营团队负责为每个人提供一个受治理的工作空间来进行创新，我们将在本章最后讨论 Power Platform 卓越中心 （CoE），它帮助组织培养应用开发者并提高应用采纳度，同时关注 治理问题。

正如我们所看到的，本章稍微转变了一下话题，更多地讨论了与运营团队相关的能力。 这些是平台采纳和 DevOps 方法成功采纳的非常重要的方面。 尽管如此，开发者和应用开发者仍然可能会发现了解这些选项有价值。 这些选项。

我们将涵盖以下 主要主题：

• 基于设计 最佳实践

• 自动化环境生命周期 管理

• Power 平台 CoE

技术要求

为了跟随本章内容，我们建议具备以下条件： 已具备：

• Power Platform 订阅：我们可以注册 Power Platform 开发计划（https://powerapps.microsoft.com/en-us/developerplan/），如果我们已经有 Microsoft Entra ID 工作账户，或者我们可以加入 Microsoft 365 开发者 计划 (https://developer.microsoft.com/en-us/microsoft-365/dev-program)。

• Azure 订阅：我们可以按照以下网站的指导，申请一个免费的 Azure 账户： https://azure.microsoft.com/en-us/free。账户创建完成后，可以通过以下 URL 访问 Azure 门户： https://portal.azure.com/。

• Azure DevOps 服务：我们可以随时创建一个 DevOps 组织，并且是免费的： https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates。

• Visual Studio Code：这可能是另一种首选的 IDE 或文本编辑工具。

• Terraform：Terraform 的安装指导可以在这里找到： https://developer.hashicorp.com/terraform/install。

• 示例：本章讨论的示例位于以下仓库 ： https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter11。

基于设计最佳实践

本节专注于 Power Platform 架构良好的框架中定义的指导方针和最佳实践，以及作为参考实现的 Power Platform 着陆区。遵循这些实践将帮助组织构建强大、可扩展且安全的 Power Platform 工作负载。

Power Platform 架构良好

Power Platform Well-Architected 是一个 框架，汇集了最佳实践和建议，帮助各种规模的组织 设计、构建并实现其在 Power Platform 上运行的工作负载的最优架构设计。

在框架的上下文中，术语 工作负载 指的是在 Power Platform 上构建的整个业务解决方案。 该解决方案与业务需求相对应，涵盖了应用程序、数据以及支持其运行的周边基础设施。

Power Platform Well-Architected 提供的指南应在业务解决方案开发的各个阶段中应用。 这些建议即使在对现有 DevOps 或 DevSecOps 流程进行增强时，仍然适用。 Well-Architected 框架的一个关键目标是让组织能够持续评估其业务解决方案是否符合该框架的指导，并通过获得的评分验证组织在框架每个支柱上的立场。 这有助于组织在确保工作负载与 业务需求保持一致的同时，持续改进。

Power Platform Well-Architected 框架建立在 Microsoft Azure Well-Architected Framework （Azure WAF） 的指导基础上。与后面将在本节中介绍的 Azure 登陆区类似，Power Platform Well-Architected 也可以与 Azure WAF 一起使用，帮助设计跨越 Power Platform 和 Azure 的工作负载架构。 这一点对已经采用 Microsoft Azure 服务并在 Azure 中运行工作负载的组织尤其重要。

Power Platform Well-Architected 包括五个基础性支柱，旨在提升 Power Platform 工作负载的质量。 这五个支柱围绕以下内容组织：

• 可靠性：确保用于运行业务解决方案的工作负载能够满足正常运行时间要求，并且我们有一个恢复计划 以应对突发情况

• 安全性：这 有助于保护服务免受各种威胁 和漏洞的影响

• 运营卓越：这 专注于促进负责任的开发和安全的 部署实践

• 性能效率：这 侧重于确保工作负载可扩展，通过健康监控，我们可以深入了解 性能效率

• 体验优化：这是为了确保运行解决方案的工作负载易于 使用

每个支柱都有自己的设计原则、检查清单、设计建议、权衡取舍以及评估问题。 对于每个支柱，有些建议容易实现，而另一些则需要从基础设施和应用角度进行适当规划才能实现。 我们还需要意识到，对于每个支柱，都存在权衡取舍，可能需要牺牲一个支柱的某些特性，以便让 另一个受益。

Power Platform Well-Architected 评估

无论 我们是构建新的工作负载，还是已经有一个在运行中但希望了解潜在的改进点，Power Platform Well-Architected 都提供了对每个支柱的评估，给出建议和支持材料，帮助改进工作负载的设计。 从评估工具中获得的建议应该导出并添加到 DevOps 工具中的项目待办事项中，如 Azure Boards 或 GitHub Issues。 我们应该遵循持续改进的过程，定期评估我们的环境。 Power Platform Well-Architected 评估可以在 这里找到： https://aka.ms/powa/assessment。

可靠性

这个支柱的重点是 确保我们正在构建一个具有韧性和可靠性的工作负载，能够在 合理的时间内从任何潜在的操作故障中恢复。

当我们在 Power Platform 上构建工作负载时，收集并记录所有业务需求是我们的责任。 业务需求将帮助我们决定哪些工具和技术将支持工作负载，以及基础设施和应用设计的形态。 围绕技术的这些决策和遵循业务需求对于制定故障恢复计划至关重要。 为了支持工作负载更加具有韧性，我们应该结合监控功能，通过这些功能，工作负载可以识别并应对操作故障。 它还将作为使用情况的洞察，能够帮助改进 工作负载。

推荐示例

目前，在可靠性支柱的背景下有八项推荐实践，其中一些与开发人员直接相关，例如在业务解决方案中实现健壮的错误处理和瞬态故障处理机制。 其他建议更多是面向 IT 运维团队，例如持续捕捉运行时间以衡量解决方案的 健康指标。

其中一项推荐特别有趣，因为它通过应用混沌工程的原理，将 DevOps 实践与应用程序弹性测试相结合。 混沌工程 是一种 帮助组织通过系统地向整个应用工作负载引入可控中断来增强其工作负载的实践，从而模拟 现实世界的停机。

与混沌工程相关的是另一种有趣的工作负载测试实践，称为 故障注入测试。它 有助于我们识别解决方案在面对特定组件或依赖项故障时的响应。 在这种情况下，测试更具针对性，在测试过程中故意向特定组件注入故障。 测试过程中的注入。

如果我们想进行此类测试，了解我们的基准行为是非常重要的。 根据实验的不同以及我们计划测试的内容，我们可以为实验构建一个假设，通过该实验来衡量基准行为。 基准行为将作为一个基准，我们将其与实验结果进行比较。 为了测量基准，我们可以简单地按常规方式运行并测试我们的应用程序/流程，不做任何中断。 然后，我们开始向系统注入故障，并从我们通过监控工作负载收集的分析和遥测数据中获取见解。 举一个故障注入的例子，我们可以向后端服务或 Power Automate 流程中引入延迟，或者在从 Power Automate 流程或后端服务获取结果时返回（模拟的）错误代码，以模拟服务故障。 我们收集到的见解会被记录下来，随着我们从中学习，我们可以制定修复计划并改进 我们的工作负载。

正如我们 所看到的，这些做法具有破坏性，因此应该在预生产环境中执行 。

这两种测试实践是相互关联的，并且应该是 DevOps 推动的持续改进过程的一部分。 我们 可以使用 Power Apps 测试引擎来构建自己的故障注入测试，例如，使用连接器模拟功能。 该测试可以通过 PAC CLI 调用，这使我们能够在 CI/CD 管道中实现自动化。 我们已经在 第八章中展示了这样的一个示例。

对于可能在 Azure 上有后台系统或通过自定义连接器安全地暴露 API 的情况，我们可以利用一个名为 Azure Chaos Studio 的服务来 对在 Azure 上运行的服务进行实验。 Azure Chaos Studio 是一个托管的混沌工程实验平台，允许我们设置不同的实验，目标是 Azure 中的服务。 通过这个工具，我们可以定义模拟现实生活中中断的实验，例如网络连接问题和后台服务 性能下降。 更多关于 Azure Chaos Studio 的信息可以在 这里找到： https://azure.microsoft.com/en-us/products/chaos-studio。

安全性

Well-Architected 的下一个支柱与安全性相关。 它专注于构建能够承受潜在攻击的工作负载，并整合了三项基本安全原则——保密性、完整性和可用性。 在设计业务解决方案或工作负载架构时，我们建议采用 Microsoft 零信任模型来减轻安全风险。 Microsoft 零信任模型围绕三个 关键原则展开：

• 明确验证：确保 通过根据各种数据点进行身份验证和授权，只有可信实体才能获得访问权限。 这样做将允许实体仅访问他们被授权访问的内容，并仅执行他们可以执行的操作。 。

• 最小权限访问：遵循 最小权限原则。 通过限制身份的权限，我们 正在限制可以做什么、做多久以及可以访问哪些资源。 。

• 假设发生泄露：工作负载 应当设计成我们假设可能会发生泄露的方式。 考虑到这一点，我们正在实施控制措施，以降低风险和潜在的损害，万一发生 这种情况。

推荐示例

此 安全支柱侧重于 10 条建议。 其中一些已在 第七章 中涉及过，我们当时讨论了 DevSecOps。 这些内容包括威胁建模、静态应用安全测试以及应用程序秘密保护等实践。 我们还提到，开始在身份层面强化我们的安全防御非常重要，因为身份层是防御的第一道防线。 由于所有 Power Platform 产品都利用 Microsoft Entra ID，我们可以通过配置条件访问控制、通过安全角色配置访问权限等方式来构建身份边界。 为了了解系统中谁做了什么，我们应启用相关环境的审计日志。 保留审计记录对于防止潜在的否认攻击至关重要。 然而，我们可以利用专门构建的工具， 而不是手动查看日志以查找常见的攻击模式。

Microsoft Sentinel 是一个云 安全信息和事件管理 (SIEM) 工具，运行在 Microsoft Azure 中，帮助通过分析来自不同 Power Platform 服务的活动日志来监控和检测潜在威胁。 通过使用 Power Platform 解决方案，我们现在可以利用 Microsoft Sentinel 来检测与 Power Platform 相关的各种异常情况，包括 Dataverse。 通过不同的数据连接器，该解决方案获取并分析活动日志和库存数据。 数据连接器从不同的数据源收集数据， 允许 Sentinel 使用内置的分析规则来检测 以下内容：

• 是否有多个 Power Apps 应用程序 被删除

• 是否有任何被 Entra ID 标记为受损的用户访问了 Power Platform

• 是否有应用程序被分享给新创建的 来宾用户

• DLP 策略是否已更新或删除 以及更多

• 当离职员工创建或修改 Power Automate 流程时， 以及更多

该解决方案的安装是在 Azure 门户中的 Microsoft Sentinel 服务中进行的。 要使用 Azure 门户，我们需要登录到我们的 Azure 订阅。 在那里，我们需要配置一个 Log Analytics 工作区和 Microsoft Sentinel 服务。 完成后，我们可以进入我们的 Sentinel 服务。 在左侧导航栏下，选择 内容管理 | 内容中心，我们可以找到 Microsoft Sentinel 提供的所有解决方案列表。 通过搜索，我们可以轻松找到 Power Platform 解决方案。 选择它并点击 安装。安装完成后，我们需要启用数据连接器，如 图 11**.1所示。完成该过程，我们需要按照一系列步骤操作，例如 创建一个 Azure Data Lake Storage Gen2 实例，供 Power Platform 自助分析使用，并确保我们拥有部署所需组件到 Azure 的所有权限。 所有七个数据连接器都必须配置，因为每个连接器都有其特定用途。 我们建议按照 图 11**.1 后面的提示，验证安装是否成功完成：

图 11.1 – Microsoft Sentinel 解决方案 for Power Platform

Microsoft Sentinel 解决方案 for Power Platform – 先决条件与安装

该解决方案帮助我们检测并响应与 Power Platform 相关的潜在威胁和事件。 该解决方案目前处于预览阶段。 有关先决条件及其如何部署的信息可以在 这里找到： https://learn.microsoft.com/en-us/azure/sentinel/business-applications/deploy-power-platform-solution。

在 Power Platform 优良架构的背景下，安全支柱推荐的另一个实践是 进行 模拟攻击。这些模拟攻击有不同的目的。 当然，通过这样的演练，我们希望识别任何潜在威胁，但通过这种方式，我们还可以验证工程师的准备情况以及修复流程，特别是在战争游戏演练中，其中有红队和蓝队。 这首先涉及尝试发起一次模拟攻击，而另一方则试图识别并防御 这次攻击。

除了模拟攻击， 安全 工作区在 Power Pages 中是我们进行安全扫描的地方，用于评估网站是否存在潜在的安全漏洞。 它是一个一站式商店，可以找到与页面相关的所有配置角色和权限信息。 我们还可以为保护 我们网站的 Web 应用防火墙配置额外的规则。 更多关于安全扫描的信息可以在 这里找到： https://learn.microsoft.com/en-gb/power-pages/security/security-scan。

图 11.2 – Power Pages 安全扫描

要了解 我们 Power Platform 租户的整体安全状况，微软最近在 Power Platform 管理中心推出了 安全 中心。 它允许管理员快速采取措施，根据识别出的建议来提升安全状况，比如为环境应用 DLP 策略、配置租户隔离，和审计。

图 11.3 – Power Platform 安全中心

卓越运营

这一 支柱强调创造一个优先考虑运营卓越的工作环境。 我们的意思是通过实施融合开发方法并采用 DevOps 文化，将最佳开发实践带入工作负载团队。 这样做将使工作负载团队能够遵循自动化和可重复的流程，从而实现安全的开发和部署实践。 流程必须遵循组织内设定的合规性和治理标准，才能高效和有效。 构建与组织政策一致的标准化流程，可能会在交付项目时导致额外的时间和成本。 项目的交付。

目前，针对这一支柱有 11 条建议，集中于融合开发方法和构建 DevOps 实践，标准化开发实践，构建监控系统，寻找自动化机会以减少手动任务，并实施 测试策略。

由于这些建议在本书中已有涉及，我们将跳到下一个支柱。 有关深入指导，请访问 进一步阅读提供的链接。

性能效率

下一个支柱关注 与构建可扩展且高效的工作负载相关的建议，并在不牺牲用户体验的情况下理解权衡。 设计原则帮助我们围绕我们正在开发的工作负载的业务需求设定性能目标。 在定义性能目标时，我们应该考虑用户如何看待我们的解决方案，以及什么样的性能对他们来说是不可接受的。 我们应该设定可实现的目标并 记录它们。

为了确保性能目标的达成，我们持续监控工作负载的整个生命周期，以了解是否达到了预定目标。 如果目标未能按预期达成，我们应该优化工作负载。 在监控方面，我们使用了 Power Platform 的内建功能。 正如我们在本书中已经看到的，Power Platform 可以通过 Azure Application Insights进行扩展。作为 Azure Monitor 的一部分，Azure Application Insights 是一款应用性能监控工具，不仅可以从 Power Platform 应用程序收集遥测数据，还可以从运行在 Azure 云或本地环境中的其他服务中收集数据。 这帮助我们理解解决方案架构中的更广泛图景和瓶颈，因为用户可能会将性能问题归咎于 Power Platform，因为这是他们与之互动的部分。 然而，性能问题可能出现在其他后端系统或数据库系统中，例如某些过程执行时间过长 或查询执行过慢。

规划高性能工作负载时，一个重要方面就是考虑 Power Platform 的请求限制。 由于 Power Platform 是一个 软件即服务 (SaaS)平台，提供服务的后台系统和服务本身有预定的限制，以确保每个 Power Platform 用户都能满足质量和服务级别协议。 Power Platform 具有 服务保护限制 ，用以保护 Power Platform 服务免受异常或过量请求的影响。 这些资源限制应当由解决方案架构师在设计工作负载架构时考虑。 这些限制在设计工作负载架构时必须加以考虑。

Power Platform 请求限制

尽管 Power Platform 的请求限制已经在增加，并且常规用户不太可能达到请求限制，但值得注意的是这些限制存在，并且在准备架构设计时应该考虑到这些限制。 有关请求限制的更多信息，请访问 此链接： https://learn.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations。

推荐示例

目前，这个 支柱包含了 10 个推荐措施，重点关注监控工作负载、操作和用户行为，这将帮助我们分析和改进 Power Platform 工作负载的性能。 这个支柱的大部分内容都集中在优化业务逻辑、自定义代码和数据性能，以及了解业务流程的性能并寻找潜在的优化机会。 在 Azure Monitor 中捕获遥测数据使我们能够深入了解性能，并设置警报，以便及时获知工作负载的当前状态。 这种分析数据还可以作为 CI/CD 管道中的部署门控——一个常见的例子是通过 Power Platform 中的自定义连接器使用的后端服务。 如果由于高峰期或性能问题，服务的使用在一段时间内较高，我们可以暂停并推迟工作负载的部署，直到此问题 得到解决。

一个重要的 DevOps 实践是实施 反馈循环。 除了设置监控以收集性能瓶颈、查看工作负载在高峰期的运行情况以及检查是否发生错误外，我们还可以使用 Azure Application Insights 来深入了解用户行为，并利用这些信息规划应用程序的改进。 我们还应考虑实现渠道，使用户能够向工作负载团队分享他们对已开发商业解决方案的反馈和建议。 这将帮助我们确保解决方案符合他们的需求。 这种做法已经在许多现成的产品中得以实现，通常是在应用程序中实现某种反馈按钮。

类似的做法也可以在 Power Platform 开发的商业解决方案中实现。 此示例提供了逐步指导，可以在以下 网站上找到： https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/application-insights#create-custom-trace-events。

体验优化

Power Platform Well-Architected 框架的 最后一个核心支柱专注于用户 体验，以及开发人员在开发过程中应考虑的事项。 应用程序应该以与用户期望相一致的方式构建，并且要设计以满足特定需求。 与应用程序的交互应该简单且合乎逻辑，以便用户能够高效地完成所需的工作。 应用程序相关的流程也应该简洁易懂 且直观。

我们应该构建用户友好的应用程序，具有包容性，能够被有障碍的用户使用。 如果该应用程序将被全球用户使用，我们应该考虑提供本地化版本以提高 用户参与度。

推荐示例

该 支柱包含九条推荐措施，专注于构建包容性、吸引力和直观性的应用程序。 在这里，我们可以找到关于如何构建 响应式应用程序的指导，如何利用 Fluent Design 构建可重用组件，以及如何使用 Power Platform Creator Kit，如何实现健壮的 错误处理控制等。 在此支柱的背景下，DevOps 实践帮助我们遵循标准化流程，从而更快速地将更改带给 用户。

Power Platform Well-Architected 深入指导

本节 介绍了 Power Platform Well-Architected 核心支柱的一些内容，并分享了一些推荐示例。 每个支柱都有一套自己的设计原则、推荐措施，更重要的是，权衡利弊，工作负载团队应该在遵循此指导时熟悉这些内容。 当遵循这些指导时。 有关可用工具和评估的更多信息，请访问以下 网址： https://learn.microsoft.com/en-us/power-platform/well-architected/。

我们已经 简要讨论了帮助我们理解 Power Platform Well-Architected 目标的一些推荐措施。 深入了解每个支柱，并通过一套最佳实践和指南来理解推荐措施，以便在 Power Platform 中设计现代应用程序时做出明智的决策，这将极大地帮助每个人，无论是构建简单还是复杂的 业务解决方案。

在下一部分中，我们将探讨如何通过参考实现遵循架构最佳实践，该实现描述于 Power Platform 登陆区。

Power Platform 登陆区

在开始 Power Platform 采用之旅时，通常会从默认的个人生产力环境开始，并逐步从那里扩展。 正如我们在 Power Platform 采用成熟度模型中看到的那样，这种方法与组织成熟度的早期阶段相吻合。 然而，随着组织对平台的熟悉，它们开始寻找保护租户、设置环境策略并围绕这些策略建立政策的方法。 通常，组织会询问如何设计最优架构，以便设置 Power Platform 来处理企业级场景。 这时，登陆区可以作为一个有价值的资源供 参考。

登陆区 作为参考实现，建立了用于运行特定工作负载的良好管理环境。 它们遵循最佳实践，构建一个强大、安全、可扩展的基础，以便在组织内使用，并随着公司采用特定技术的不断推进而不断发展。 它们遵循跨多个设计领域的关键设计原则，如许可、安全、治理、自动化和 DevOps。 通过登陆区，微软提供了各种技术和服务的参考实现。 其中最广为人知的是 Azure 登陆区，这是一个帮助组织设置 Azure 环境 和服务的总纲登陆区。

Power Platform 登陆区

Power Platform 登陆区 代表一个参考实现，组织可以 用它来构建他们在 Power Platform 租户内的初始架构设计。 它也可以看作是一种方法论，包含有关架构设计的指南，遵循实施最佳实践。 在 Power Platform 的上下文中，登陆区代表一个环境，其中配置了所有支持服务、政策和安全角色，为组织提供与最佳实践和建议对齐的起始点。 通过可用的控制，组织可以决定哪些安全政策和治理要求应该配置，以匹配 组织的需求。

Power Platform 登陆区通过与现有的 Azure 订阅连接，扩展了 Azure 登陆区，这使得已经采用 Azure 云服务的客户能够使用 LCNC 开发平台（如 Microsoft Power Platform）解锁新的应用现代化场景。 连接 Azure 订阅与 Power Platform 环境的核心点是 Microsoft Entra ID，这是一种身份和访问 管理系统：

图 11.4 – 使用 Power Platform 登陆区扩展 Azure 登陆区

设计原则和关键设计领域

Power Platform 登陆区架构基于五个设计原则构建。 这些原则在做出进一步设计决策时，作为 指导方针：

• 环境民主化：环境作为管理单元，具有安全性和策略边界。 它们的创建是为了支持业务单元和开发者，并解决 业务需求。

• 政策驱动治理：实施 DLP 政策为应用开发者提供了灵活性，以便在 保持合规的同时创建应用程序工作负载。

• 单一控制和管理平面：Power Platform 管理通过原生的 Power Platform 管理工具进行，以提供 一致的体验。

• 与角色无关：任何开发者都欢迎在 Power Platform 中进行创新，并且在能力的视角下，所有开发者都被平等对待。

• Power Platform 原生设计和平台路线图对齐：在可能的情况下，应使用原生服务和功能，这将确保一旦发布新功能，应用程序可以从这些新功能中受益。 Power Platform 路线图使管理员和开发者可以及时了解新功能，并根据需要采纳 它们。

在设计原则之外，Power Platform 登陆区架构还包括了对设计决策起重要作用的设计领域。 它们作为决定架构设计的指南针。 其中有八个设计领域，包含了考虑因素和建议，应该在规划架构设计时加以考虑。 我们可以看到，这些设计领域中的一些与 Well-Architected 支柱中的推荐类似，例如平台自动化 和 DevOps。

以下是 Power Platform 的 关键设计领域：

• 许可与 AD 租户：由于许可证是允许用户访问 Power Platform 服务的第一个控制点，因此该设计领域专注于理解许可证如何影响环境访问、哪种许可模型最合适（包括按需付费计划），以及关于分配许可证 给用户的建议。

• 身份与访问管理：身份与访问管理与 基于角色的访问控制 (RBAC) 在使用户能够操作 Power Platform 中起着重要作用。 该设计领域侧重于通过条件访问策略和多因素身份验证等控制措施来保护对租户的访问，以及与组织的安全性和 合规性要求相一致的其他授权规则。

• 环境：环境在隔离数据和应用负载中起着重要作用。 该设计领域涵盖了良好的环境策略和配置选项的重要性，例如选择环境的地理位置、启用审计以及其他用于监控用户环境行为的控制措施。 此外，它还专注于启用托管环境，以提供一组额外的高级功能 和控制。

• 安全性、治理和合规性：在许可证和角色基于访问控制（RBAC）之外，此设计领域专注于提供有关数据丢失防护（DLP）政策的建议，这些政策定义了连接器的分类及其使用政策。 控制连接器的使用在平台的安全采纳中起着重要作用。 平台采纳。

• 管理与监控：通过使用管理中心和其他第一方工具，管理员配备了管理 Power Platform 环境和构建自动化任务所需的工具。 为了监控性能和查看审计日志，Power Platform 可以与 Azure Monitor、Microsoft Entra ID 和 Microsoft Purview 等其他服务连接，以启用额外的监控和 审计能力。

• 业务连续性和灾难恢复：组织应该制定场景，确保环境的弹性和持续可用性。 在持续可用性中，这里我们也专注于备份和环境 恢复过程。

• 连接性与互操作性：这一设计领域涉及可能的连接模型，连接 Power Platform 服务及其外部服务。 由于数据可能位于 Power Platform 外部，理解如何连接到这些数据非常重要，可以通过 本地数据网关或 虚拟网络 （VNet）数据网关进行连接（当使用 Azure 数据服务时）。 这两项服务各自有其局限性和要求，包括许可要求，可能会影响决策。 在必要时，可以使用 Azure ExpressRoute，通过组织本地网络与 Microsoft 云服务之间的私有连接来连接组织与 Microsoft 云服务。 这还使得连接更加可预测，适合于任务关键型应用程序。 具有严格监管要求的组织也可能对 ExpressRoute 感兴趣。 ExpressRoute 可作为其解决方案的一部分。

• 平台自动化与 DevOps：Power Platform 登陆区鼓励组织实施 DevOps 实践，使 IT 管理团队和专业开发人员能够合作，不仅管理应用生命周期，还通过环境生命周期管理、安全监控、成本管理等全面管理 Power Platform。 以及更多。

如我们所见，Power Platform 登陆区提供了关于一组设计考虑事项和建议的深刻见解，这些内容可以作为组织构建包含这些设计考虑因素的架构设计的起点。 结合 Power Platform Well-Architected，现在我们有了广泛的指导，可以帮助我们在 Power Platform 上进行现代应用解决方案的架构决策。

为了查看这些设计领域的实际应用，我们可以查看 参考实现。

部署 Power Platform 登陆区参考实现

Power Platform 登陆区参考实现是一个模块化的架构参考，利用设计原则和关键设计领域，帮助组织构建支持应用工作负载的环境。 这个参考实现可以根据需要进行定制，只部署必要的部分到 组织的租户。

要部署 Power Platform 登陆区参考实现，我们需要一个 Azure 订阅和一个 Power Platform 租户。 我们在本章的 技术要求 部分提供了指导链接，帮助您在需要时进行配置 。

作为部署登陆区的 前置条件之一，我们需要首先创建一个 用户分配的托管身份 （UMI），该身份 具有使用 Power Platform API 的权限。 这可以通过访问 Azure 门户并创建一个 新的 UMI 来完成：

1. 在 Azure 门户中，我们应该搜索 托管身份 并打开 托管身份 页面，页面上展示了您租户中的所有托管身份：

图 11.5 – 托管身份

1. 要创建新的 UMI，我们接下来点击 点击 创建：

图 11.6 – 创建新的托管身份

在此阶段，我们需要提供所有创建托管身份的详细信息。 这 包括选择 Azure 订阅，在此我们可以选择已有的资源组，也可以直接从该 页面提供一个新的资源组。

1. 通过提供托管身份实例的详细信息，例如选择 UMI 将要配置的 Azure 区域以及名称，我们可以通过 点击 下一步来准备创建 UMI：

图 11.7 – 配置新的 UMI

1. 在下一个屏幕中，我们可以添加标签。 我们建议为 Azure 资源添加标签， 以便以后能够对其进行分类，并将其映射到组织中的正确成本中心。 完成后，我们通过点击 审查 + 创建进行下一步操作，这将启动验证 过程，以验证 Azure 资源管理器 （ARM）模板。 验证过程完成后，我们可以通过 点击 创建来配置资源。

2. 一旦新 UMI 创建完成，我们继续打开该资源，在 概述 屏幕上，进入 托管身份，找到并复制 客户端 ID 信息。 这将在下一步中 在 PowerShell 中使用：

图 11.8 – 托管身份概述信息

现在，我们准备好运行本地 PowerShell 会话或继续使用 Azure Cloud Shell。Azure Cloud Shell 提供许多预安装的工具和模块，简化了管理，特别是当我们在权限有限的设备上工作时。

以下代码展示了如何使用 PowerOps PowerShell 模块访问 Power Platform API，并将新创建的 UMI 注册为管理员管理应用程序。 这是通过 ARM 模板 成功部署 Power Platform 登陆区参考实现的前提条件。

如果我们在本地运行这些命令，我们应确保安装了 Az.Accounts 和 PowerOps 模块。 对于 Azure Cloud Shell，这一步 是无需执行的：

 Install-Module -Name Az.Accounts -Force
Install-Module -Name PowerOps -Force

一旦模块安装完成，我们需要连接到我们的 Azure 租户。 我们通过使用 Connect-AzAccount 命令来完成此操作。 如果我们的 Azure 管理员已配置多重身份验证，我们需要使用带有特殊标志的命令，以便提供与 设备代码 的交互式身份验证：

 Connect-AzAccount -UseDeviceAuthentication

连接到 Azure 后，我们需要确保使用的是正确的 Azure 订阅。 如果我们要使用的订阅是默认订阅，则无需执行此命令。 如果我们有多个订阅，应该确保我们位于正确的 Azure 订阅中。 Azure 订阅 ID 可以在 Azure 门户中找到，或者通过使用 Get-AzSubscription 命令返回所有订阅的列表、其 ID 及其状态。 要设置当前工作上下文，我们使用带有 订阅 ID 的命令：

 Set-AzContext -Subscription "xxxx-xxxx-xxxx-xxxx"

最后，我们准备好执行 UMI 的注册。 我们可以从之前创建的身份中复制客户端 ID，方法是在 Azure 门户中：

 $clientId = '<Azure UMI Client Id>'
Register-PowerOpsAdminApplication -ClientId $clientId

注册过程完成后，我们可以继续进行部署设置。 在托管 Power Platform 着陆区实施指南的 GitHub 仓库中（https://github.com/microsoft/industry/tree/main/foundations/powerPlatform），我们可以找到一个 部署到 Microsoft 云 按钮。 选择此选项后，我们将被转移到 Azure 门户，Power Platform 着陆区将通过自定义 ARM 模板进行部署：

图 11.9 – 在 Azure 门户中的 Power Platform 着陆区部署模板

1. 从 图 11**.9中，我们可以看到设置着陆区参考实现过程中的第一个标签是 部署设置。在这里，我们将连接到新创建的 UMI 并选择我们的 Azure 订阅以及位置。

2. 下一个标签是 安全、治理和合规性，允许进行租户范围的 DLP 策略配置，通过为连接器选择不同级别的限制。 在此步骤中创建的 DLP 策略将作为基准策略，后续可以添加新的 DLP 策略。 还可以在此应用其他策略，如租户隔离、访客用户和共享设置。

3. 下一个标签是 管理员环境与设置，允许组织创建仅用于管理目的的独立管理员环境——例如，我们可以创建一个独立环境，在其中部署一个 CoE 启动工具包。创建独立的管理员环境将导致拥有独立的开发、测试和生产环境，以支持我们业务解决方案的应用生命周期管理。 在这里，我们还可以找到一项策略，禁止用户自行创建不同类型的环境。

4. 接下来，我们有 管理与监控。在这里，我们可以配置用于监控的其他 Azure 服务，例如 Azure Monitor 中的 Application Insights。 此外，我们还可以为 Power Platform 启用租户级分析。

5. 该过程的最后一步是配置额外的登陆区（环境），这些环境将专门面向公民开发者、专业开发者或行业解决方案。 如果需要，我们可以跳过这一步，稍后当我们意识到需求增加且需要更具体的环境时，我们可以使用 登陆区自动配置模板 选项，使用相同的 Power Platform 登陆区 GitHub 仓库来配置 更多环境。

6. 在过程结束时，我们可以回顾我们所做的所有配置选项，并通过选择 创建 按钮来完成配置过程。

这些标签页包含了针对参考实现的关键设计领域的配置设置。 这些是我们在创建自己的架构设计时需要考虑的事项。 即使我们来自一个较小的组织，实施登陆区似乎过于复杂，我们仍然应该遵循关键设计领域，并将登陆区参考实现作为我们的北极星，作为指导我们前进的方向，实施最佳实践和保护措施，以保护组织数据。 我们可以从小规模开始，但随着采用的增长，我们将通过标准化和一致性的方法看到登陆区在资源配置中的好处。 受管环境。

现在我们已经看过如何使用登陆区参考实现来配置新的环境，我们将朝着使用各种工具自动创建和管理环境的方向前进，同时仍然包括设计领域中的重要部分，例如添加 DLP 策略 和许可。

自动化环境生命周期管理

到目前为止，我们 一直使用 Power Platform 管理中心来管理环境和 Power Platform 租户。 来自云服务和 DevOps 领域的人可能知道，Azure 云服务可以通过更具描述性的方法和 CI/CD 管道进行管理，而不是通过 Azure 门户进行管理。 通过门户手动操作的方式也无法很好地扩展。 Well-Architected 和关键设计领域的建议之一提到，我们应该寻求自动化所有可能的操作，并在不需要人工干预的地方实现自动化。 在本节中，我们将尝试以类似于其他 Azure 云服务的方式来管理环境。 我们将探讨如何启用一种更自动化的方式来管理环境，遵循来自定制开发和 DevOps 领域的知名实践。

基础设施即代码（IaC）与 ClickOps

首先，让我们从解释什么是 IaC 以及 配置即代码 (CaC)开始，因为它们都涉及到基础设施，但又有所不同。 这两者都是广为人知的 DevOps 实践，能够自动化 IT 操作，并帮助实现一致的软件交付。 这两种实践使得 DevOps 团队不仅能够交付应用程序，还能交付支持应用程序部署的底层基础设施和所需的配置。 这两种实践都使用某种脚本或代码模板，通过这些模板可以管理底层基础设施。 IaC 专注于基础设施的供应；这可能包括服务器、数据库、特定的 平台即服务 (PaaS)服务及其他组件。 而 CaC 则关注于管理我们应用程序所需的系统组件的设置和配置，例如，设置服务器配置、安装和配置数据库服务器，以及配置 网络设置。

不同的工具使用不同的语言来描述或配置基础设施。 工具通常定义了使用代码的哪种类型的方法。 这意味着代码以 声明式 (功能) 或 命令式 (过程) 方式描述。 如果方法是声明式的，那么在代码中我们描述 我们希望目标环境是什么 ，而工具将执行所需的步骤以达到所需的状态。 如果方法是命令式的，我们描述 我们如何达到目标环境 ，这意味着我们需要按照适当的顺序定义一组命令，这些命令将引导我们到 所需的状态。

在 Power 平台着陆区，我们使用了通过 Azure 门户配置的参考实现，但在后端，门户的配置映射到了一个 ARM 模板，该模板描述了我们希望拥有的 Power 平台环境的状态。 ARM 模板是一种 JSON 文件类型，遵循 JSON 部署模板架构，在声明方式中描述我们希望 ARM 在目标订阅中提供的基础设施。 目标订阅。

ARM 模板文件示例——Power 平台着陆区 ARM 模板

着陆区 ARM 模板文件可以访问 这里： https://github.com/microsoft/industry/blob/main/foundations/powerPlatform/landingZones/ppNorthStarLzs-arm.json。

Azure 提供了另一种描述 IaC 的方式——使用 Bicep。然而，在市场上还有其他支持 IaC 的工具可用，其中之一是 Terraform，因其与 Power 平台的关系，我们将仔细研究。

IaC 部署是可重复的，并防止配置漂移或缺失依赖，因为所有基础设施的信息都在 IaC 文件中提供。 ARM、Bicep、Terraform 和其他 IaC 工具支持幂等操作。 这意味着即使我们多次应用配置，结果都将如描述的一样。 。

这也是 IaC 方法相比 ClickOps 方法拥有所有优势的主要原因之一。 那么，什么是 ClickOps？ 这个 术语 ClickOps 来源于 可点击的操作 ，它用于描述一种过程，其中人们在配置门户中点击不同的配置选项。 在 Power Platform 中，管理员通过 Power Platform 管理中心点击不同的选项来配置和 设置环境。

虽然可以通过 使用 用户界面 (UI) 自动化工具 或 机器人过程自动化 (RPA) 工具，结合一组记录下来的手动操作，ClickOps 通常容易出错。 要么工程师忘记某些步骤，途中犯错，或者网站发生变化，自动化 UI 方法失败。 这种方法也不具备可扩展性，因为它速度较慢，可能导致配置漂移，导致我们可能在不同的环境状态下 工作。

由于 IaC 代码可以进行版本控制，并且得到 SDLC 的支持，而可点击的方法缺乏这种协作 以及透明度。

使用 Terraform 进行 Power Platform 管理

我们 现在理解到，必须有一种更好的方式来自动化平台管理，这种方式比 ClickOps 方法更具可扩展性。 关于平台自动化和 DevOps 的关键设计领域，在 Power Platform 着陆区中提到了一个建议，即构建一个跨职能团队，该团队将构建和管理支持环境配置的功能，包括 DLP、RBAC 和其他能力。 该团队还将负责管理着陆区模板文件。 然而，我们也将看看另一种选择——使用 Terraform 构建 IaC 模板。 这样一来，使用 Terraform 文件，平台运维团队将负责环境配置、平台管理、计费和 DLP 策略创建。 这将帮助我们自动化环境管理任务，并逐步摆脱 ClickOps。

Terraform 是 由 HashiCorp 创建的 IaC 工具，使用声明式配置语言来配置和管理多云环境中的基础设施。 Terraform 使用的语言也被称为 HashiCorp 配置语言 (HCL)。 Terraform 由核心元素以及称为 提供程序的插件扩展组成，这些提供程序用于对各种云服务进行操作，包括 Azure 和 Power Platform。 要使用 Terraform，我们需要该工具本身和一个 Terraform 配置文件。 工作负载团队首先为 Terraform 文件的工作创建一个分支，该文件定义了基础设施和配置文件。 通常，我们将 IaC 配置分为 不同的文件：

• terraform.tf 是定义所有使用的提供程序、远程后端和应使用的 Terraform 版本的配置文件。 应该使用此版本。

• main.tf 将包括使用的资源和 数据源。

• variables.tf 描述了在 配置中使用的所有变量。

• variables.tfvar 用于指定不同环境的实际值。 我们也可以在 variables.tf 文件中定义具有默认值的变量，然而，这种方法在处理 不同环境时给我们带来了灵活性。

• output.tf 可以用于存储来自 已创建资源的输出变量。

在 配置文件编写完成后，定义核心 Terraform 工作流的三个主要步骤将应用此配置到云服务中，这也包括 Power Platform：

1. terraform.tf 配置文件提供。 在这里，将安装指定的提供程序。 启动此步骤时，我们使用 terraform init 命令。 此命令会创建一个 Terraform 锁文件，其中保存了该工作区中使用的提供程序信息。 如果我们希望在 不同环境中使用相同的提供程序版本，这个文件也可以进行版本控制。

2. main.tf 文件。计划将包括提供、更新或删除基础设施或其组件的步骤。在这一步，我们使用terraform plan命令。如果我们使用-out标志，计划将保存到文件中，这样我们就可以在需要时重新使用相同的计划。为了拥有一个灵活的 IaC 配置文件，我们建议将变量存储在main.tf外部的单独变量文件中。我们在variables.tf中声明变量并提供可选的默认值，其中单独环境的实际值通过variables.tfvars文件进行设置。

3. terraform apply 命令。

作为 DevOps 实践的一部分，建议将 Terraform 配置文件存储在源代码仓库中，以便进行协作和版本控制，并遵循分支策略以及拉取请求来合并更改。

如果我们希望删除已创建的基础设施，可以使用terraform destroy命令来清理资源。此操作将永久删除所有已创建的资源。为了保护生产工作负载免受意外删除的影响，我们可以在我们构建的资源的prevent_destroy = true的生命周期块中设置。

Power Platform Terraform 提供程序 是一个 Terraform 插件，允许管理 Power Platform 环境和额外资源，并遵循 IaC 方法。它定义了一组 Terraform 可以管理的资源和可以用来从 Power Platform 检索信息的数据源。通过使用 Power Platform 提供程序，组织可以遵循相同的方法，并利用现有的知识，以与现在为 Azure 服务所做的一样的方式来管理 Power Platform，使用 IaC 方法。这对于那些工作负载跨越 Power Platform 与其他云提供商（如 Microsoft Azure 云）边界的组织尤为重要。

这种方法有助于解锁在大规模部署和管理 Power Platform 的场景。它使我们能够以完全自动化的方式提供不同类型的环境，从而使开发人员在部署工作负载时更加灵活。

实验性功能

Power Platform Terraform 提供程序目前处于 实验模式 ，不应由生产环境用户使用。 然而，我们相信，未来这将成为平台运营团队管理大规模环境的关键能力之一。 。

使用 Power Platform Terraform 提供程序

此 提供程序 要求 Terraform 版本 >= 0.13 （考虑到提供程序的最新版本时）。 当前 Terraform 版本已经远超 1.8 版本，因此这一要求不应成为问题。 要启用这个 Power Platform 提供程序，我们需要将以下代码片段添加到 terraform.tf 配置文件中：

 terraform {
  required_providers {
    power-platform = {
      source = "microsoft/power-platform"
      version = "2.3.1-preview" # change to the latest stable version for your production workload
    }
  }
}

通过这样做，我们确保 Terraform 在运行 terraform init 命令时，会安装所需的提供程序，以初始化 工作区。

为了让 Terraform 访问 Power Platform，我们需要对提供程序进行身份验证，以便连接到 Power Platform。 我们可以使用 Azure CLI、带有 OpenID Connect 的服务主体，或带有客户端密钥的服务主体。 所有选项都要求我们首先执行 应用注册过程 在 Microsoft Entra ID 中，为 Power Platform Terraform 提供程序进行注册。 在应用注册过程中，我们需要授予 Dataverse、Power Apps 服务和 Power Platform API 的 API 权限。 Power Platform API 是一个预览功能，支持管理环境、计费策略、Power Pages 管理等功能。 如果我们通过 Azure CLI 进行身份验证，我们还需要在应用 Expose API 部分进行配置 注册过程期间。

API 权限 – 应用注册过程

Terraform 已经详细记录了在应用注册过程中应设置哪些 API 权限。 可以通过以下链接查看相关 API： https://registry.terraform.io/providers/microsoft/power-platform/latest/docs/guides/app_registration。

如果 Power Platform API 在我们可以授予 API 权限的 API 列表中没有出现，在应用注册过程中，我们可能需要通过以下 PowerShell 命令将其显示出来： 。

 Install-Module AzureAD
Connect-AzureAD
New-AzureADServicePrincipal -AppId 8578e004-a5c6-46e7-913e-12f58912df43 -DisplayName "Power Platform API"

AppId 是使用 Azure 公有云时 API 服务的值。 在任何其他情况下，它需要更新为正确的 AppId 值。

在此干预后，Power Platform API 应该会出现在列表中，我们 可以在应用注册过程中添加 API 权限，如 图 11**.10所示：

图 11.10 – Power Platform 提供者的 API 权限，用于 Terraform

应用注册过程 – Power Platform API

有关应用注册过程的更多帮助，请参考此 链接： https://learn.microsoft.com/en-us/power-platform/admin/programmability-authentication-v2。

另外，我们 可以着手准备 main.tf 文件和任何支持的 配置文件。 本书的示例 Terraform 文件已上传到 GitHub 仓库的 第十一章 文件夹中。

请注意，在计划使用 Terraform 管理 Power Platform 环境时，服务主体应作为应用用户添加到 Power Platform 环境中，以便能够对现有环境进行更改。 我们可以通过访问 Power Platform 管理中心 | 环境，选择环境并点击 查看所有 在 用户 下方的 访问 部分。 然后，点击 应用用户列表 | 新建应用用户 并使用向导将新创建的服务主体添加到 您的环境中。

在准备好所有 Terraform 配置文件后，我们现在可以执行工作流中的下一步操作：

 terraform plan -var-file dev.variables.tfvars -out <outfile>

如果计划 成功完成，我们应该会在终端看到更长的输出，显示所有的更改计划，最后是类似这样的内容（使用提供的 示例文件）：

 Plan: 2 to add, 0 to change, 0 to destroy. ──────────────────────────────────────────────────────────────
Saved the plan to: <outfile>

这里， <outfile> 表示上一步骤中输出文件的名称。 。

现在，我们可以使用以下命令，将计划应用到我们的环境中： 以下命令：

 terraform apply <outfile>

如果我们希望在 DevOps 流水线中执行这些步骤，由于我们希望在 CI/CD 流水线期间自动化这些步骤，我们可以在 Azure DevOps 中使用脚本任务或特定的 Terraform 任务，或者在 GitHub 中使用动作。 很可能，我们首先需要从可用的市场安装 Terraform 任务/动作。 安装完成后，我们将能够使用它们。 现在，我们可以创建一个 DevOps 流水线，在规划阶段，我们将使用 terraform plan 命令来准备 tfstate 文件，然后在部署阶段，我们将使用相同的 tfstate 文件将配置应用到 Power Platform 服务。

在创建 Terraform 计划时， tfstate 文件可以存储在本地，或者在某个中央存储库中存储，从中可以访问。 由于我们使用的是多阶段流水线和 DevOps 服务，我们决定使用一个 Azure 存储帐户，在其中存储 Terraform 状态文件。

在这里，我们有一个简单的单阶段 DevOps 流水线，我们使用 Terraform 任务来执行 Terraform 工作流的所有步骤。 在 GitHub 仓库中，我们已经上传了一个 simple-tf-iac.yml 流水线文件，它可以作为使用 Terraform 任务的 Azure DevOps 流水线的参考。 Terraform 任务的示例如下： 一个 Terraform 任务的示例是： 如下所示：

 - task: TerraformTaskV4@4
    inputs:
      provider: 'azurerm'
      command: 'init'
      workingDirectory: '$(System.DefaultWorkingDirectory)/tf-iac/'
      backendServiceArm: '<SERVICE_CONNECTION>'
      backendAzureRmResourceGroupName: $(test-rg)
      backendAzureRmStorageAccountName: $(storageaccountname)
      backendAzureRmContainerName: $(containername)
      backendAzureRmKey: 'terraform.tfstate'

尽管 IaC 带来了环境生命周期管理的好处，但每种方法总有利有弊，IaC 也不例外。 可能我们没有具备 IaC 和 Terraform 知识的资源，或者我们不想使用 Terraform Power Platform 提供者，因为它目前仍处于实验模式（不应在生产工作负载中使用），或者因为我们不想引入新的工具，或者其他任何原因。 在这种情况下，我们总是可以回归使用更传统的方式来管理 Power Platform 租户。

传统的自动化环境管理方法

除了 使用 Terraform 提供者的 IaC 方法外，还有其他选项可用来管理环境生命周期，以及与我们合作多年的 Power Platform 租户。 接下来我们将提到一些 示例：

• 到目前为止，我们已经熟悉了 用于 Azure DevOps 和 Power Platform Build Tools 以及 Power Platform Actions 工具 和 GitHub。

  Power Platform Build Tools 提供了可用于 Power Platform 租户管理的任务，包括环境管理。 我们可以创建新环境、配置治理设置和环境设置，例如将环境更改为托管环境，等等。

  采用这种方法可以让我们构建 DevOps 管道，重点不仅仅是提供应用程序解决方案，而是专注于配置端到端的解决方案生命周期，包括环境的配置、部署应用程序到环境中、测试应用程序，甚至在不再需要时移除环境。 这为整体 解决方案管理提供了额外的灵活性。

• 下一个选项是使用 PAC CLI。 我们可以将 PAC CLI 安装到运行 CI/CD 管道的构建代理/运行器上，并使用 PAC CLI 任务来执行自动化任务，管理环境生命周期。 通过命令行或 Bash 任务，我们可以编写脚本，利用 PAC CLI 执行操作，并在我们的 Power Platform 租户上执行操作。

• 对于那些希望在 CI/CD 管道之外构建自动化流的管理员，我们建议使用 Power Automate 流程并使用 Power Platform for Admins 连接器，该连接器专注于环境生命周期管理和 DLP 策略。 图 11**.11 展示了一个示例，属于更大的 创建已批准环境 流程的一部分，该流程属于 CoE 启动工具包。 它很好地展示了如何使用 Power Platform Management 连接器来构建环境 生命周期 并通过工作流执行：

图 11.11 – 使用 Power Automate 进行环境管理

管理环境时的 DLP 注意事项

在 Power Platform 着陆区部分，我们讨论了关键的设计领域以及在设计 Power Platform 架构时需要考虑的因素。 这包括在 Entra ID 中进行许可和身份管理，但有一个非常重要的领域，它与环境生命周期管理紧密相关。 数据丢失防护 （DLP）是保护数据不超出某些边界的最 重要部分之一。 DLP 策略帮助我们设置保护措施，确保我们的数据得到保护，并且不会与 不必要的受众共享。

在组织中创建环境策略时，我们还应就一组最基本的 DLP 策略达成一致，以保护用户免受不合规使用的影响。 这些策略可以在租户级别或环境级别设置。 租户级别的策略可以与所有环境或仅与特定环境关联，并作为跨 多个环境的组织范围政策。

设置 DLP 策略应在创建环境时自动完成。 也可以在根据工作负载或 组织需求调整策略后完成。

创建 和分配 DLP 策略有多种方式。 我们已经提到了两个例子，一个是使用 Terraform，另一个是通过 Power Automate 流程中的连接器。 这两者都支持创建和分配 DLP 策略。 在 Terraform 中，我们可以通过创建一个 powerplatform_data_loss_prevention_policy 资源，并通过一组参数，指定所有业务（敏感）、非业务（非敏感）、阻止和自定义连接器模式的列表。 这将定义哪些连接器被分组以及它们具有何种敏感性标签。 我们还可以指定应用 DLP 策略的环境列表。 这将定义该策略的适用范围。

在使用 Power Automate 时，我们通过创建使用 Power Platform for Admins 连接器的流，来实现相同的结果， 这些动作用于创建和管理 DLP 策略。 通过可视化体验，它们提供了所有 所需的信息。

图 11.12 – Power Platform for Admins 连接器

使用 Power Platform 的管理员连接器方法在管理环境和其他租户设置的过程中已经得到了很好的应用。 我们可以在许多属于 CoE 启动工具包的流程中找到这种方法。 让我们看看 CoE 启动工具包中有什么内容，以及它如何 被使用。

Power Platform CoE

另一个 部分专注于为 Power Platform 提供指导和最佳实践，将着重于采用和理解现有使用情况。 随着组织在 Power Platform 使用方面的成熟，运行在 Power Platform 上的工作负载数量可能会大幅增加。 组织应当投资于促进这种增长，同时保持环境的治理和安全。 本节将讨论 Power Platform CoE，它是什么，为什么组织应该在其环境中创建这样的团队。 我们将看看 CoE 团队可用的工具，并通过环境管理示例了解它如何 紧密相连。

CoE 超越了组织中的特定团队；它展示了组织中的文化承诺，帮助推动创新和持续改进。 CoE 团队充当一个知识中心，专注于提高 Power Platform 的采用率，同时确保使用符合内部治理和 合规标准。

CoE 团队可以由一个或多个人组成，这取决于组织的规模和成熟度。 它可以从组建一个充满热情的 Power Platform 个人团队开始，这些人致力于通过 LCNC 平台支持组织的业务战略。 从那里，它可以发展成一个更大、更具多样化的团队，由来自不同部门、拥有不同技能的角色代表。 它可以包括应用开发者、DevOps 工程师、IT 团队、支持工程师、培训专家和业务代表。 CoE 团队不应与融合团队混淆。 融合团队 专注于通过 LCNC 和以代码为先的开发加速业务解决方案的开发，而 CoE 团队旨在推动 LCNC 平台的治理和采用，遵循最佳实践 和指导。

CoE 团队遵循一个持续的流程，通过这个流程，他们能够了解当前的情况。 在需要的地方，他们会建立安全和治理实践来控制环境。 最后，他们通过帮助提升员工社区的采用率来支持员工群体。 为了促进他们的工作，CoE 团队利用了 Power Platform 管理中心的功能以及 CoE 启动工具包。

微软还 提供了自动化工具包，这是 CoE 启动工具包的补充工具套件，旨在提高 Power Automate 自动化平台的采用率。 该工具包提供了现成的解决方案，用于管理自动化项目，并且能够 深入了解节省的成本和估算的 投资回报率 （ROI） 。

CoE 启动工具包和自动化工具包的安装

设置 CoE 启动工具包和自动化工具包是一个较长的过程，包含多个步骤。 我们不会深入讨论安装细节，而是提供一个指向文档网站的链接，该网站提供了逐步的安装指南。 我们 建议按照该指南操作，并在 单独的环境中安装 CoE 启动工具包。

CoE 启动工具包 安装： https://learn.microsoft.com/en-us/power-platform/guidance/coe/setup。

自动化工具包 安装： https://learn.microsoft.com/en-us/power-automate/guidance/automation-kit/setup/prerequisites。

CoE 启动工具包

CoE 启动工具包提供了不同的模块，其中包括一套现成的应用程序和流程，旨在帮助管理员、治理和推广活动。 这些模块被分为 不同的组件：

• 核心组件：这是主要应用程序 CoE 管理员命令中心 所在的位置。 此应用程序是一个用于访问其他与管理员相关的应用程序的中央控制平面。 在这里，我们可以找到 设置应用权限 和 设置流权限 设置，用于发现应用程序和流并更改用户访问权限及 所有权权限。 此外， DLP 编辑器 有助于监督所有 DLP 策略，并了解哪些应用程序/流受到影响。 另一个重要的组件集是 与 环境 请求管理相关。

• 治理：该组专注于确保 Power Platform 组件得到治理并符合规定。 许多流是审核过程的一部分，审查应用程序、流和机器人状态，并通知管理员或所有者采取必要步骤，以确保其符合规定。 该组中包括 开发者合规中心 ，为开发者提供一个应用程序，以了解其应用程序、流、机器人、解决方案等的合规状态。

• 培养：该组中的组件致力于培养内部 Power Platform 社区。 组件如 视频中心，用于查找和观看培训视频内容， 为开发者提供的培养应用，用于查找培训活动，以及 解决方案评估 页面，在 为开发者提供的培养应用中，帮助开发者了解其计划解决方案的许可和治理影响。

• 主题管理：该组帮助创作者创建和管理画布应用的主题。 主题编辑器 和 主题库 允许创建和浏览已发布的主题，这些主题将在画布应用中使用。 在这里，我们想再次提到 Power Platform 创作者工具包，它不是 CoE 启动包的一部分，但从能力角度来看，它更为丰富，因为它支持使用 Fluent UI 框架，这将帮助组织在模型驱动应用和画布应用中创建一致的现代应用。

• 创新积压：这包含了 创新积压 用于添加创新想法和对现有想法进行投票的应用程序。

这些组件组每个都包含一组额外的表格、流程和应用程序，虽然我们没有提到这些，但它们支持整个 CoE 体验。 这些组件可以通过不同的方式使用。 我们可以仅使用 CoE Power BI 仪表板来全面了解 Power Platform 当前的状况，或者我们可以用它来驱动一些结论和行动。 通过仪表板，我们可以识别出，例如，孤立的应用，并采取措施重新分配所有权或在不再需要时将其淘汰。 我们还可以看到服务的采用情况，以及哪些连接器和应用程序使用最为频繁。 这些信息中的一部分也已经 可以在 Power Platform 管理中心 | 分析中找到，在这里我们可以追踪 Dataverse、Power Apps 和 Power Automate 的使用情况和活动。 有关 CoE 启动包及其组件的更多信息，请访问 此链接： https://learn.microsoft.com/en-us/power-platform/guidance/coe/starter-kit-explained。

环境管理示例

既然我们 已经通过 CI/CD 管道和在 Power Automate 中构建流程简要了解了环境管理的样子，我们接下来将看看 CoE 启动包如何支持环境 请求流程。

如果我们在 Power Platform 中配置了只有管理员可以创建环境的设置，那么对于普通用户来说，就无法为特定项目创建自己的开发环境。 他们应该使用现有的环境，这些环境可能会跨业务单元或组织共享，具体取决于组织的环境策略。 如果应用程序开发人员认为他们的项目需要隔离，那么他们应该申请自己的环境。 环境的创建可以通过 Power Platform 着陆区参考实现、通过 DevOps 管道自动化、通过 Power Automate 流程，或者手动进行。 然而，在所有这些情况下，管理员需要启动该过程，这使得他们成为整个过程中的瓶颈。 因此，在 CoE 启动工具包中，我们可以找到一个环境请求管理流程，帮助任何人申请新的环境和相关的 DLP 策略：

图 11.13 – 环境管理过程

使用 Maker - 环境请求 应用程序，应用程序开发人员可以提交新的环境请求。 他们选择所需的连接器以及所有者，并且 提供更多关于环境的信息，例如环境类型，是否需要 Dataverse，是否需要其他数据来配置环境。 请求提交后，由管理员来审核该请求。 通过他们的 Admin - 环境请求 应用程序，管理员可以审核所选择的连接器，检查是否有 DLP 策略影响了选择的连接器，并且需要对 DLP 策略做哪些修改。 一旦管理员审核并批准创建过程，Power Automate 流程中的 Power Platform for Admins 连接器开始工作，收集所有数据，并配置一个环境以及相关的 DLP 策略。 如果该环境设置了过期日期，环境将在此日期后自动删除，除非环境的所有者在此之前申请延长过期日期。 对于环境的删除，再次使用 Power Automate 流程中的 Power Platform for Admins 连接器来移除 该环境。

这展示了一个现实世界的例子，说明 Power Platform 运维团队如何通过应用程序和 Power Automate 流程的结合来设置环境生命周期管理过程。 借助 CoE Starter Kit，我们已经获得了这样的流程，任何人都可以重用它们，同时也可以作为一个参考，供组织在想要构建自己的平台管理流程时使用。 管理流程。

总结

在本章中，我们主要集中在 Power Platform 管理的运维部分。 我们详细介绍了不同的设计最佳实践和指南。 我们从 Power Platform Well-Architected 开始，了解了它的目的在于设计具有韧性、可靠性和高效性的应用程序工作负载，并为用户提供出色的用户体验。 接着，我们讨论了 Power Platform 着陆区，帮助管理员创建所需的环境，遵循经过验证的架构设计，并允许组织快速扩展以支持数字化转型的努力，同时为应用开发者提供创新的空间。 我们研究了运维团队在规划 架构设计时应考虑的设计原则和设计领域。

从设计最佳实践开始，我们转向了其中一项建议的实际实施——平台自动化。 我们尝试了一个想法：如果一个低代码/无代码平台，比如 Power Platform，结合来自专业开发领域的基础设施描述概念，那会是什么样子？在这个领域中，基础设施工作负载和系统配置通常是通过 IaC 文件来编写的。 我们使用 Terraform 演示了如何创建 IaC 文件，并利用 Terraform 来管理 Power Platform 环境。 由于 Power Platform Terraform 提供者仍处于实验阶段，且组织可能更倾向于使用其他方式来管理环境，我们研究了其他工具如何帮助我们解决这个挑战，包括在 Power Automate 中使用 Power Platform for Admins 连接器，这也是 CoE Starter Kit 中管理流程的常用工具。 从一个非常高层次的角度，我们简要介绍了 CoE 是什么，以及 CoE Starter Kit 为组织带来了哪些工具。 通过一个环境管理请求的例子，我们展示了这些最佳实践如何在 现实生活中得以实施。

在下一章节中，我们将超越 DevOps，探索生成式 AI 给 Power Platform 带来的创新。 我们将探讨如何 ChatOps 连接人、流程和工具，并改善我们进行 DevOps 过程的方式。

进一步阅读

• Power Platform 着陆 区域： https://github.com/microsoft/industry/tree/main/foundations/powerPlatform

• Power Platform 良好架构： https://learn.microsoft.com/en-us/power-platform/well-architected/

• 微软零信任 模型： https://www.microsoft.com/en-us/security/business/zero-trust

• Terraform 文档： https://developer.hashicorp.com/terraform

• Power Platform Terraform 提供者： https://playbook.microsoft.com/business-applications/Enterprise-Solutions/Power-Platform-Terraform-Provider/

• Power Platform for Admins 连接器： https://learn.microsoft.com/en-us/connectors/powerplatformforadmins/

• Power Platform CoE： https://learn.microsoft.com/en-us/power-platform/guidance/coe/starter-kit

• Power Platform 自动化 工具包： https://learn.microsoft.com/en-us/power-automate/guidance/automation-kit/overview/introduction

第十二章：展望未来：与 Copilot、ChatOps 以及 AI 赋能应用一起前行

我们目前正处于一个时代，在这个时代，构建增强型应用程序变得非常简单，应用人 工智能（AI）已经成为一种常态。 将大 型 语言 模型（LLMs）接入我们的应用程序，并为其赋能 AI，正在开启新的选择，并使得组织能够创新并重新定义其业务流程。 本章将通过讨论 AI 赋能的低代码/零代码开发方法结束本书。 随着 LLM 的引入，如 OpenAI 的生成预训练转换器（GPT）模型，我们已经见证了在帮助创作者和开发者更高效完成工作并更快实现结果的工具上的巨大变化。 Microsoft Copilot 正在将 AI 注入每一款 Microsoft 产品，帮助创作者和开发者通过使用自然语言描述所需状态，利用零代码方法构建更多应用程序。 我们将深入探讨 Power Platform 中的 Copilot，以及 Copilot 如何在 Power Platform 产品中得到应用。 我们将查看 AI Builder 的功能，并了解如何通过使用自定义连接器，利用 Azure OpenAI 模型扩展 Power Platform 的能力。 本章将以讨论 ChatOps 作为结尾。 我们将探讨它如何丰富现有的 DevOps 流程，以及如何使用 Copilot Studio 来帮助我们在组织中实施 ChatOps。

我们将涵盖以下 主要话题：

• AI 时代与 GPT 的崛起

• Microsoft Copilot 与 Power Platform 中的 Copilot

• 从创作者的角度看 Copilot 的使用

• 通过 AI Builder 和 Azure OpenAI扩展业务解决方案

• ChatOps 与 Copilot Studio

技术要求

要跟随本章内容，我们建议提前准备以下要求： 以便更好地进行学习：

• Power Platform 订阅：我们可以注册 Power Platform 开发计划（https://powerapps.microsoft.com/en-us/developerplan/），如果我们已经拥有 Microsoft Entra ID 工作帐户，或者我们可以加入 Microsoft 365 开发者 计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。

• Azure 订阅：我们可以按照以下指南申请一个免费的 Azure 账户 https://azure.microsoft.com/en-us/free。一旦创建，Azure 门户可以通过以下链接访问 ： https://portal.azure.com/。

• Azure DevOps 服务组织：我们可以随时创建一个 DevOps 组织，免费使用（https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates）。

• GitHub 用户名和一个代码仓库：作为创建 DevOps 组织的替代方案，我们可以注册一个免费账户（https://github.com/signup）。 要访问 GitHub 企业云，我们可以获得一个 30 天的试用版（https://docs.github.com/en/enterprise-cloud@latest/admin/overview/setting-up-a-trial-of-github-enterprise-cloud）。

• Microsoft 365 或 Teams 许可证：要访问 Teams，需要一个 Microsoft 365 试用许可证或 Teams 许可证。 我们可以使用 Teams 试用版（https://learn.microsoft.com/en-us/microsoftteams/teams-exploratory）。

• Visual Studio Code：你可以选择使用其他的 IDE 或文本编辑工具。

人工智能时代与 GPT 的崛起

本节将 提供一个宏观视角，回顾我们如何走到今天，在这个阶段，AI 创新几乎已经成为一种商品。 我们将探索那些震撼世界并对社会和全球产业产生巨大影响的 GPTs。 现在，应用程序开发者甚至可以在 Power Platform 服务中使用这些 GPT 模型来提供商业解决方案，但我们稍后会详细讨论。 让我们首先从 开始讲起。

GPT 已经在市场上存在了一段时间。 它们已经颠覆了市场，带给人们一些恐惧，但也带来了创新的新思路。 由于每个人都可以访问这些模型，任何人都可以利用 AI 创新并构建鼓舞人心的解决方案。 这意味着，使用公开可获得的大型语言模型（LLM）构建的 AI 的竞争优势已经下降。 这促使公司在如何将这项新技术应用于商业流程方面进行创新。 然而，就像任何项目一样，在 AI 融入的项目中，如何快速将一个可靠且安全的解决方案推向市场也非常重要。 在这里，创新和开发应该遵循 DevSecOps 流程，这些流程允许组织将可靠的解决方案带入 市场。

为了理解当前的情况，我们需要回顾 过去。

人工智能简介

人工智能是一个智能 计算机系统，它利用数学算法和统计模型来模拟人类思维，在分析数据时做出决策。

1955 年，计算机科学家约翰·麦卡锡提出了“人工智能”（AI）这一术语。 这个术语描述了能够展示类似人类智慧的机器的概念。 然而，人工智能的起源甚至可以追溯得更早。 1940 年，艾伦·图灵创造了一种机器学习算法， 该算法被用于破解恩尼格码密码。 这导致了 图灵测试 的产生，后者出现在 1950 年。 这个测试用于判断机器在特定条件下是否能够模仿人类智能。 经过这么多年，AI 专家们现在辩论图灵测试是否仍然相关，因为 AI 模型和自然 语言理解的进展。

简单来说，人工智能背后是计算机科学和工程领域，它们创造出各种算法，驱动这些 AI 系统的运行。 算法被描述为 AI 系统按照一定规则和程序化指令处理和分析数据的一系列步骤。 这些算法可用于情感分析、物体检测等任务。 AI 模型遵循算法，并通过在大规模、具有代表性的数据集上进行训练，以便利用这些算法来解决特定的任务 或问题。

一旦 AI 模型在具有代表性的数据上训练完成，它就能理解数据中的关系，从而能够将所学应用于新的、未知的数据。 这种训练 AI 的常见做法是 在 机器学习中进行的。我们用于训练的更多数据和多样化的数据，训练出的模型效果就会更好。 例如，用更多的物体图片训练物体检测模型，并提供每张图片的准确描述信息，将导致该模型的更好效果。

AI 使计算机系统能够执行在许多应用中都有用的任务。 通过 自然 语言 处理 （NLP），这是机器学习的一个子领域，系统现在可以理解人类语言，并执行诸如语言检测、语言翻译和情感分析等操作。 通过扩展到语音，微软声称他们在 2016 年达到了人类对话语音识别的水平。 通过加入计算机视觉，借助 AI 的支持，机器甚至能够理解 视觉物体。

机器学习还有其他子集，如 强化学习 以及更进一步的 神经网络。神经网络是一种受人类大脑功能启发的模型。 神经网络由神经元组成，神经元是相互连接的节点，按层次分组。 神经元接收输入，这些输入用于计算函数，以确定数据将被发送到下一层哪个神经元。 神经网络可以用于非常复杂的 数据关系。

人们可能会问，为什么我们要讨论这些模型。 嗯，这就是 GPT 的作用所在。 它来了。

GPT

AI 在 过去几年中的进展带来了生成式 AI。 生成式 AI 是一种使用 LLM 的 AI 类型。 生成式 AI 能够通过生成文本、图像、语音，甚至视频来响应提示并生成新内容。 有许多 LLM 可用；然而，其中最具代表性的是 GPT，得益于 OpenAI 的 ChatGPT的流行。看到某些技术需要多长时间才能达到 1 亿月均活跃用户，总是令人着迷。 ChatGPT 只用了 两个月就达到了 1 亿月均活跃用户。 这也表明，新的创新解决方案正在缩短达到这一 重大里程碑所需的时间。

GPT 是 LLM 或文本生成模型的一部分，能够生成新内容（因此， 生成式），已在大量数据集上进行训练（因此， 预训练），并使用神经网络处理输入请求并提供输出（因此，变压器*）。

如前所述，许多 LLM 可用，其中包括已向开源社区开放的模型。 目前，最著名和流行的 GPT 包括 OpenAI 的 GPT。 OpenAI 还提供了其他模型，这些模型用于各自的特定目的。 随着每个新版本的发布，我们可以看到 GPT 变得更加复杂和智能。 2024 年 5 月，OpenAI 推出了 GPT-4o，也被称为 omni，这是一个多模态模型，接受文本和图像作为输入，并可以生成文本作为输出。 在发布会上，OpenAI 强调了新的 GPT-4o 模型如何通过音频、视觉和文本与用户进行交互。 OpenAI 还展示了一种新模型，它能够 将文本转化为 视频，名为 OpenAI Sora，并于 2024 年 2 月发布。

当前已经可用的其他模型包括 以下几种：

• GPT-4 Turbo、GPT-4和 GPT-3.5 Turbo 是 可以 理解自然语言指令并生成自然语言 或代码的模型

• DALL-E (文本到图像) 是 用于根据提供的自然语言指令生成图像的模型

• Whisper 是一个模型 用于将音频转换成文本

虽然 LLM 为生成 AI 铺平了道路，但我们也看到了小型语言模型的出现。 由于训练数据规模较小，这些模型体积较小，但能够在设备上本地运行，这为组织带来了新的创新思路。 。

AI 模型需要数据、AI 算法或模型以及大量的计算能力来运行。 微软与 OpenAI 合作，并开放 Microsoft Azure Cloud 供 OpenAI 利用其计算能力进行新模型的研发。 作为回报，合作规定 OpenAI GPT 模型独家在 Microsoft 平台上提供。 它们可以作为 Azure OpenAI 服务的一部分提供使用。 这使得已经在使用 Azure 或希望使用 Azure 的客户可以利用安全合规的平台构建利用 AI 能力的安全企业应用。 这项合作使得 Microsoft 能够将 OpenAI LLM 集成到其自己的产品中，并构建新功能以提升用户生产力。 这样一个产品的良好示例是 GitHub Copilot，它 就像一个 AI 的编程伴侣。 它帮助开发人员在使用诸如 Visual Studio、Visual Studio Code、JetBrains IDEs 和 Neovim 等 IDE 时理解和生成代码。 这种合作的另一个例子是为 Microsoft 产品和服务提供各种副驾驶的集成，这些副驾驶集成到各种工具中，通过帮助用户更快地实现结果，从而丰富用户体验。 更有效地。

负责任的 AI

随着 AI 的进步，对其潜在误用的担忧变得合理。 因此，负责任地使用 AI 至关重要。 微软以及其他公司、社区和个人已经意识到这一点，并开始积极倡导负责任使用的必要性。 微软在内部进行了重大投资，以确保其 AI 系统设计具有责任感。

微软已制定 其 负责任 AI 标准，该标准为确保组织负责任使用 AI 提供了实际指导。 它由六项负责任的 AI 原则定义，将指导 AI 的开发 和使用：

• 公平性: AI 系统应当平等对待所有人，不带偏见 或歧视

• 可靠性和安全性: AI 系统应当可靠运行，并优先考虑安全，以防止 不良后果

• 隐私和安全: AI 系统应当确保安全并通过保护 用户数据

• 包容性: AI 系统应当吸引广泛的用户，并通过考虑 多元化的视角

• 透明度: AI 决策和过程应该是可以理解的，并提供清晰的解释以便 提高信任

• 问责制: 开发者 和组织应对所开发的 AI 系统负责

除了负责任的 AI 原则之外，我们还应确保 AI 系统的开发符合合规性并遵循治理方式，以确保符合当地的监管要求。 微软更进一步，实施了一个五点蓝图，专注于治理 AI。 这些原则确保 AI 的使用符合政府的 AI 安全标准，并且是负责任的。 它们还确保我们保持对 AI 系统的控制，以便 AI 可以 安全使用。

微软已将 负责任的 AI 实践不仅融入了协助工具，还融入了其他工具和人们的文化中。 他们这样做是为了促进 AI 的安全和负责任使用。 AI 的使用。

微软协助工具与 Power Platform 中的协助工具

微软已在多个微软产品中嵌入了协助工具 以支持不同的场景。 本节将首先解释什么是协助工具，然后介绍一些可用的协助工具及其如何使用。 接着，我们将重点了解协助工具在 Power Platform 中的能力。

Microsoft 使用“copilot”一词来描述能够检索信息并执行特定任务（如摘要和内容生成）的 AI 助手。 Copilot 利用 LLM，例如 OpenAI 的 GPT 模型，来响应用户的提示。 并非所有 Copilot 的行为都相同。 一些 Copilot 较为通用，例如 Microsoft Copilot，而其他则是特定产品的，例如 Microsoft 365 的 Copilot 或 Power Platform 的 Copilot。这些 Copilot 在特定产品的上下文中运作，并且能够了解该产品中的数据和操作。

所有这些 Copilot 都共享与用户的共同对话式聊天体验。 然而，当我们查看这些 Copilot 时，我们可以看到一些 Copilot 是集成到产品本身中的，它们的主要任务是支持用户在使用特定产品时提高生产力，例如 Power Platform 中的 Copilot。 其他 Copilot 也是特定于产品的，例如 Microsoft 365 的 Copilot 或 Sales 的 Copilot，它们具有一组标准功能，包括 Copilot 组件，但也可以通过 Copilot Studio 的支持进行扩展。 最后一类 Copilot 是自定义 Copilot，用户可以在 Copilot Studio 或使用 Azure AI 服务上自行构建，并通过不同渠道向 用户提供。

Copilot 的示例包括 以下内容：

• Microsoft Copilot：这款工具使用 OpenAI LLMs 来为用户的提示提供类似聊天的响应体验。 它可以在网络上搜索结果，并能总结针对特定问题的回答，同时提供相关 内容来源的链接。

• Microsoft 365 的 Copilot：这个工具 生成基于用户有权限访问的组织数据的响应。 它利用 Microsoft Graph 和 LLMs，并集成于 Microsoft 365 套件（Word、Excel、Teams 等）中，旨在提升 个人生产力。

• GitHub Copilot：这是一款 AI 配对程序员或代码补全工具，帮助开发人员在软件开发生命周期（SDLC）中。 它主要围绕编码相关话题，因此可以提供代码建议、解释代码、构建单元测试、 等等。

Power Platform 中的 Copilot

AI 在 Power 平台中已经存在了几年。 2019 年，AI Builder 被引入 Power 平台，帮助将 AI 模型融入到业务流程中，并丰富了应用和流程。 2021 年，Power Apps 中推出了将自然语言提示转换为 Power Fx 函数的功能。 从那时起，新的 AI 功能每年都不断加入到 Power 平台中。 每年都有新的进展。

在 Power 平台中启用 copilot 功能将平台带入了无代码开发的领域，并且得到了 AI 的辅助。 这意味着，无论我们是专业开发者、低代码应用开发者，还是刚开始学习使用 Power 平台的人，Power 平台中的 copilot 都能提供通过自然语言生成有意义的面向业务的解决方案的能力。 这有助于开发者和组织节省时间并 提高生产力。

Power 平台家族中的每个产品都包括其专属的 copilot。 这些 copilot 作为 AI 助手，具备产品特定的功能，可以作为开发者或业务解决方案用户使用， 并在 Power 平台上构建。

Copilot 已集成到产品中，并始终共享产品的主屏幕，这使得 开发者或用户在解决方案工作时更加高效，因为它不需要他们离开当前工作 的上下文。 工作环境：

• Power Apps 中的 Copilot：这使得 开发者可以通过自然语言描述来构建新的应用或编辑现有应用，并编写或理解 Power Fx 函数。 作为用户，我们可以在应用中使用 copilot 组件，帮助我们获取有关应用中数据的答案。

• Power Automate 中的 Copilot：使用这个功能，开发者可以创建新的流程，并通过自然语言描述所需的连接器。 我们还可以修改现有的流程，并为业务流程获得灵感。 很快，我们将能够构建 AI 流程，LLMs 将创建动态的自动化流程，并通过语音记录指令利用多模态模型，构建 Power Automate 桌面流程。 用户能够深入了解由 Power Automate Process Mining 分析的流程。

• Copilot Studio 中的 Copilot：开发者 可以通过对话式构建器创建新的自定义 copilot，还可以使用 自然语言创建和修改主题。

• Power Pages 中的 Copilot：此功能 促进了外部网站和页面的创建，允许我们通过自然语言聊天界面添加表单、文本内容和 AI 生成的代码。 用户可以利用定制的 Copilot 聊天体验和通过生成式 AI 丰富的搜索体验进行推理， 从搜索结果中获取信息。

• Power BI 的 Copilot：此功能 有助于构建跨云服务和 Power BI Desktop 的报告页面。 作为用户，我们可以获取有关模型中数据的问题答案，获取报告摘要， 以及更多内容。

Power Platform 中的 Copilot – 预览功能

需要注意的是，Power Platform 中的一些 Copilot 功能仍处于预览阶段。 这些功能不适用于生产环境。 为了访问这些功能，我们可能需要将环境 设置为 提前发布周期 (https://learn.microsoft.com/en-gb/power-platform/admin/early-release)。 我们可以使用沙盒环境，并通过 预览 URL (Power Apps: https://make.preview.powerapps.com/) 或通过启用 体验新的数据体验 在 Power Apps 主页屏幕中。

一些 Copilot 的配置设置可以在 Power Platform 管理中心 | 设置中打开或 关闭租户设置，我们可以根据组织的政策找到可以启用或禁用的配置设置，正如在 图 12**.1中所示：

图 12.1 – 在 Power Platform 中启用或禁用 Copilot

这些 设置 包括启用数据收集、用户发送反馈的能力，以及在 Power Apps 中启用或禁用 Copilot 预览功能的能力。

从创建者角度看 Copilot 的使用

在本节中，我们 将了解如何在 Power Platform 中使用助手生成带有数据表的 Power Apps 画布应用，并通过 Power Automate 中的流进行支持。 这展示了 AI 如何帮助应用开发者在低代码开发过程中获得额外支持，并转向 无代码方法。

在 Power Platform 中使用助手的好处之一是，这种方法使开发者能够更快速地构建解决方案原型。 这是因为原型不需要具备应用的所有功能，只需要提供概念的外观和感觉。 借助 Power Platform 应用中的助手，开发者可以使用自然语言描述构建应用或流的模型，并快速验证业务应用构思的可行性。 对于助手提供的每个建议步骤，我们可以通过点击撤销 按钮撤回助手所做的更改。 这使得测试想法变得更加容易，并且在不满意建议的工作时可以快速恢复。

Power Platform 中的助手具有相同的用户体验。 在该服务的首页，我们可以找到一个大型文本输入组件，允许我们添加想要执行的操作描述。 我们写给助手的提示应该清晰且具体，因为这将帮助助手返回更相关的结果。 为了使用助手获得更好的结果，我们应提供更多关于请求的上下文，或者在需要时，提供一些如何实现某个功能的示例：

图 12.2 – Power Platform 首页上的助手

在 Power Apps 首页（https://make.powerapps.com/）上，我们将首先描述我们希望构建的应用程序的构思。 由于几乎所有的业务应用都依赖于数据，助手将开始在 Dataverse 中创建一个数据架构，作为我们的数据源来管理数据。 在这个步骤中，助手会提取我们提示的上下文 并根据输入开始创建一个 实体关系图。

我们可以使用提示建议来更改数据架构、添加更多表格、配置它们之间的关系、向表格中添加更多测试数据等等。 此时， 查看提示 按钮作为提示指南，提供了 Copilot 可以执行的操作建议。 这些操作包括创建表格和关系、修改表格和列，并作为灵感提供基于当前数据 架构设计的建议：

图 12.3 – 丰富数据模型创建

一旦我们点击 保存并打开应用，Copilot 将使用此数据架构创建一个示例应用 ，该应用具有多个屏幕，包含表单用于操作表格，同时也有一个独立的欢迎屏幕，可作为屏幕之间的导航 。

在 Power Apps Studio 中，我们可以利用 Copilot 提问，了解如何在 Power Apps 中实现某些功能。 它利用 Bing 搜索来查找相关内容，并为我们提供指导。 例如，我们可以提问“如何将图片添加到图像组件？”它会提供与问题相关的回答。 在这种情况下，它会提供逐步的指导，教你如何实现此操作，并提供相关的文档链接，解释整个过程。 我们可以要求它向屏幕添加特定的组件，如按钮或文本标签，但此时我们可能仍然需要手动完成一些任务，因为它尚不能完成 所有任务。

构建 Power Fx 公式有时会很具挑战性，特别是对于第一次使用 Power Platform 的人。 类似于 GitHub Copilot 的功能，为了支持开发人员，现在我们可以使用自然语言的注释来生成 Power Fx 公式。 它也可以反向工作，帮助理解公式的作用，只需点击公式框旁的 Copilot 图标，然后选择 解释 此公式：

图 12.4 – 使用 Copilot 提供 Power Fx 公式建议

作为开发人员，我们还可以直接在 Power Apps Studio 中查看代码。 通过选择屏幕或组件旁边的三个点（或右键单击），我们现在可以看到一个 查看代码（预览） 选项，显示所选部分的 YAML 格式代码。 这使我们可以复制代码并与其他开发人员讨论，直接修改代码，甚至使用复制/粘贴将此部分放入另一个屏幕 或应用程序中。

如果我们转向 Power Automate，Copilot 也可以帮助我们完成类似的任务。 这意味着使用自然语言描述我们希望创建的流程，并对现有流程进行修改，例如向流程中添加操作、配置操作的参数， 等等。

随着人工智能的进步，我们很快就能构建 AI 流程，AI 将决定如何构建一个自动化计划，并满足实现要求所需的所有条件。 我们也很快能够使用语音记录构建 Power Automate 桌面流程的指令。

图 12.5 – Power Automate 中的 Copilot

我们必须记住，目前一些 Copilot 功能仍处于预览阶段。 从 DevOps 的角度来看，我们当前能看到一个主要问题，那就是在 解决方案级别上，并未启用使用相同构建方法的能力。

我们在 第四章 中提到，我们应该从解决方案资源管理器内部开始构建我们的 Power 平台组件。 在那里，我们可以使用现有的解决方案或创建新的解决方案，因为解决方案使我们能够在不同环境之间移动应用程序并管理解决方案组件所需的依赖项。 当前的开发方法是从设计体验开始，而不是从解决方案资源管理器开始。 这种方式，通过 copilot 的初始设计体验创建的所有组件都将添加到 默认解决方案 并处于未管理状态。 目前，用于构建业务应用程序的 copilot-first 方法不支持从解决方案开始，这使我们只能选择将现有组件添加到新解决方案，并确保将所有必需的依赖项添加到解决方案。 但是，如果我们希望从手动创建 custom copilot 开始，我们可以首先创建一个解决方案，然后从那里创建新组件（如 Power Apps 应用程序）。 我们 希望 copilot 在初始创建应用程序和其他组件方面的体验也可以通过 解决方案方法启用。

通过 AI Builder 和 Azure OpenAI 扩展业务解决方案

现在，我们已经看到 AI 如何帮助我们构建 Power 平台组件，接下来，我们将寻找将 AI 能力融入我们的应用程序和流程中的方法。 本节将介绍 AI Builder 的能力，并比较它与 Azure OpenAI 的区别。 我们将看看如何设置自定义连接器以连接到 Azure OpenAI，在这里，我们将使用我们选择的 Azure OpenAI 模型来丰富用户体验或改进我们在 Power 平台中的业务流程。 Power 平台。

介绍 AI Builder

AI Builder 是一个 Power 平台服务，允许制作者在其解决方案内使用不同的 AI 模型和提示，无需编码或特殊的数据科学知识。 它允许组织通过添加额外的 AI 能力来改善其业务流程，这可以帮助自动化手动和重复的任务，并帮助实现更好的结果。

它可以通过 Power Fx 公式或使用 AI Builder 组件集成到 Power Apps 应用程序中。 通过使用 AI Builder 动作，AI Builder 还可以在 Power Automate 工作流中使用。 我们还可以选择在 Copilot Studio 内的插件中使用其功能。

AI 模型

AI Builder 提供了一套预构建的模型，这些模型在许多业务流程中得到了广泛应用。 当我们需要更符合数据特定需求的自定义模型时，可以创建自定义模型，并在 自定义数据集上进行训练。

AI 模型可以根据它们使用的数据类型进行分组。 这些组可以同时包含预构建模型和 自定义模型：

• 文档处理：该组包含发票处理、文本识别、作为自定义模型的文档处理以及一个 名片识别器

• 文本处理：在这里，我们可以找到用于文本处理的模型，如关键词提取、情感分析、语言检测和 类别分类

• 图像处理：提取图像信息的模型，例如图像描述生成图像或物体检测的模型， 都可以在此找到

• 结构化数据处理：目前只有一个自定义模型能够使用数据进行预测并预测结果 。

每个模型都有其自身的特点和要求，以获得最佳结果。 要了解更多关于每个具体模型的信息，我们建议阅读以下 文档： https://learn.microsoft.com/en-us/ai-builder/model-types。

使用预构建模型时，我们无需进行任何特殊配置——它们是即开即用的，不需要任何训练。 我们可以使用组件或连接器操作，将其指向数据并接收输出。 在使用自定义模型时，我们构建的是一个特定于某个业务领域的模型。 它必须先使用历史数据进行训练，才能完成特定任务。 对于文档处理，我们 需要 至少五个具有相同布局的示例，才能准确训练一个 模型。

AI 提示

AI 提示使得开发者可以构建指令，告诉大语言模型（LLM）需要执行的任务。指令越精准，任务的结果就会越好。AI Builder 提供了预构建的提示，可以更快速地将这些指令应用于 GPT，例如文本摘要、文本分类、情感分析、草拟回复等任务。然而，就像以前使用 AI 模型一样，开发者仍然有机会创建自定义 AI 提示。在提示工程的帮助下，我们可以提供指导 GPT 模型达到预期结果的指令。需要注意的是，指令的质量会直接影响输出结果。AI 提示允许我们提供输入变量和 Dataverse 数据，从而创建高度动态并与我们业务流程相关的提示。

AI Builder 目前使用 GPT-3.5-Turbo 或 GPT-4（预览版）进行 AI 提示的处理。这些都是由 Azure OpenAI 提供支持的。

创建提示非常重要，而且还有其他参数决定了模型的行为，例如模型选择和温度设置，因此了解如何构建 AI 提示是一个好主意，可以通过以下链接了解更多：learn.microsoft.com/en-us/ai-builder/create-a-custom-prompt。

为了安全起见，我们建议在将响应用于重要的业务流程之前，先对其进行人工检查，以防错误或无关的响应带来危害或负面影响。

使用 AI 模型和 AI 提示

我们可以从AI Hub开始创建 AI 模型或 AI 提示：

1. 在 Power Apps 或 Power Automate 中，我们可以在左侧导航菜单中找到 AI Hub。如果暂时找不到，可以在更多中找到并将其固定到左侧导航栏，或者通过访问更多 | 发现所有，在其中找到AI Hub并将其固定到左侧导航菜单。

2. 一旦进入 AI 中心，我们可以开始构建 AI 提示和模型。 在那里，我们还可以找到一个文档自动化解决方案，结合 RPA 流程和 AI，从各种文档中提取信息，并继续执行文档 处理工作流。

3. 从 AI 提示开始 – 在 AI 中心，选择 提示。在这里，我们将看到所有预构建提示的列表，并有选项创建自定义提示 与 GPT。

   AI 提示由 提示组成，应该准确清晰，还有 提示设置。我们可以配置多个输入变量并将其添加到提示中，使其高度动态。 我们可以使用 Dataverse 中的数据，进一步为 GPT 模型提供知识来源。 输出可以是文本或 JSON，有时后者可能更合适，因为我们对展示层有更多控制。 在 设置中，我们可以选择我们想要使用的模型和温度设置。 来使用。

4. 现在我们已经创建了 AI 提示，可以将其添加到我们的应用程序或流程中。 在 Power Apps Studio 中开发画布应用时，我们可以在 数据 部分找到 AI 提示或 AI 模型。

5. 在左侧导航栏中，点击 数据 | 添加数据，这会打开一个选项以选择数据源。 在这里，我们可以使用搜索栏找到我们的 AI 提示或模型并将其添加 到 我们的应用程序中：

图 12.6 – 将 AI 提示添加到画布应用程序中

1. 为了使用 AI 提示或 AI 模型，我们将通过 Power Fx 函数来触发它：

    Set(varComplaint, 'Example - Custom prompt Complaint Accommodation'.Predict(txtComplaint.Text,txtApartmentName.Text))
   

在前面的代码中，我们可以看到一个 Power Fx 函数的示例，它将 AI 提示的响应存储为一个变量，之后可以根据我们的业务流程在应用程序中使用该变量。 在 Power Apps 中，我们可以找到专注于特定 AI 模型的 AI Builder 组件，并可以通过组件将其实现到应用程序中，以启用一些额外的功能，如收据和表单处理器、物体检测等。

在 Power Automate 中添加 AI 提示和 AI 模型与添加任何其他操作一样简单，只需在 工作流中进行添加：

1. 在 Power Automate 设计器中，工作在我们的工作流时，点击 添加操作 在我们希望添加 AI 能力的地方。

2. 搜索 AI Builder 并从列表中选择一个模型或提示类型。

3. 首先选择模型类型，然后在下一步中，可以将一个连接器操作链接到我们的模型 或提示。

   与前面提到的示例相关，我们使用了自定义 AI 提示，我们可以通过以下 Power Automate 操作找到我们的自定义 AI 提示： AI Builder | 使用 GPT 创建文本，使用 提示。

4. 我们对连接器进行身份验证，并在 参数 | 提示中，从列表中选择我们的提示。

5. 我们提供必要的输入，并继续构建 我们的工作流。

在任何后续 操作中，我们 将能够使用前一操作的输出，这对于 AI Builder 操作也是相同的。 举个例子，在 图 12**.7中，我们正在使用由 GenAI 构建的生成的投诉回复的输出，在 审批 操作中，允许审核人员审查生成的投诉回复是否恰当。 如果是，我们将投诉消息发送给 客户：

图 12.7 – 将 AI Builder 与 Power Automate 集成

重要说明

从 使用 打包我们业务应用程序的解决方案的角度来看，我们需要记住 AI 模型和提示不被视为应用程序的依赖项。 我们需要手动将 AI 提示和模型添加到我们的解决方案中，以便与应用程序 或工作流配合使用。

此外，AI 模型和提示使用 AI Builder 学分。 不同的模型类型消耗不同数量的学分，因此请确保查看许可指南（https://go.microsoft.com/fwlink/?linkid=2085130）以更好地了解您的项目的学分使用情况。

AI Builder ALM

每当我们 创建一个定制的 AI 模型或 AI 提示，我们希望在不同环境中重复使用时，我们可以应用已经在前几章中介绍过的应用生命周期管理原则，与其他 Power Platform 组件一样。

由于无法从解决方案资源管理器中创建 AI 模型或提示，首先需要使用 AI Builder 创建一个定制的 AI 模型或 AI 提示，在那里我们可以使用我们的数据集训练 AI 模型或构建定制的 AI 提示。 我们建议遵循环境策略，在开发或沙盒环境中开发定制模型，然后将其部署到其他目标环境。 一旦模型训练完成，我们需要发布它，以便将其添加到 解决方案中。

由于该模型不被视为应用程序或流程依赖项，我们需要手动添加定制的 AI 模型或 AI 提示以及将要使用它的应用程序或流程。 在此阶段，我们准备将现有模型添加到解决方案中。 我们需要意识到，当模型添加到解决方案时，只会添加模型可执行文件，而不会添加用于训练的数据。 这就是为什么当我们使用文档处理、对象检测或实体提取等模型时，在目标环境中无法修改模型，因为数据没有传输到目标环境。 在这种情况下，如果需要进行修改，应该在 目标环境中创建一个新模型。

作为 AI Builder 的 ALM 部分，我们还应该考虑实施一个 持续改进过程 以改进我们的模型。 到目前为止，我们可以仅通过现成功能为自定义文档处理模型自动化此方法。 但是，我们应该实施一个反馈循环，至少通过使用不同的度量标准来衡量模型的相关性和适用性，从而通知 AI 模型或提示的所有者。 其中之一可以是模型置信度评分。 然而，我们也可以结合人工审查过程，正如我们在之前的示例中所看到的。 为了实现自定义文档处理模型的持续改进，我们可以实施一个 Power Automate 流程，在现有 AI 模型的总置信度评分低于某个阈值时，使用 保存文件到 AI Builder 反馈循环 的 AI Builder 操作。 此过程的详细描述已记录在 此处： https://learn.microsoft.com/en-us/ai-builder/feedback-loop。

当我们准备好解决方案后，可以使用我们在前几章中配置的 CI/CD 流水线来导出解决方案，并将源代码添加到一个代码库中。 之后，我们可以遵循 DevOps 流程，并在准备好后，使用我们的导入流水线将模型导入目标环境。 之后，模型和提示可以在应用程序和流程中使用。 如果我们使用的是托管流水线或全局流水线，我们只需确保已将 AI Builder 组件 添加到 解决方案中。

介绍 Azure OpenAI

有时，开发者和 组织可能希望使用最新版本的 GPT 模型，或者他们可能已经在 Azure OpenAI 上构建了模型，围绕公司数据构建了模型。 他们可能希望重用已经在 Azure OpenAI 上完成的工作，以便应用于其他应用程序，或者也许 Power Platform 中包含的 GPT 模型版本正是他们希望使用的版本。 幸运的是，Power Platform 是一个非常可扩展的平台，支持此类情况 。

正如我们在 第九章中提到的，Power Platform 支持 Azure 与 Power Platform 之间的多种专业开发集成场景。 构建融合开发团队将有助于我们将相关工程师带入项目。 然后，我们可以将任务分配给数据科学家、AI 架构师或类似角色，确保模型在 Azure OpenAI 中被设计和微调。 开发人员或经验更丰富的应用开发者将确保自定义连接器与 Azure OpenAI 集成。 最后，应用开发者将把自定义连接器作为业务应用或流程的一部分，来产生它们 被构建的结果。

Azure OpenAI 服务是一个 PaaS 服务，将 OpenAI 模型带到 Azure 云平台。 这些模型通过 REST API 端点进行暴露，借此我们可以使用这些 LLM，同时受益于 Azure 平台的安全性、可扩展性和可靠性。 这些模型支持跨越 NLP、计算机视觉、语音等不同任务。 以及更多。

Azure OpenAI 旨在为数据科学家和 AI 工程师设计，帮助他们更好地控制模型，允许他们微调模型、生成嵌入、应用内容过滤器等。 此外，在 AI Builder 中，我们可以使用 GPT-4 通过 AI 提示进行文本处理。 Azure OpenAI 提供了其他 LLM 模型，如果我们整体查看 Azure AI 服务，可以发现还有其他 LLM 模型以及 SLM 模型可供使用。 通过这种方式，我们可以超越文本，必要时获得多模态支持，比如最新的 GPT-4o 或其他模型，如 Whisper 或带有视觉功能的 GPT-4 Turbo。 随着 AI 的不断进步以及硬件和 AI 操作的优化，Power Platform 很快将会通过额外的 LLM 模型变得更加丰富，并且这些模型将开箱即用地支持多模态。

将 Azure OpenAI 与 Power Platform 集成

Azure OpenAI 提供了一种名为 Azure OpenAI Studio的用户界面体验，通过它 用户可以构建、测试并管理他们的 Azure OpenAI 部署。 要开始使用它，可以通过 Azure 门户手动配置 Azure OpenAI 服务，也可以使用 Azure CLI 或我们在 上一章中已经熟悉的基础设施即代码的方法。

为了更好地理解创建 Azure OpenAI 资源和模型部署的过程，我们建议阅读以下文档 文章： https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/create-resource。

Azure OpenAI 模型可以围绕组织数据构建，确保数据在组织的 Azure 订阅内安全。 我们的新 Azure OpenAI 服务现在可以通过 REST API 和 SDK 在自定义开发的应用程序中使用。 在 Power Platform 中，可以通过 连接器进行集成。

访问 Azure OpenAI 服务

在我们的 Azure 订阅中第一次配置 Azure OpenAI 服务之前，我们必须提交申请，以获得访问 Azure OpenAI 服务的权限。 这可以通过一个可访问的表单完成， 表单链接为 https://aka.ms/oai/access。

我们已经在 第九章中看到了一些构建自定义连接器的示例。 不过，我们将提供连接到 Azure OpenAI 服务时应考虑的具体事项。 所有所需的信息都可以在 Azure OpenAI Studio 中找到：

图 12.8 – Azure OpenAI 聊天演示区

以下是 步骤：

1. 在 Power Apps 或 Power Automate 中，选择 自定义连接器 在左侧导航栏中，然后点击 新建自定义连接器 | 从空白创建 **。

2. 除了其他数据外，我们需要提供 <name>.openai.azure.com 格式，如下所示： 图 12.8。

3. 在 安全 选项卡中，我们指定 API 密钥 作为认证类型，它会添加到 头部 位置。 这个密钥是我们在 Power Platform 中创建连接时提供的。 它可以在端点 URL 旁边找到，如 图 12**.8所示，或者通过进入 Azure 门户，在 Azure OpenAI 资源 | 资源管理 | 密钥 和端点中找到。

4. 在 定义 选项卡中，点击 新建操作 来定义聊天完成 API 操作。 在 请求 部分，我们可以使用 从示例导入 来创建 HTTP POST 请求。 在 URL部分，我们提供完整的端点 URL，该 URL 也可以在 Azure OpenAI 聊天游乐场 | 查看代码中找到，如 图 12**.8所示。聊天完成 API 还需要一个包含系统和用户角色内容的消息体。 我们可以包含来自 Azure OpenAI 聊天游乐场的示例有效载荷，以方便添加 参数。

   操作可以在 定义 选项卡中进一步自定义，以确保我们为 模型提供了所需的信息。

5. 一旦我们满意，就可以继续到 测试 选项卡，在这里我们将通过提供 Azure OpenAI 服务的 API 密钥来创建连接。 之后，我们可以测试 连接器。

6. 一旦我们有了一个有效的连接器，就可以像使用任何 其他连接器一样，在我们的 Power Platform 解决方案中使用它。

微软最近发布了一个高级版 Azure OpenAI 连接器 (预览版)，适用于 Azure Logic Apps，并且它在 Power Platform 中也能使用。 我们预计，在某个时刻，它会作为 Azure OpenAI 的正式发布连接器进行宣布。 Azure OpenAI 连接器简化了 Azure OpenAI 服务与 Power Platform 解决方案之间的连接，允许开发者利用聊天补全操作与他们的 Azure OpenAI GPT 模型交互。 然而，由于该连接器仍处于预览阶段，我们建议仍然构建并使用连接到 Azure OpenAI 的自定义连接器：

图 12.9 – 创建与 Azure OpenAI 的连接

一旦连接器正式发布并广泛可用，我们可以像使用任何其他连接器一样使用它，正如我们在 前面的例子中所看到的。

此外， 记得 使用 连接引用 在我们的 解决方案中，如 第十章中所提到的那样。通过使用部署设置文件（如下片段所示），可以更有效地将我们的解决方案在环境之间迁移：

 "ConnectionReferences": [
    {
      "LogicalName": "<CONNECTION-REFERENCE-NAME>",
      "ConnectionId": "<CONNECTION-ID-TARGET-ENVIRONMENT>",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_azureopenai" }
  ]

通过这一点，我们已经看到，构建 AI 模型并将其集成到现有的商业解决方案中以改善我们的业务流程是多么容易。 使用 AI Builder 或者甚至是 Azure OpenAI 可以支持许多 业务流程：

• 通过提取附带发票 和文档中的信息自动生成费用报告

• 从产品评论中提取情感，以便做出相应的 回应

• 回复 客户投诉

• 总结会议内容 要点

• 利用语音转文本操作构建客户电话的文字记录

• 将文档翻译成 各种语言

• 识别 欺诈交易

现在我们将切换话题 ， 从 AI Builder 和 Azure Open AI 的具体内容转向自定义 Copilot 或虚拟 AI 助手，以及它们如何支持我们的 DevOps 流程。

ChatOps 和 Copilot Studio

我们已经查看了嵌入产品中的各种副驾驶。 现在是时候看看我们如何创建一个自定义副驾驶了。 本节将重点介绍一个工具，帮助我们构建自定义副驾驶： Copilot Studio。从这里，我们将学习 关于 ChatOps 的内容，并通过一个示例，看看如何利用 Copilot Studio 构建一个帮助我们实现 ChatOps 实践的助手。 我们还将查看可以支持 ALM 的 PAC CLI 命令，用于 Copilot Studio。

深入了解 Copilot Studio

我们在本书的开头简要介绍了 Copilot Studio。 让我们回顾一下它是什么。 Copilot Studio 是一个低代码工具，用于管理自定义副驾驶。 它源自以前称为 Power Virtual Agents （PVA）的产品，该产品用于构建聊天机器人。 随着生成式 AI 的引入以及副驾驶的出现，微软扩展了 PVA 的功能，并将产品更名为 Copilot Studio。 这一变化恰到好处，因为这个工具不仅用于构建聊天机器人，还可以扩展现有的副驾驶，加入更多的自定义功能。 Copilot Studio 现在允许任何人利用生成式 AI 能力构建自定义副驾驶。

自定义副驾驶充当 AI 助手，可以处理各种请求，从执行由业务流程支持的特定操作，到仅仅使用基于业务数据的 GPT 模型回答问题。 由于其生成式 AI 能力，它们不仅仅是聊天机器人，尽管我们通常称它们为机器人。 组织可以构建不同的内部或外部机器人，支持内部团队，与客户合作，帮助推动内部流程，等等。 考虑到它是一个低代码工具，它使得组织能够快速开发符合业务需求并有助于提高投资回报率（ROI）的副驾驶。 。

Copilot Studio 提供了一套预定义的系统话题。 它还允许我们创建自己的自定义 话题。 话题 是 Copilot 的基础构建块。 它们定义了用户与 Copilot 之间对话的特定部分，允许自然的互动与交流。 每个话题包括一个触发器，触发器可以表示为一组触发短语和一组对话节点。 这些元素共同定义了话题可以遵循的对话路径。 节点可以表示一个消息或一个问题，机器人将向用户提出该问题。 节点可以执行一个动作，例如触发 Power Automate 工作流或利用 Power Platform 中的任何连接器。 它们还可以涉及话题管理功能，例如设置变量、检查某些值的条件、调用其他话题等。 创建话题使我们能够完全控制机器人和 用户之间的对话。

图 12.10 – Copilot Studio 话题创建体验

从生成式 AI 的角度来看，Copilot Studio 允许组织通过启用生成式答案和 生成式动作 来提升用户生产力并改善对话流程。

生成式答案 是一项功能，GPT 使用不同的知识源，如公共网站、内部 SharePoint 网站、各种文档、自定义数据源等，生成对问题的回答。 当启用生成式答案功能时，我们可以将 GPT 驱动的答案添加到任何自定义话题，并使用一个回退系统话题，在没有其他话题匹配时触发。 Copilot Studio 还允许集成 Azure OpenAI 模型，而不是使用嵌入在 Copilot Studio 中的 GPT 模型。 在这种情况下，用户的问题会被发送到 Azure OpenAI，在那里生成一个答案并返回给 Copilot Studio，后者再将该答案展示给 用户。

生成模式，也被称为 生成式动作，允许我们通过将各种动作（连接器动作、Power Automate 流程、AI Builder 提示或 Bot Framework 技能）与我们的机器人连接，结合所有自定义和系统话题，并让生成式 AI 自动决定如何响应用户请求，选择最合适的动作或话题来继续 对话。

在开发完机器人之后，我们可以直接在 Copilot Studio 中测试其功能。 一旦我们对其工作结果满意，就可以通过不同的渠道公开自定义的 Copilot。 它们可以通过 Microsoft Teams 或自定义网站发布。 我们可以构建自己的自定义应用，结合自定义 Copilot 实现聊天功能，并将其发布到内部 SharePoint 或部署到其他各种沟通渠道，如 Facebook Messenger、Twilio、Slack、Direct Line API 等。

接下来，我们继续 了解什么是 ChatOps，然后看看如何使用 Copilot Studio 实现 ChatOps 过程。

什么是 ChatOps

ChatOps 这个术语 并不新颖；它已经存在超过 10 年，由 GitHub 引入。 ChatOps 在今天的 DevOps 社区中有所消散，因为人们不再频繁讨论它。 然而，我们可以看到，许多 DevOps 团队已经在 Teams 或 Slack 等沟通平台上实现了部分 ChatOps 实践。 尽管 DevOps 社区没有太多讨论 ChatOps，但我们可以看到 DevOps 工程师确实认识到 ChatOps 的好处，并且可能已经在团队频道中实现了一些 ChatOps 实践，甚至他们自己都未意识到这些实际上是 ChatOps 实践。

ChatOps 是一种也被称为 以对话为驱动的 DevOps的实践。它利用聊天机器人和沟通平台，如 Microsoft Teams 或 Slack，来通过自动化各种与 DevOps 相关的任务，支持开发人员和 IT 运维团队。 这些任务包括创建新的问题或工作项、提供基础设施、在代码库中创建新分支、批准拉取请求、部署应用程序、 等等。

ChatOps 有许多好处。 ChatOps 可以增加和改善团队之间的协作和沟通，这也有助于更好的知识共享和对 DevOps 过程与项目的可视化。 它允许某些过程被自动化，并通过统一的沟通平台提供给成员。 随着我们自动化任务，操作可以更快地完成。 这种方法也有助于减少过程中的潜在人为错误。 团队成员还可以查看其他成员执行的操作历史。 它促进了团队内部的分享，团队成员可以互相帮助。 就像 DevOps 一样，这里不仅仅是工具和过程，更关乎人 和文化。

ChatOps 可以 与聊天机器人结合，帮助提供自动化功能。 随着近期有关 Copilot Studio 中具备代理能力的自定义 Copilot 的宣布，我们相信，使用聊天机器人和自定义 Copilot 支持 DevOps 过程和 IT 运维的案例频率 只会增加。

一个 具有代理能力的自定义 Copilot 是 Copilot Studio 中的一项新功能（该功能在 Microsoft Build 2024 大会期间宣布，目前尚不可用），它使创作者能够创建由事件触发的 Copilot，而不仅仅是用户对话。 它们可以支持长时间运行和复杂的过程，减少人工干预。 我们可以创建一个自定义 Copilot，当 Azure DevOps 或 GitHub Enterprise 中发生特定事件时，能够响应该事件并理解事件的结果。 例如，如果新任务分配给了工程师，自定义 Copilot 可以为该工程师创建一个特性分支，并通知工程师有关计划工作的情况。 当构建失败时，它还可以执行一系列操作。 这两个例子都可以完全通过利用生成式 AI 能力和在 Copilot Studio 中注册的操作来处理。

让我们扩展一下，探讨支持 DevOps 过程的其他可能用例，利用今天在 Copilot Studio 中可访问的能力。 这些能力已经可以使用了。

ChatOps 的使用案例

我们可以开始构建 我们的 ChatOps 实践，涵盖简单但 相关的案例。

第一组用例侧重于向团队成员通知特定活动。 通过使用通信平台，如 Microsoft Teams，我们可以开始从我们的版本控制系统和项目管理工具中引入信息。 当 DevOps 团队成员在进行项目工作时，他们有时可能会错过项目中一些重要的变更。 这就是为什么我们可以将信息带入他们的团队聊天室，并提供筛选过的内容，如有关新拉取请求、失败的流水线执行、任务或新错误创建的信息等。 我们还应考虑实施一种机制，通知团队成员有关 任何事件的发生。

在向团队聊天频道提供信息时，我们应该确保不会让他们接收到过多的所有信息。 我们应当筛选内容，发布相关的信息，这是团队可以决定设置的事情。 然而，这些活动本质上是信息性的，旨在告知某项活动。 每当我们想要基于这些信息或任务执行某个操作时，我们应该查看可以通过机器人或在我们案例中的 自定义副驾驶来提供的其他活动。

在通过 ChatOps 实现的活动第二部分中，我们可以放置任何团队希望自动化的活动。 由于自定义副驾驶可以通过 Copilot Studio 与许多第一方和第三方工具进行连接，借助连接器以及自定义连接器，选项几乎是无限的。 我们可以调用连接器或 API 获取与项目相关的信息，例如获取项目中的所有 bug，或允许团队成员询问如何执行某些活动的常规问题。 我们可以与 Azure DevOps 或 GitHub 等工具集成，以创建新的问题或 bug 工作项，或者我们可以调用 Terraform 或 Power Automate 流程，通过我们在前一章中讨论过的流程来配置新的环境。 我们可以设置诸如拉取请求审批等活动。 正如我们所见，选项 几乎 是无限的。

操作前的授权

聊天机器人可以在给定项目的所有团队成员之间共享。 使用 Microsoft Teams 和 Copilot Studio，我们可以利用 Microsoft Entra ID 作为身份管理系统。 我们注册的连接器和操作应该授权用户，以验证这些用户是否有权限在启动任务之前执行操作。 这可以防止他们执行一些 敏感操作。

将 Microsoft Teams 与 GitHub 和 Azure DevOps 集成

让我们来看看如何将 Microsoft Teams 与 Azure DevOps 或 GitHub 进行集成，以便项目中的更改能反映在公共团队频道中。 这两个工具都与 Microsoft Teams 有原生集成。 为了将 Azure DevOps 或 GitHub 的通知配置到 Microsoft Teams，我们需要在 Microsoft Teams 中安装一个连接器。 在 Microsoft Teams 团队频道中，我们右键点击一个频道并选择 管理频道。当进入频道设置时，我们可以看到 连接器 部分，点击 编辑，这会打开一个新屏幕，显示特定频道的所有连接器。 在这里，我们可以使用搜索功能找到 Azure DevOps 或 GitHub Enterprise。 点击 配置 并按照设置连接器的流程进行操作。

目前，对于 GitHub Enterprise，仅支持以下事件：问题、拉取请求、推送以及这些类别的评论。 在配置 GitHub 连接器时，我们还将获得非常详细的逐步指导，帮助我们配置 Webhook：

图 12.11 - GitHub 通知在 Teams 中的示例

Azure DevOps 支持 有关已完成构建、推送代码和与拉取请求、发布及工作项相关操作的事件通知。 我们还可以对这些事件类型进行更精细的控制，例如仅在项目中添加了新的Bug 类型工作项时接收信息。 一旦添加连接器，向导将引导我们完成过程并在 Azure DevOps 中创建服务钩子订阅：

图 12.12 - 通过 Azure DevOps 的连接器创建服务钩子订阅

除了接收通知，Azure DevOps 还通过允许我们向频道添加标签来与 MS Teams 集成。 这些标签可以显示 Azure DevOps 仪表板或 看板 ，提供项目当前状态的实时信息。 这样，团队成员无需切换上下文和工具，就能获得 这些信息。

GitHub 提供了与 Microsoft Teams 集成的额外功能。 我们可以使用 GitHub 与 Microsoft Teams 的集成，这会在 Microsoft Teams 中安装一个聊天机器人，我们也可以通过它接收项目通知、打开或关闭问题、评论拉取请求等。 安装链接可以在 以下找到： https://teams.github.com/。

图 12.13 – 通过聊天机器人集成 GitHub 和 Microsoft Teams

GitHub 的机器人已经引导我们进入了支持聊天机器人的 ChatOps 实践。 让我们来看看 如何 构建 我们自己的自定义 copilot，以支持 ChatOps 并使用 Copilot Studio。

使用 Copilot Studio 为 Power Platform 构建 ChatOps

我们将通过创建一个简单的 ChatOps 聊天机器人，并使用 Copilot Studio 来演示如何利用 Copilot Studio 支持 DevOps 任务。

我们将前往 Copilot Studio，网址为 https://copilotstudio.microsoft.com/ 并点击 创建 | 新建 copilot：

图 12.14 – 创建新的自定义 copilot

如果我们的环境位于美国地区，我们将提供一个对话式 创建方式。 然而，我们将点击 跳过配置，填写 我们的 名称 和 描述 字段，点击 创建。这将为我们的 copilot 配置 预构建的主题。

如果我们希望通过基于我们数据的生成式回答来增强我们的 copilot，可以选择顶部的 知识 标签，然后点击 添加知识：

图 12.15 – 向我们的副驾驶添加知识

在这里，我们将使用 文件 选项 上传任何包含相关 信息的文件，这些信息可能对我们的团队有用。 这可以是包含一般指导或项目特定文档的文件。 我们可以通过拖放文件或使用 点击浏览 选项来上传文件。 这样，我们的副驾驶就能回答关于该文档主题的问题。 文档索引并准备好使用需要几分钟时间。 这些文档存储在 Dataverse 文件存储中。

一旦准备好，我们就可以使用 测试你的 副驾驶 选项来测试这个功能。

在副驾驶 概览 部分，进入 知识 | 允许 AI 使用其通用知识（预览），我们可以启用或禁用 GPT 模型所拥有的通用知识。 这些是 GPT 被训练时使用的数据。 目前，副驾驶工作室仍使用 GPT-3.5-Turbo，截止日期为 2021 年 9 月。 我们建议在这种情况下禁用它。

下一步是启用副驾驶中的某个操作。 无论我们希望启用什么场景，我们都需要创建一个主题或向副驾驶添加一个操作。 我们先从 主题开始。

我们从顶部菜单中选择 主题 选项。 在这里，我们可以看到一些预设的主题，分别命名为 第一课， 第二课，和 第三课。这些是我们不需要的预设主题，因此我们可以删除或禁用它们。 我们可以通过点击每个主题旁边的三个点，将状态切换为禁用，或者直接 点击 删除。

我们将通过点击 添加话题 | 从空白开始来创建一个新话题。我们也可以在 Copilot Studio 中使用 Copilot，描述我们需要什么样的话题，并让 Copilot 根据提供的描述提出一个大致的对话流程。 现在我们进入了设计器，可以在这里创建话题。 我们可以通过点击 编辑 在 短语 的 触发器 节点中指定几个短语，这些短语将触发 这个话题。

一旦短语被 添加后，我们可以继续选择添加节点，点击 +号。 在这里，我们可以添加控制对话的对话节点。 在这个示例中，我们将前往 调用一个动作 | 连接器（预览） 并搜索 Azure DevOps。我们可以选择任何我们想要添加到我们的 Copilot 中，以支持 ChatOps 的动作。 例如，我们将选择 创建工作项。这会添加一个连接器动作，并包含我们需要配置的所有输入，以便此连接器动作能够 正常工作：

图 12.16 – 向话题添加动作

我们可以在这个连接操作之前创建一条对话路径， 通过一系列问题来询问用户，并将回答存储到变量中，这些变量将作为连接操作的参数。 另一种方法是利用 Copilot Studio 中的生成模式，注册连接操作，并让生成式 AI 根据用户问题的上下文自动判断缺失的值。 生成式 AI 然后可以向用户提出一系列问题，来获取连接操作所需的缺失值。 我们使用 Copilot Studio 中的生成模式并添加生成式操作。 首先，我们需要启用生成模式。 我们需要进入 设置 | 生成式 AI | 生成式（预览）。请注意，该功能目前仍处于预览阶段，不应在生产环境中使用。 目前它仅适用于 英文协助程序。

图 12.17 – 在自定义协助程序中启用生成模式（预览）

选择后，点击 保存 该设置上方的按钮。 通过此操作，我们允许生成式 AI 根据用户的消息确定应该调用哪个操作或话题。 这也改变了我们触发 话题的方式。 它们不再是短语，而是转化为话题 描述。 话题描述包含了我们的话题所执行的操作信息。 话题描述的示例可以在 图 12**.18中看到。这由 GPT 模型使用来确定应该调用哪个操作或话题。 话题或操作描述越准确，GPT 模型就越有可能调用正确的操作 或话题：

图 12.18 – 在生成模式下触发话题

我们可以通过点击 X 关闭副驾驶设置，点击位置在 Copilot Studio 右上角。 接下来，我们将点击 操作 | 添加操作 在顶部菜单栏中。 在这里，我们可以使用搜索框查找 Azure DevOps 或 GitHub 连接器的所有可用操作。 我们可以选择我们希望启用的连接器操作，例如 从 GitHub 创建问题 ，并继续配置选项：

图 12.19 – 在 Copilot Studio 中添加连接器操作

每个连接器操作都带有一组输入和输出。 我们可以静态设置输入值，或者让生成式 AI 理解用户消息的上下文，并尝试从消息中提取正确的实体，并将它们输入到参数中。 对于输出，我们可以让 AI 动态生成输出消息，或者手动配置它。 我们将保持默认设置，并允许 AI 针对每个必需的参数向我们提问。 在 输出中，我们将配置默认设置并让 AI 动态生成响应。 通过这种方式，我们现在已经在副驾驶中启用了 创建新问题 操作。 我们可以继续启用我们希望在 ChatOps 流程中使用的其他操作。

最后，我们将创建一个与 Power Automate 工作流的集成，以支持更复杂的流程。 流程可以像我们之前看到的那样注册为操作。 另外，我们可以构建一个主题，并添加一个节点来调用 Power Automate 流程。 由于我们已将副驾驶的生成式 AI 设置更改为生成模式，我们需要提供 关于我们主题的准确和清晰的信息。 在 描述完主题后，我们可以通过使用加号 | 调用操作 | 基本操作 | 创建流程来添加一个流程。这将单独打开 Power Automate，并带有输入触发器和输出操作，二者都与副驾驶的集成相关 ：

图 12.20 – 为副驾驶创建流程

我们可以继续这个过程，构建主题和流程，并与将支持我们的 ChatOps 流程的操作进行连接。

一旦我们对工作满意 并且希望将其部署到 Microsoft Teams，我们需要发布这个机器人。 在副驾驶的右上角，我们有 发布 选项。 会弹出一个窗口，我们需要确认发布过程，点击 发布。然后，我们可以返回到 副驾驶工作室副驾驶 | 频道 | Microsoft Teams。我们可以点击 启用 Teams 来在 Teams 中启用这个机器人。 在这里，我们有 可用性选项，可以让我们将副驾驶分享到 Teams 应用商店中。 返回到 Teams 设置，我们有 打开副驾驶 选项，点击它会将副驾驶作为应用打开在 Teams 中。 我们的机器人 现在已准备好与用户互动并执行 DevOps 操作。 如果我们希望将副驾驶添加到 Teams 频道，我们可以在 编辑详细信息 中设置，允许同一租户的用户将此副驾驶添加到团队中。 但是，这样会使用户能够将副驾驶添加到他们所在的任何团队中。 我们建议查看 Teams 管理选项，并通过 Teams 管理副驾驶的推广过程 。

在下图中，我们 可以看到一个成功部署自定义副驾驶到 Microsoft Teams 的示例。 我们可以看到生成式 AI 功能如何在不同主题之间切换，执行操作，甚至通过提问来获取所有 必需的参数值：

图 12.21 – 在 Microsoft Teams 中使用自定义副驾驶

副驾驶工作室的 ALM

副驾驶 工作室与其他 Power Platform 产品一样，通过解决方案支持应用生命周期管理。 我们应该从 前往 解决方案 并点击 新建解决方案 或打开一个现有的解决方案。 进入解决方案后，我们可以点击 新建 | 聊天机器人 开始在副驾驶工作室中创建我们的自定义副驾驶。 使用这种方式可以确保我们可能在副驾驶中作为操作使用并注册的任何潜在连接器，会作为 连接引用 添加到解决方案中。

我们可以按照前几章中展示的相同方法，使用 Azure DevOps 或 GitHub 导出和导入解决方案。

由于我们可以在 Copilot Studio 中使用不同的连接器，因此必须确保有有效的 DLP 策略，这将确保在任何给定的环境中，只能使用组织策略允许的连接器。 可以使用。

除了之前提到的方法，我们还可以专门利用 PAC CLI 来管理 copilot。 如果我们希望仅维护自定义 copilot 的 ALM，我们可以使用这些命令并将其打包成脚本。 自定义 copilots。

使用以下 PAC CLI 命令，我们可以导出我们 copilot 的 YAML 模板文件： 我们的 copilot：

 pac copilot extract-template --bot <BOT-ID> --templateFileName <templateName>.yaml

这有两个目的。 首先，我们可以将整个 copilots 作为代码导出，存储在代码库中，并通过代码进行协作。 其次，采用这种方法，我们可以为组织的 copilots 构建模板。 我们可以使用这种方法准备一个模板，作为组织各部门 copilots 外观的框架或起点。 这将包括一些预定义的主题作为起点。 然后，我们可以将这些 copilots 的定义导出为模板文件，并将这些文件存储在中央代码库中的某个地方。 当有人请求特定的 copilot 时，我们可以使用预先准备好的模板文件，创建一个包含这些预构建主题的 copilot，并与合适的人分享。 导入过程可以通过以下 PAC CLI 命令完成。

在我们能够将 copilot 导入目标环境之前，我们需要确保 connectionReferences 部分已正确更新，以反映目标环境中的适当值。 在创建的模板 YAML 文件中，在文件的底部，我们可以找到连接引用，如下所示： 以下片段：

 connectionReferences:
  - managedProperties:
      isCustomizable: false connectionId: <CONNECTION-ID-TARGET-ENVIRONMENT> connectorId: /providers/Microsoft.PowerApps/apis/shared_visualstudioteamservices
    connectionReferenceLogicalName: template.connectionreference.cr6a8_chatOpsDemo.cr.SyS11HJP
    displayName: cr6a8_chatOpsDemo.cr.SyS11HJP
connectorDefinitions:
  - connectorId: /providers/Microsoft.PowerApps/apis/shared_visualstudioteamservices

此外，我们 还需要确保在启动该命令之前，目标环境中已经准备好解决方案。 我们可以创建一个新的解决方案或使用现有的解决方案。 我们可以创建一个新的解决方案或使用现有的解决方案。

一旦所有这些设置完成，我们就可以启动导入命令： 导入命令：

 pac copilot create --environment <ENVIRONMENT_ID> --schemaName <SCHEMA_NAME> --templateFileName <TEMPLATE-FILE>.yaml --displayName <DISPLAY-NAME> --solution <SOLUTON-NAME>

如果出现任何错误，这将记录在 pac-log.txt 文件中，错误信息中已写明。

现在副驾驶已经配置好，我们可以与创作者组分享副驾驶。 如果我们单独与用户分享副驾驶，他们将获得创作者角色，以共同编辑机器人。 如果我们将副驾驶 分享给安全 组，那么安全组中的用户将获得 仅使用权限。

总结

在本章中，我们对 AI 进行了宏观概述，并讨论了过去两年的一个热门话题：GPTs。 AI 已经成为我们日常任务的不可或缺的一部分。 它无处不在，几乎在我们使用的每个应用程序中。 各组织正在寻求利用 AI 进行创新，或者仅仅是提高业务流程的效率。 无论是哪种方式，我们都必须确保以负责任、伦理和安全的方式构建 AI 解决方案，正如本章中所学。 接下来，我们了解了微软如何将 AI 助手，称为副驾驶，嵌入到每个产品中，以便我们在使用这些工具时能够更高效。 我们特别研究了 Power Platform 中的副驾驶，以及我们作为创作者，如何利用它快速设置数据架构、原型应用、流程 等。

随着各组织寻求通过 AI 进行创新，他们可能会面临一个问题：Power Platform 中有哪些 AI 服务可供使用。 下一部分重点介绍了 AI Builder 及其组件，如 AI 模型和 AI 提示。 我们了解了如何在应用程序中使用它们，并将 ALM 流程应用于 AI Builder 组件。 然而，AI Builder 并不是唯一可以用来增强我们业务应用程序的 AI 服务。 Azure OpenAI 为组织提供了安全可靠的 OpenAI 模型，可以在任何流程或应用程序中使用，正如 我们所学。

我们通过聚焦于使用 Copilot Studio 和 ChatOps 来定制助手，结束了这一章节。 我们介绍了 Copilot Studio，它使我们能够构建定制的助手或简单的聊天机器人。 通过将 AI 融入 Copilot Studio，我们可以在数小时内为内部或外部用户构建丰富的对话式 AI 体验，而不是数月。 Copilot Studio 是一个支持业务流程的平台，包括支持 ChatOps 相关的服务。 因此，在这一部分的结尾，我们探讨了 ChatOps，它通过提供与机器人对话的体验，扩展了 DevOps，能够执行与 DevOps 相关的操作。 最后，我们实际探讨了 ChatOps 流程如何通过 Copilot Studio 获得支持，以及在应用生命周期管理（ALM）中，Copilot Studio 有哪些小的特殊性。 Copilot Studio。

至此，我们将结束这本书。 这本书带我们走过了 DevOps 生命周期的不同阶段，从规划业务解决方案到构建管道、管理 DevSecOps、照料环境生命周期、理解最佳实践，最后以 AI 和 ChatOps 收尾。 我们希望到目前为止，我们已经成功地展示了 Microsoft Power Platform 是一个强大而成熟的平台，具有扩展性，能够帮助组织和个人构建应用并支持其业务流程，利用 Power Platform 中可用的服务和功能。 Power Platform。

进一步阅读

• 微软关于负责任 AI 的 实践： https://www.microsoft.com/en-us/ai/responsible-ai

• Azure OpenAI 服务： https://learn.microsoft.com/en-us/azure/ai-services/openai/overview

• Copilot Studio 指南： https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/

• GitHub 和 Microsoft Teams 集成的文档： https://github.com/integrations/microsoft-teams/blob/master/Readme.md

• 关于 Azure DevOps 和 Microsoft Teams 集成的详细信息： https://learn.microsoft.com/en-us/azure/devops/service-hooks/services/teams?view=azure-devops

• PAC CLI 命令用于 copilot： https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/copilot