精通微软 PowerPlatform 上的 DevOps（三）

技术文档

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

译者：飞龙

协议：CC BY-NC-SA 4.0

第十章：在 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 最佳实践，我们将通过一个示例来进一步了解这种方法。

示例 - 将配置与应用程序解耦

在这个例子中，我们将利用连接引用和环境变量来将配置从我们的业务解决方案中解耦。

首先，我们需要创建一个解决方案并添加所有属于我们业务解决方案的组件，包括新的环境变量和连接引用。然后，我们将创建一个部署设置文件，该文件将把配置设置与实际应用程序解耦。这将使我们能够配置特定于目标环境的值。我们将使用部署设置文件将解决方案导入到目标环境中，并带有相关的配置值。

准备解决方案

让我们来探索准备解决方案与配置设置的第一步：

在 Power Apps（https://make.powerapps.com）或 Power Automate（https://make.powerautomate.com）主页上，我们可以在左侧导航栏中找到 解决方案 选项。选择该选项将打开一个屏幕，显示当前环境中所有解决方案的列表。
我们可以点击 pac solution init 和 pac solution import 命令。
当我们进入解决方案对象资源管理器时，我们可以通过点击新建 | 更多 | 连接引用来添加新的连接引用。

要添加一个现有的连接引用，我们点击 添加现有 | 更多 | 连接引用，选择现有的连接引用，然后点击 下一步，正如我们在 图 10*.1.* 中看到的。这将把任何现有的组件添加到解决方案中：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_1.jpg

图 10.1 – 在解决方案对象资源管理器中添加组件

每当我们创建新的连接引用时， 新建连接引用 屏幕将会打开，正如在 图 10*.2*中所见。

在这里，我们必须提供 显示名称，名称， 连接器 的值，以及连接值用于所选连接器。提供描述是可选的，但建议提供，以便更好地理解连接引用的用途：
- 如果在环境中没有所选连接器的连接，我们需要通过选择 + 新建连接来创建一个新连接，这将打开一个新连接屏幕，弹出框中显示我们所选的连接器。我们需要提供所有必需的连接参数，并点击创建来创建一个连接。
返回到之前的 新建连接引用 屏幕，我们现在可以点击刷新按钮，位于连接下拉列表旁边，如 图 10*.2*所示，这将更新连接列表并显示新创建的连接。我们可以选择它并点击创建，这将在我们的解决方案中创建一个新组件。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_2.jpg

图 10.2 – 创建新的连接引用

要添加一个环境变量，我们遵循类似于 步骤 3中提到的步骤。这次，我们选择新建 | 更多 | 环境变量。
将出现一个新屏幕，我们需要提供更多关于环境变量的信息，例如 显示名称，名称，描述，以及 数据类型：
- 数据类型 指定了我们环境变量的类型。这可以是 十进制数， 是/否，文本， 数据源，机密，等等。选择数据类型后，我们可以配置默认值和当前值，如在 图 10.3中所示。如果我们正在创建一个类型为 数据源的环境变量，我们可以选择连接器**。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_3.jpg

图 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 进行解决方案导入时使用。我们在 第八章中简要提到过它：

我们应该导出我们的解决方案或克隆它。我们需要拥有一个解决方案 ZIP 文件或一个未打包的解决方案文件夹，我们可以通过它来生成设置文件。我们可以通过两种方式来实现：
- 选择解决方案，点击 pac solution clone --name 或 pac solution export --name ，这意味着解决方案文件夹将被本地克隆，或解决方案 ZIP 文件将被本地下载
现在我们已经导出了解决方案包文件，我们准备好按照以下方法创建部署设置文件。

生成部署设置文件可以使用以下 PAC CLI 命令：
```
 pac solution create-settings --solution-zip  --solution-folder  --settings-file deploymentSettings.json file in the current folder.
```
下面是 deploymentSettings.json 文件结构的示例，位于本书 GitHub 仓库的 第十章 文件夹中。在该文件中，我们可以看到环境变量和连接引用的结构，并包含相应的值。

文件中的每个环境变量都有一个 Value 属性。初始时，它是一个空字符串，我们将其更新为目标环境的值。对连接引用也应进行相同的操作，其中 ConnectionId 属性最初为空，需要提供。

要更新连接引用值，我们可以使用 PAC CLI 连接到目标环境并列出所有连接。这将使我们看到给定连接器的连接是否已存在于目标环境中。当我们将 PAC CLI 指向目标环境时，可以使用 pac connection list 命令列出在选定环境中建立的所有连接。如果连接已存在，请将该连接的 Id 值复制到部署设置文件中的正确连接引用 ConnectionId 值下，如 第八章 所示；否则，创建一个新的连接。
现在我们已经为解决方案准备了部署设置文件，可以继续进行解决方案导入过程，包括指定的部署设置文件。如果命令中未提供环境值或路径，将使用当前环境和当前文件夹结构进行解决方案导入：
```
 pac solution import --path  --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: \'\' SolutionInputFile: \'$(Build.ArtifactStagingDirectory)/$(SolutionName).zip\' UseDeploymentSettingsFile: true DeploymentSettingsFile: \'$(SolutionName).json\' AsyncOperation: true MaxAsyncWaitTime: \'60\'

现在，我们更清楚地了解了我们的解决方案如何拥有配置设置文件，使其能够在不同的环境中重用，这也将帮助我们构建其他组件，如画布组件和代码组件。我们将从画布组件和组件库开始。

画布组件和组件库概述

在 Power Apps 中开发应用时，应用开发者使用各种控件来构建应用的基础模块。为了避免重复，并构建可重用的应用部件，这些部件可以在同一个应用或多个应用中使用，开发者应考虑使用画布组件。本节介绍了画布组件以及组件库，并帮助你理解它们之间的区别以及它们如何融入 ALM 过程。

画布组件

画布组件 作为独立的模块化构建块，封装了特定的功能或用户界面元素。画布组件可以在 Power Apps 画布应用和基于模型的应用中重用。这些组件不仅在创建更大、更复杂的企业级应用时起着至关重要的作用，而且在多人协作开发环境中也非常重要，因为开发人员可以分配任务，并在构建业务解决方案时专注于每个单独的组件。创建画布组件的另一个好处是，它们可以在一个地方集中更新，所有更新都会在应用中的所有实例中反映出来。该应用。

创建画布组件是在 Power Apps Studio 中构建画布应用程序时完成的。在左侧导航栏中，点击 树视图，我们可以看到应用程序中所有的屏幕和组件。点击组件可以查看所有现有的组件，并通过点击 新建组件来创建新的组件。这会创建一个空白的画布组件，我们可以添加控件：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_4.jpg

图 10.4 – 在 Power Apps 中创建画布组件

每个组件都可以拥有自定义属性。自定义属性允许组件接收应用程序传递的值（称为输入属性），或者将数据或状态从组件发送到应用程序（称为输出属性）。无论属性类型是输入还是输出，自定义属性都可以保存任何数据类型的数据，涵盖从传统的数据类型，如文本和数字，到更符合 Power Apps 特性的类型，如屏幕、颜色和表格。使用自定义属性可以在组件与应用程序主机之间共享信息。在画布组件层级还有一个设置， 访问应用程序范围，可以在组件的属性中找到。它可以打开或关闭，以允许访问应用程序内更广泛的信息，例如全局变量、集合和应用程序中的控件。这仅适用于应用程序内的画布组件，而不适用于组件库中的组件。我们可以关闭此设置，并通过自定义属性将信息传递给组件。

组件库

由于画布组件只能在一个应用程序内使用，为了在环境中跨应用程序重用组件，我们可以创建组件库。一个 组件库 作为组件定义的存储库。这使得应用程序可以管理其所依赖的组件，这意味着每当组件更新可用时，应用程序开发者将被通知。可用更新的信息会在 Power Apps Studio 中编辑应用程序时显示，或者通过手动点击刷新按钮来检查组件库更新。

创建组件库与创建画布组件不同：

可以通过导航到 Power Apps 主屏幕并从左侧导航面板中选择 组件库 来找到组件库。如果在左侧导航面板中看不到此选项，请点击更多 | 查看全部，在这里可以找到 应用增强：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_5.jpg

图 10.5 – 访问组件库

一旦我们在组件库屏幕上，我们可以点击 + 新建组件库 来创建一个空白的画布，用于添加应用程序组件。
在这里，我们可以按照与常规画布组件相同的过程导入现有组件或创建新组件。在组件库中创建或导入的每个组件都允许制作者在目标环境中进行自定义。 允许自定义 是 Power Apps Studio 内部组件的属性。如果允许自定义，则一旦应用制作者开始在应用程序中对组件进行更改，这将打破对组件库的引用并创建组件的本地副本。为了保持对组件的控制并仅允许从组件库内部进行组件更改，关闭此组件设置是一个良好的实践。
一旦所有组件添加到组件库中，我们需要发布这些更改。发布过程与任何其他画布组件或画布应用相同。如果组件库没有发布，则无法重复使用。
发布后，我们可以在应用程序中重新使用库中的组件。为此，我们在 Power Apps Studio 中打开我们的画布应用，在左侧导航面板中点击插入，这将打开添加控件的选项和组件。

我们点击代表目录搜索的图标，这将打开一个 导入组件 屏幕。在这里，我们可以找到我们的组件库以及库中的所有组件。我们可以选择需要的组件然后点击导入：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_6.jpg

图 10.6 – 从组件库导入组件

组件库中的组件将出现在左侧导航面板的插入选项下。我们可以在 库组件 组中找到它们，位于 自定义 类别下方，该类别包含本地创建的画布组件，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_7.jpg

图 10.7 – 从添加的组件库中访问组件

现在我们已经学习了如何构建画布组件和组件库，这些组件库支持在环境中跨画布应用程序的组件可重用性，让我们来探讨如何管理组件库的生命周期。

管理组件库的生命周期

正如我们之前所看到的，为了在多个应用程序之间重用组件，它们需要被添加到组件库中。一旦添加到库中，它们就可以被插入到应用程序中。这样，应用程序就会创建一个来自组件库的选定组件的依赖关系，并简化我们的解决方案管理。

为了将带有组件依赖关系的应用程序部署到不同的环境中，我们必须确保在部署应用程序之前，目标环境中存在该组件库。否则，导入解决方案的过程将无法成功。我们需要确保组件库要么与应用程序一起打包在解决方案中，要么在部署带有组件依赖关系的应用程序之前，将其移至目标环境的单独解决方案中。

我们可以通过导航到 解决方案，选择我们的解决方案，点击对象，点击应用程序名称旁边的三个点，点击高级，然后点击 显示依赖关系，如 图 10.8所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_8.jpg

图 10.8 – 检查应用程序的依赖关系

在这里我们会找到一个标签叫做使用，它显示了哪些对象正在被我们的应用程序使用。选择组件库名称旁边的三个点将会引导我们到 默认解决方案。需要注意的是，组件库会被放置在环境中的默认解决方案中。当我们迁移到目标环境时，只要该环境已启用 Dataverse，情况将保持不变。

将组件库添加到包含我们应用程序的解决方案中，可以通过进入我们的解决方案，点击对象，然后创建一个新的组件库或添加一个现有的组件库。创建新组件库的方法是点击新建 | 更多 | 组件库。添加现有组件库的方法是通过 添加现有 | 更多 | 组件库。将组件库添加到解决方案后，我们可以启用/禁用允许在目标环境中进行自定义的选项。该设置可以在解决方案资源管理器中找到。我们选择组件库，点击其名称旁边的三个点，然后点击高级 | 托管属性。这将打开一个编辑组件库托管属性的界面。在这里，我们可以切换启用或禁用允许在目标环境中进行自定义的选项：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_9.jpg

图 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  --namespace  --template  --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

以下是文件夹结构：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_10_10.jpg

图 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 componentWith 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 environmentPackaging the code componentCode 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

This will create a reference inside the `.cdsproj` file, like this:

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 PlatformImporting 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 `. 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

Here is the other:

pac pcf push -pp

Without the name of the solution, this code component will be imported to a temporary `PowerAppsTools_` solution.Preparing the component for releaseWhen preparing our code component for release to the production environment, we should add the `production` property inside the `pcfproj` file underneath `OutputPath`, as in the following example:

PCFe71d2e10-908c-4123-9f29-3283cbd224ab$(MSBuildThisFileDirectory)out\\controlsproduction

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:

Managed

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 applicationsCode components can be used across canvas applications, model-driven apps, and websites. The following are some examples of adding components to apps.Model-driven appsAdding 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 app1. 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 appsAdding 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 appPower PagesAdding 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 Pages1. 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 componentsAs 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 project2. Working on the code component’s implementation3. Testing/local debugging of the developed code component and pushing it to the Power Platform development environment4. Adding the component project reference to the solution in the development environment5. Testing the business solution with the included code components6. Preparing the code component for release7. Importing the solution to other environments and testingWe 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 componentsAnother 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 componentsWhenever 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 appsIn 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 solutionsTo 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 solutionsThe 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 componentsTo 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 PagesPower 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 modelAlthough 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 PagesThe 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 profilesA 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 `.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 PagesManifest filesWhen 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 PagesWe 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 -p

我们对文件进行更改，并决定上传这些更改，使用部署配置文件。 pac pages upload –path --environment --deploymentProfile

Using Power Platform Build Tools with Power PagesPower 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 \"\"git config user.name \"\"git initgit checkout -B maingit add --allgit commit -m \"代码提交\"git push --set-upstream origin maingit -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 ReposWhenever 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 pipelinesOnce 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.SummaryThis 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 上构建工作负载时，收集并记录所有业务需求是我们的责任。业务需求将帮助我们决定哪些工具和技术将支持工作负载，以及基础设施和应用设计的形态。围绕技术的这些决策和遵循业务需求对于制定故障恢复计划至关重要。为了支持工作负载更加具有韧性，我们应该结合监控功能，通过这些功能，工作负载可以识别并应对操作故障。它还将作为使用情况的洞察，能够帮助改进工作负载。

安全性

Well-Architected 的下一个支柱与安全性相关。它专注于构建能够承受潜在攻击的工作负载，并整合了三项基本安全原则——保密性、完整性和可用性。在设计业务解决方案或工作负载架构时，我们建议采用 Microsoft 零信任模型来减轻安全风险。 Microsoft 零信任模型围绕三个关键原则展开：

明确验证：确保通过根据各种数据点进行身份验证和授权，只有可信实体才能获得访问权限。这样做将允许实体仅访问他们被授权访问的内容，并仅执行他们可以执行的操作。。
最小权限访问：遵循最小权限原则。通过限制身份的权限，我们正在限制可以做什么、做多久以及可以访问哪些资源。。
假设发生泄露：工作负载应当设计成我们假设可能会发生泄露的方式。考虑到这一点，我们正在实施控制措施，以降低风险和潜在的损害，万一发生这种情况。

卓越运营

这一支柱强调创造一个优先考虑运营卓越的工作环境。我们的意思是通过实施融合开发方法并采用 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。

体验优化

Power Platform Well-Architected 框架的最后一个核心支柱专注于用户体验，以及开发人员在开发过程中应考虑的事项。应用程序应该以与用户期望相一致的方式构建，并且要设计以满足特定需求。与应用程序的交互应该简单且合乎逻辑，以便用户能够高效地完成所需的工作。应用程序相关的流程也应该简洁易懂且直观。

我们应该构建用户友好的应用程序，具有包容性，能够被有障碍的用户使用。如果该应用程序将被全球用户使用，我们应该考虑提供本地化版本以提高用户参与度。

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，这是一种身份和访问管理系统：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_4.jpg

图 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 来完成：

在 Azure 门户中，我们应该搜索 托管身份 并打开 托管身份 页面，页面上展示了您租户中的所有托管身份：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_5.jpg

图 11.5 – 托管身份

要创建新的 UMI，我们接下来点击点击创建：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_6.jpg

图 11.6 – 创建新的托管身份

在此阶段，我们需要提供所有创建托管身份的详细信息。这包括选择 Azure 订阅，在此我们可以选择已有的资源组，也可以直接从该页面提供一个新的资源组。

通过提供托管身份实例的详细信息，例如选择 UMI 将要配置的 Azure 区域以及名称，我们可以通过点击 下一步来准备创建 UMI：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_7.jpg

图 11.7 – 配置新的 UMI

在下一个屏幕中，我们可以添加标签。我们建议为 Azure 资源添加标签，以便以后能够对其进行分类，并将其映射到组织中的正确成本中心。完成后，我们通过点击 审查 + 创建进行下一步操作，这将启动验证过程，以验证 Azure 资源管理器 （ARM）模板。验证过程完成后，我们可以通过点击创建来配置资源。
一旦新 UMI 创建完成，我们继续打开该资源，在概述屏幕上，进入 托管身份，找到并复制 客户端 ID 信息。这将在下一步中在 PowerShell 中使用：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_8.jpg

图 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 -ForceInstall-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 = \'\'Register-PowerOpsAdminApplication -ClientId $clientId

注册过程完成后，我们可以继续进行部署设置。在托管 Power Platform 着陆区实施指南的 GitHub 仓库中（https://github.com/microsoft/industry/tree/main/foundations/powerPlatform），我们可以找到一个 部署到 Microsoft 云 按钮。选择此选项后，我们将被转移到 Azure 门户，Power Platform 着陆区将通过自定义 ARM 模板进行部署：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_9.jpg

图 11.9 – 在 Azure 门户中的 Power Platform 着陆区部署模板

从 图 11*.9*中，我们可以看到设置着陆区参考实现过程中的第一个标签是 部署设置。在这里，我们将连接到新创建的 UMI 并选择我们的 Azure 订阅以及位置。
下一个标签是 安全、治理和合规性，允许进行租户范围的 DLP 策略配置，通过为连接器选择不同级别的限制。在此步骤中创建的 DLP 策略将作为基准策略，后续可以添加新的 DLP 策略。还可以在此应用其他策略，如租户隔离、访客用户和共享设置。
下一个标签是 管理员环境与设置，允许组织创建仅用于管理目的的独立管理员环境——例如，我们可以创建一个独立环境，在其中部署一个 CoE 启动工具包。创建独立的管理员环境将导致拥有独立的开发、测试和生产环境，以支持我们业务解决方案的应用生命周期管理。在这里，我们还可以找到一项策略，禁止用户自行创建不同类型的环境。
接下来，我们有 管理与监控。在这里，我们可以配置用于监控的其他 Azure 服务，例如 Azure Monitor 中的 Application Insights。此外，我们还可以为 Power Platform 启用租户级分析。
该过程的最后一步是配置额外的登陆区（环境），这些环境将专门面向公民开发者、专业开发者或行业解决方案。如果需要，我们可以跳过这一步，稍后当我们意识到需求增加且需要更具体的环境时，我们可以使用 登陆区自动配置模板 选项，使用相同的 Power Platform 登陆区 GitHub 仓库来配置更多环境。
在过程结束时，我们可以回顾我们所做的所有配置选项，并通过选择创建按钮来完成配置过程。

这些标签页包含了针对参考实现的关键设计领域的配置设置。这些是我们在创建自己的架构设计时需要考虑的事项。即使我们来自一个较小的组织，实施登陆区似乎过于复杂，我们仍然应该遵循关键设计领域，并将登陆区参考实现作为我们的北极星，作为指导我们前进的方向，实施最佳实践和保护措施，以保护组织数据。我们可以从小规模开始，但随着采用的增长，我们将通过标准化和一致性的方法看到登陆区在资源配置中的好处。受管环境。

现在我们已经看过如何使用登陆区参考实现来配置新的环境，我们将朝着使用各种工具自动创建和管理环境的方向前进，同时仍然包括设计领域中的重要部分，例如添加 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：

terraform.tf 配置文件提供。在这里，将安装指定的提供程序。启动此步骤时，我们使用 terraform init 命令。此命令会创建一个 Terraform 锁文件，其中保存了该工作区中使用的提供程序信息。如果我们希望在不同环境中使用相同的提供程序版本，这个文件也可以进行版本控制。
main.tf 文件。计划将包括提供、更新或删除基础设施或其组件的步骤。在这一步，我们使用terraform plan命令。如果我们使用-out标志，计划将保存到文件中，这样我们就可以在需要时重新使用相同的计划。为了拥有一个灵活的 IaC 配置文件，我们建议将变量存储在main.tf外部的单独变量文件中。我们在variables.tf中声明变量并提供可选的默认值，其中单独环境的实际值通过variables.tfvars文件进行设置。
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 AzureADConnect-AzureADNew-AzureADServicePrincipal -AppId 8578e004-a5c6-46e7-913e-12f58912df43 -DisplayName \"Power Platform API\"

AppId 是使用 Azure 公有云时 API 服务的值。在任何其他情况下，它需要更新为正确的 AppId 值。

在此干预后，Power Platform API 应该会出现在列表中，我们可以在应用注册过程中添加 API 权限，如 图 11*.10*所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_10.jpg

图 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

如果计划成功完成，我们应该会在终端看到更长的输出，显示所有的更改计划，最后是类似这样的内容（使用提供的示例文件）：

 Plan: 2 to add, 0 to change, 0 to destroy. ──────────────────────────────────────────────────────────────Saved the plan to:

这里，表示上一步骤中输出文件的名称。。

现在，我们可以使用以下命令，将计划应用到我们的环境中：以下命令：

 terraform apply

如果我们希望在 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: \'\' 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 连接器来构建环境生命周期并通过工作流执行：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_11.jpg

图 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 策略。通过可视化体验，它们提供了所有所需的信息。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_12.jpg

图 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 策略：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_11_13.jpg

图 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*中所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_1.jpg

图 12.1 – 在 Power Platform 中启用或禁用 Copilot

这些设置包括启用数据收集、用户发送反馈的能力，以及在 Power Apps 中启用或禁用 Copilot 预览功能的能力。

从创建者角度看 Copilot 的使用

在本节中，我们将了解如何在 Power Platform 中使用助手生成带有数据表的 Power Apps 画布应用，并通过 Power Automate 中的流进行支持。这展示了 AI 如何帮助应用开发者在低代码开发过程中获得额外支持，并转向无代码方法。

在 Power Platform 中使用助手的好处之一是，这种方法使开发者能够更快速地构建解决方案原型。这是因为原型不需要具备应用的所有功能，只需要提供概念的外观和感觉。借助 Power Platform 应用中的助手，开发者可以使用自然语言描述构建应用或流的模型，并快速验证业务应用构思的可行性。对于助手提供的每个建议步骤，我们可以通过点击撤销按钮撤回助手所做的更改。这使得测试想法变得更加容易，并且在不满意建议的工作时可以快速恢复。

Power Platform 中的助手具有相同的用户体验。在该服务的首页，我们可以找到一个大型文本输入组件，允许我们添加想要执行的操作描述。我们写给助手的提示应该清晰且具体，因为这将帮助助手返回更相关的结果。为了使用助手获得更好的结果，我们应提供更多关于请求的上下文，或者在需要时，提供一些如何实现某个功能的示例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_2.jpg

图 12.2 – Power Platform 首页上的助手

在 Power Apps 首页（https://make.powerapps.com/）上，我们将首先描述我们希望构建的应用程序的构思。由于几乎所有的业务应用都依赖于数据，助手将开始在 Dataverse 中创建一个数据架构，作为我们的数据源来管理数据。在这个步骤中，助手会提取我们提示的上下文并根据输入开始创建一个实体关系图。

我们可以使用提示建议来更改数据架构、添加更多表格、配置它们之间的关系、向表格中添加更多测试数据等等。此时， 查看提示 按钮作为提示指南，提供了 Copilot 可以执行的操作建议。这些操作包括创建表格和关系、修改表格和列，并作为灵感提供基于当前数据架构设计的建议：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_3.jpg

图 12.3 – 丰富数据模型创建

一旦我们点击 保存并打开应用，Copilot 将使用此数据架构创建一个示例应用，该应用具有多个屏幕，包含表单用于操作表格，同时也有一个独立的欢迎屏幕，可作为屏幕之间的导航。

在 Power Apps Studio 中，我们可以利用 Copilot 提问，了解如何在 Power Apps 中实现某些功能。它利用 Bing 搜索来查找相关内容，并为我们提供指导。例如，我们可以提问“如何将图片添加到图像组件？”它会提供与问题相关的回答。在这种情况下，它会提供逐步的指导，教你如何实现此操作，并提供相关的文档链接，解释整个过程。我们可以要求它向屏幕添加特定的组件，如按钮或文本标签，但此时我们可能仍然需要手动完成一些任务，因为它尚不能完成所有任务。

构建 Power Fx 公式有时会很具挑战性，特别是对于第一次使用 Power Platform 的人。类似于 GitHub Copilot 的功能，为了支持开发人员，现在我们可以使用自然语言的注释来生成 Power Fx 公式。它也可以反向工作，帮助理解公式的作用，只需点击公式框旁的 Copilot 图标，然后选择解释 此公式：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_4.jpg

图 12.4 – 使用 Copilot 提供 Power Fx 公式建议

作为开发人员，我们还可以直接在 Power Apps Studio 中查看代码。通过选择屏幕或组件旁边的三个点（或右键单击），我们现在可以看到一个 查看代码（预览） 选项，显示所选部分的 YAML 格式代码。这使我们可以复制代码并与其他开发人员讨论，直接修改代码，甚至使用复制/粘贴将此部分放入另一个屏幕或应用程序中。

如果我们转向 Power Automate，Copilot 也可以帮助我们完成类似的任务。这意味着使用自然语言描述我们希望创建的流程，并对现有流程进行修改，例如向流程中添加操作、配置操作的参数，等等。

随着人工智能的进步，我们很快就能构建 AI 流程，AI 将决定如何构建一个自动化计划，并满足实现要求所需的所有条件。我们也很快能够使用语音记录构建 Power Automate 桌面流程的指令。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_5.jpg

图 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 提示：

在 Power Apps 或 Power Automate 中，我们可以在左侧导航菜单中找到 AI Hub。如果暂时找不到，可以在更多中找到并将其固定到左侧导航栏，或者通过访问更多 | 发现所有，在其中找到AI Hub并将其固定到左侧导航菜单。
一旦进入 AI 中心，我们可以开始构建 AI 提示和模型。在那里，我们还可以找到一个文档自动化解决方案，结合 RPA 流程和 AI，从各种文档中提取信息，并继续执行文档处理工作流。
从 AI 提示开始 – 在 AI 中心，选择提示。在这里，我们将看到所有预构建提示的列表，并有选项创建自定义提示与 GPT。

AI 提示由提示组成，应该准确清晰，还有 提示设置。我们可以配置多个输入变量并将其添加到提示中，使其高度动态。我们可以使用 Dataverse 中的数据，进一步为 GPT 模型提供知识来源。输出可以是文本或 JSON，有时后者可能更合适，因为我们对展示层有更多控制。在设置中，我们可以选择我们想要使用的模型和温度设置。来使用。
现在我们已经创建了 AI 提示，可以将其添加到我们的应用程序或流程中。在 Power Apps Studio 中开发画布应用时，我们可以在数据部分找到 AI 提示或 AI 模型。
在左侧导航栏中，点击数据 | 添加数据，这会打开一个选项以选择数据源。在这里，我们可以使用搜索栏找到我们的 AI 提示或模型并将其添加到我们的应用程序中：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_6.jpg

图 12.6 – 将 AI 提示添加到画布应用程序中

为了使用 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 模型与添加任何其他操作一样简单，只需在工作流中进行添加：

在 Power Automate 设计器中，工作在我们的工作流时，点击 添加操作 在我们希望添加 AI 能力的地方。
搜索 AI Builder 并从列表中选择一个模型或提示类型。
首先选择模型类型，然后在下一步中，可以将一个连接器操作链接到我们的模型或提示。

与前面提到的示例相关，我们使用了自定义 AI 提示，我们可以通过以下 Power Automate 操作找到我们的自定义 AI 提示： AI Builder | 使用 GPT 创建文本，使用 提示。
我们对连接器进行身份验证，并在参数 | 提示中，从列表中选择我们的提示。
我们提供必要的输入，并继续构建我们的工作流。

在任何后续操作中，我们将能够使用前一操作的输出，这对于 AI Builder 操作也是相同的。举个例子，在 图 12*.7*中，我们正在使用由 GenAI 构建的生成的投诉回复的输出，在审批操作中，允许审核人员审查生成的投诉回复是否恰当。如果是，我们将投诉消息发送给客户：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_7.jpg

图 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 中找到：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_8.jpg

图 12.8 – Azure OpenAI 聊天演示区

以下是步骤：

在 Power Apps 或 Power Automate 中，选择 自定义连接器 在左侧导航栏中，然后点击 新建自定义连接器 | 从空白创建 **。
除了其他数据外，我们需要提供 .openai.azure.com 格式，如下所示： 图 12.8。
在安全选项卡中，我们指定 API 密钥 作为认证类型，它会添加到头部位置。这个密钥是我们在 Power Platform 中创建连接时提供的。它可以在端点 URL 旁边找到，如 图 12*.8*所示，或者通过进入 Azure 门户，在 Azure OpenAI 资源 | 资源管理 | 密钥 和端点中找到。
在定义选项卡中，点击 新建操作 来定义聊天完成 API 操作。在请求部分，我们可以使用 从示例导入 来创建 HTTP POST 请求。在 URL部分，我们提供完整的端点 URL，该 URL 也可以在 Azure OpenAI 聊天游乐场 | 查看代码中找到，如 图 12*.8*所示。聊天完成 API 还需要一个包含系统和用户角色内容的消息体。我们可以包含来自 Azure OpenAI 聊天游乐场的示例有效载荷，以方便添加参数。

操作可以在定义选项卡中进一步自定义，以确保我们为模型提供了所需的信息。
一旦我们满意，就可以继续到测试选项卡，在这里我们将通过提供 Azure OpenAI 服务的 API 密钥来创建连接。之后，我们可以测试连接器。
一旦我们有了一个有效的连接器，就可以像使用任何其他连接器一样，在我们的 Power Platform 解决方案中使用它。

微软最近发布了一个高级版 Azure OpenAI 连接器 (预览版)，适用于 Azure Logic Apps，并且它在 Power Platform 中也能使用。我们预计，在某个时刻，它会作为 Azure OpenAI 的正式发布连接器进行宣布。 Azure OpenAI 连接器简化了 Azure OpenAI 服务与 Power Platform 解决方案之间的连接，允许开发者利用聊天补全操作与他们的 Azure OpenAI GPT 模型交互。然而，由于该连接器仍处于预览阶段，我们建议仍然构建并使用连接到 Azure OpenAI 的自定义连接器：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_9.jpg

图 12.9 – 创建与 Azure OpenAI 的连接

一旦连接器正式发布并广泛可用，我们可以像使用任何其他连接器一样使用它，正如我们在前面的例子中所看到的。

此外，记得使用 连接引用 在我们的解决方案中，如 第十章中所提到的那样。通过使用部署设置文件（如下片段所示），可以更有效地将我们的解决方案在环境之间迁移：

 \"ConnectionReferences\": [ { \"LogicalName\": \"\", \"ConnectionId\": \"\", \"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 中的任何连接器。它们还可以涉及话题管理功能，例如设置变量、检查某些值的条件、调用其他话题等。创建话题使我们能够完全控制机器人和用户之间的对话。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_10.jpg

图 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：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_11.jpg

图 12.11 - GitHub 通知在 Teams 中的示例

Azure DevOps 支持有关已完成构建、推送代码和与拉取请求、发布及工作项相关操作的事件通知。我们还可以对这些事件类型进行更精细的控制，例如仅在项目中添加了新的Bug 类型工作项时接收信息。一旦添加连接器，向导将引导我们完成过程并在 Azure DevOps 中创建服务钩子订阅：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_12.jpg

图 12.12 - 通过 Azure DevOps 的连接器创建服务钩子订阅

除了接收通知，Azure DevOps 还通过允许我们向频道添加标签来与 MS Teams 集成。这些标签可以显示 Azure DevOps 仪表板或看板，提供项目当前状态的实时信息。这样，团队成员无需切换上下文和工具，就能获得这些信息。

GitHub 提供了与 Microsoft Teams 集成的额外功能。我们可以使用 GitHub 与 Microsoft Teams 的集成，这会在 Microsoft Teams 中安装一个聊天机器人，我们也可以通过它接收项目通知、打开或关闭问题、评论拉取请求等。安装链接可以在以下找到： https://teams.github.com/。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_13.jpg

图 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：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_14.jpg

图 12.14 – 创建新的自定义 copilot

如果我们的环境位于美国地区，我们将提供一个对话式创建方式。然而，我们将点击 跳过配置，填写我们的名称和描述字段，点击创建。这将为我们的 copilot 配置预构建的主题。

如果我们希望通过基于我们数据的生成式回答来增强我们的 copilot，可以选择顶部的知识标签，然后点击 添加知识：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_15.jpg

图 12.15 – 向我们的副驾驶添加知识

在这里，我们将使用文件选项上传任何包含相关信息的文件，这些信息可能对我们的团队有用。这可以是包含一般指导或项目特定文档的文件。我们可以通过拖放文件或使用 点击浏览 选项来上传文件。这样，我们的副驾驶就能回答关于该文档主题的问题。文档索引并准备好使用需要几分钟时间。这些文档存储在 Dataverse 文件存储中。

一旦准备好，我们就可以使用 测试你的 副驾驶 选项来测试这个功能。

在副驾驶概览部分，进入知识 | 允许 AI 使用其通用知识（预览），我们可以启用或禁用 GPT 模型所拥有的通用知识。这些是 GPT 被训练时使用的数据。目前，副驾驶工作室仍使用 GPT-3.5-Turbo，截止日期为 2021 年 9 月。我们建议在这种情况下禁用它。

下一步是启用副驾驶中的某个操作。无论我们希望启用什么场景，我们都需要创建一个主题或向副驾驶添加一个操作。我们先从主题开始。

我们从顶部菜单中选择主题选项。在这里，我们可以看到一些预设的主题，分别命名为 第一课， 第二课，和 第三课。这些是我们不需要的预设主题，因此我们可以删除或禁用它们。我们可以通过点击每个主题旁边的三个点，将状态切换为禁用，或者直接点击删除。

我们将通过点击 添加话题 | 从空白开始来创建一个新话题。我们也可以在 Copilot Studio 中使用 Copilot，描述我们需要什么样的话题，并让 Copilot 根据提供的描述提出一个大致的对话流程。现在我们进入了设计器，可以在这里创建话题。我们可以通过点击编辑在短语的 触发器 节点中指定几个短语，这些短语将触发这个话题。

一旦短语被添加后，我们可以继续选择添加节点，点击 **+**号。在这里，我们可以添加控制对话的对话节点。在这个示例中，我们将前往 调用一个动作 | 连接器（预览） 并搜索 Azure DevOps。我们可以选择任何我们想要添加到我们的 Copilot 中，以支持 ChatOps 的动作。例如，我们将选择 创建工作项。这会添加一个连接器动作，并包含我们需要配置的所有输入，以便此连接器动作能够正常工作：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_16.jpg

图 12.16 – 向话题添加动作

我们可以在这个连接操作之前创建一条对话路径，通过一系列问题来询问用户，并将回答存储到变量中，这些变量将作为连接操作的参数。另一种方法是利用 Copilot Studio 中的生成模式，注册连接操作，并让生成式 AI 根据用户问题的上下文自动判断缺失的值。生成式 AI 然后可以向用户提出一系列问题，来获取连接操作所需的缺失值。我们使用 Copilot Studio 中的生成模式并添加生成式操作。首先，我们需要启用生成模式。我们需要进入设置 | 生成式 AI | 生成式（预览）。请注意，该功能目前仍处于预览阶段，不应在生产环境中使用。目前它仅适用于英文协助程序。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_17.jpg

图 12.17 – 在自定义协助程序中启用生成模式（预览）

选择后，点击保存该设置上方的按钮。通过此操作，我们允许生成式 AI 根据用户的消息确定应该调用哪个操作或话题。这也改变了我们触发话题的方式。它们不再是短语，而是转化为话题描述。话题描述包含了我们的话题所执行的操作信息。话题描述的示例可以在 图 12*.18*中看到。这由 GPT 模型使用来确定应该调用哪个操作或话题。话题或操作描述越准确，GPT 模型就越有可能调用正确的操作或话题：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_18.jpg

图 12.18 – 在生成模式下触发话题

我们可以通过点击 X 关闭副驾驶设置，点击位置在 Copilot Studio 右上角。接下来，我们将点击操作 | 添加操作 在顶部菜单栏中。在这里，我们可以使用搜索框查找 Azure DevOps 或 GitHub 连接器的所有可用操作。我们可以选择我们希望启用的连接器操作，例如 从 GitHub 创建问题 ，并继续配置选项：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_19.jpg

图 12.19 – 在 Copilot Studio 中添加连接器操作

每个连接器操作都带有一组输入和输出。我们可以静态设置输入值，或者让生成式 AI 理解用户消息的上下文，并尝试从消息中提取正确的实体，并将它们输入到参数中。对于输出，我们可以让 AI 动态生成输出消息，或者手动配置它。我们将保持默认设置，并允许 AI 针对每个必需的参数向我们提问。在输出中，我们将配置默认设置并让 AI 动态生成响应。通过这种方式，我们现在已经在副驾驶中启用了 创建新问题 操作。我们可以继续启用我们希望在 ChatOps 流程中使用的其他操作。

最后，我们将创建一个与 Power Automate 工作流的集成，以支持更复杂的流程。流程可以像我们之前看到的那样注册为操作。另外，我们可以构建一个主题，并添加一个节点来调用 Power Automate 流程。由于我们已将副驾驶的生成式 AI 设置更改为生成模式，我们需要提供关于我们主题的准确和清晰的信息。在描述完主题后，我们可以通过使用加号 | 调用操作 | 基本操作 | 创建流程来添加一个流程。这将单独打开 Power Automate，并带有输入触发器和输出操作，二者都与副驾驶的集成相关：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_20.jpg

图 12.20 – 为副驾驶创建流程

我们可以继续这个过程，构建主题和流程，并与将支持我们的 ChatOps 流程的操作进行连接。

一旦我们对工作满意并且希望将其部署到 Microsoft Teams，我们需要发布这个机器人。在副驾驶的右上角，我们有发布选项。会弹出一个窗口，我们需要确认发布过程，点击发布。然后，我们可以返回到 副驾驶工作室副驾驶 | 频道 | Microsoft Teams。我们可以点击 启用 Teams 来在 Teams 中启用这个机器人。在这里，我们有 可用性选项，可以让我们将副驾驶分享到 Teams 应用商店中。返回到 Teams 设置，我们有 打开副驾驶 选项，点击它会将副驾驶作为应用打开在 Teams 中。我们的机器人现在已准备好与用户互动并执行 DevOps 操作。如果我们希望将副驾驶添加到 Teams 频道，我们可以在 编辑详细信息 中设置，允许同一租户的用户将此副驾驶添加到团队中。但是，这样会使用户能够将副驾驶添加到他们所在的任何团队中。我们建议查看 Teams 管理选项，并通过 Teams 管理副驾驶的推广过程。

在下图中，我们可以看到一个成功部署自定义副驾驶到 Microsoft Teams 的示例。我们可以看到生成式 AI 功能如何在不同主题之间切换，执行操作，甚至通过提问来获取所有必需的参数值：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_12_21.jpg

图 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  --templateFileName .yaml

这有两个目的。首先，我们可以将整个 copilots 作为代码导出，存储在代码库中，并通过代码进行协作。其次，采用这种方法，我们可以为组织的 copilots 构建模板。我们可以使用这种方法准备一个模板，作为组织各部门 copilots 外观的框架或起点。这将包括一些预定义的主题作为起点。然后，我们可以将这些 copilots 的定义导出为模板文件，并将这些文件存储在中央代码库中的某个地方。当有人请求特定的 copilot 时，我们可以使用预先准备好的模板文件，创建一个包含这些预构建主题的 copilot，并与合适的人分享。导入过程可以通过以下 PAC CLI 命令完成。

在我们能够将 copilot 导入目标环境之前，我们需要确保 connectionReferences 部分已正确更新，以反映目标环境中的适当值。在创建的模板 YAML 文件中，在文件的底部，我们可以找到连接引用，如下所示：以下片段：

 connectionReferences: - managedProperties: isCustomizable: false connectionId:  connectorId: /providers/Microsoft.PowerApps/apis/shared_visualstudioteamservices connectionReferenceLogicalName: template.connectionreference.cr6a8_chatOpsDemo.cr.SyS11HJP displayName: cr6a8_chatOpsDemo.cr.SyS11HJPconnectorDefinitions: - connectorId: /providers/Microsoft.PowerApps/apis/shared_visualstudioteamservices

此外，我们还需要确保在启动该命令之前，目标环境中已经准备好解决方案。我们可以创建一个新的解决方案或使用现有的解决方案。我们可以创建一个新的解决方案或使用现有的解决方案。

一旦所有这些设置完成，我们就可以启动导入命令：导入命令：

 pac copilot create --environment  --schemaName  --templateFileName .yaml --displayName  --solution

如果出现任何错误，这将记录在 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

精通微软 PowerPlatform 上的 DevOps（三）

第十章：在 Power Platform 中启用专业开发人员扩展性

技术要求

启用集成功能——连接器

连接器

连接引用

环境变量

示例 - 将配置与应用程序解耦

准备解决方案

构建部署设置文件

部署设置文件和 DevOps 方法

画布组件和组件库概述

画布组件

组件库

管理组件库的生命周期

了解代码组件

代码组件的组成

清单文件

组件实现

前提条件

创建代码组件

destroy：当组件从 DOM 树中移除时，会调用此方法。 它应被用于执行任何清理操作，并释放组件所使用的任何内存。 此方法需要在代码 实现文件中实现。

初始化项目

实现代码组件

显示所有 Power Pages 网站

下载 Power Pages 网站的内容并将其传输到选定位置。 pac pages download -id -p

我们对文件进行更改，并决定上传这些更改，使用部署配置文件。 pac pages upload –path --environment --deploymentProfile

第十一章：通过设计最佳实践管理环境生命周期

技术要求

基于设计最佳实践

Power Platform 架构良好

可靠性

推荐示例

安全性

推荐示例

卓越运营

性能效率

推荐示例

体验优化

推荐示例

Power Platform 登陆区

Power Platform 登陆区

设计原则和关键设计领域

部署 Power Platform 登陆区参考实现

自动化环境生命周期管理

基础设施即代码（IaC）与 ClickOps

使用 Terraform 进行 Power Platform 管理

使用 Power Platform Terraform 提供程序

传统的自动化环境管理方法

管理环境时的 DLP 注意事项

Power Platform CoE

CoE 启动工具包

环境管理示例

总结

进一步阅读

第十二章：展望未来：与 Copilot、ChatOps 以及 AI 赋能应用一起前行

技术要求

人工智能时代与 GPT 的崛起

人工智能简介

GPT

负责任的 AI

微软协助工具与 Power Platform 中的协助工具

Power Platform 中的 Copilot

从创建者角度看 Copilot 的使用

通过 AI Builder 和 Azure OpenAI 扩展业务解决方案

介绍 AI Builder

AI 模型

AI 提示

使用 AI 模型和 AI 提示

AI Builder ALM

介绍 Azure OpenAI

将 Azure OpenAI 与 Power Platform 集成

ChatOps 和 Copilot Studio

深入了解 Copilot Studio

什么是 ChatOps

ChatOps 的使用案例

将 Microsoft Teams 与 GitHub 和 Azure DevOps 集成

使用 Copilot Studio 为 Power Platform 构建 ChatOps

副驾驶工作室的 ALM

总结

`destroy`：当组件从 DOM 树中移除时，会调用此方法。它应被用于执行任何清理操作，并释放组件所使用的任何内存。此方法需要在代码实现文件中实现。