原文：
annas-archive.org/md5/500a107f5b6fc7d7506eff9576d6eaca译者：飞龙
第六章：深入了解持续集成/持续部署（CI/CD）管道
在本章中，我们将 亲身体验设计 应用生命周期 C ycle Management (ALM) 过程，适用于具有代码优先和低代码/无代码组件的应用程序。 此外，我们还将讨论 DevOps 工程师如何标准化管道 并为它们注入活力 在任何其他 新的 Power Platform 项目中，使用 管道模板 和 可重用工作流 在 Azure DevOps 和 GitHub 作为可重用的构建模块。 我们将深入了解 并对 Power Platform 的 ALM 加速器 包有一个扎实的理解，这个包是 Power Platform 卓越中心启动工具包的一部分，以及我们如何在自己的 DevOps 环境中重用该包中的内容。 我们还将学习 Power Platform 管道 、托管管道，以及它们如何利用专业 DevOps 工具的功能，比如自动化测试。 最后，本章 还将教我们如何 使用开源框架进行自动化测试 及其在 持续集成与持续部署 (CI/CD)管道中的集成。
在本章中，我们将涵盖以下 主要主题：
-
当所有内容汇聚在一起——分支、环境和 Power Platform 目录
-
Azure 管道模板和可重用 GitHub 工作流
-
Power Platform 的 ALM 加速器
-
DevOps 和 Power Platform 管道中的自动化测试
技术要求
要通过使用专业开发 DevOps 工具深入了解我们的 CI/CD 管道，我们需要具备 以下内容：
-
Power Platform 订阅：如果我们已经有了 Microsoft Entra ID 工作账户，我们可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free），或者我们也可以加入 Microsoft 365 开发者计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。
-
Azure DevOps Services 组织：我们可以随时创建一个 DevOps 组织 免费 (https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates)。 如果我们在 Azure DevOps 中创建一个公共项目，我们将获得多个免费的流水线，并免费访问服务的所有功能（请参阅 Azure DevOps for Open Source 提供）。
-
一个 GitHub 账号 和公共代码库（https://github.com/signup），这也 是免费的 ，适用于公共代码库。
-
本章讨论的示例和教程位于 在 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter06。
当一切都合而为一时
在上一章中，我们看到 Azure DevOps Services 流水线和 GitHub 流程如何与我们的 Dataverse 环境和 Power Platform 解决方案互动，以实现 DevOps CI/CD 能力。
分支和环境
如果我们遵循 基于主干的分支策略 或非常相似的 GitHub flow，我们将经常创建短生命周期的分支用于开发目的。 这些分支就是 所谓的 功能分支 ，我们可以用它们来实现新的用户需求或修复客户或内部质量保证过程中发现的漏洞。 。
我们可以使用 Power Platform 构建工具 以及相应的底层 Pac CLI 来创建 开发者 环境。 一个特定解决方案的典型分支 结构可能如下所示：
main
test
devA
devB
devZ
在 分支策略的帮助下，我们可以强制开发者 使用拉取请求将更改合并回测试和/或主分支。 在 Azure DevOps Services 中，如果我们为某个分支配置了任何分支策略（要求 最低审阅者数量， 检查链接的工作项， 检查评论解决，或者 限制合并类型），该分支 将无法删除，并且要求 拉取请求 (PRs) 用于所有更改。 因此，我们可以避免将意外更改直接提交到这些 专用分支：
图 6.1 – 分支策略
检查链接的工作项
我们强烈建议在您的专用主分支和测试分支上强制执行此设置。 它仅仅确保，在没有明确定义的用户故事或 待办事项的情况下，不会有任何更改。
我们也可以在 GitHub 上实现类似的配置。 这被称为 分支保护规则，它提供了更多 选项。 例如，我们可以要求在合并之前进行 PR 审核，要求在合并之前通过状态检查，并限制谁可以推送到该分支。 我们还可以强制 签名提交 通过附加加密签名来验证 提交的真实性。 这个签名是使用提交者的私钥创建的，其他人可以使用提交者的公钥进行验证。 签名提交提供了代码更改来自可信且 授权源的保证。
下图显示了所有可用的保护规则 适用于 GitHub 分支：
图 6.2 – 分支保护规则
无论我们使用哪个 DevOps 工具，我们的目标是创建一个 DevOps 框架，使得专业开发人员不仅能够相互协作，还能与每一个开发人员（公民开发者）合作。 为了在开发过程中设置正确的 质量门控 ，建议 在专用和临时/开发人员 Power 平台环境中映射我们的分支结构：
图 6.3 – 分支与环境
在前面的图中，Power Platform 环境和 Git 分支之间的箭头表示代码 和部署流程。 生产环境 和测试环境只能处理 PR（即解决方案仅被导入到这些环境中），而开发环境应当是双向的，因为这些环境中的更改将被导出回 Git 仓库，并分别更新到开发分支。 在我们的案例中， US_XXX_Y 分支表示 一个短期的功能分支，包含了用户故事的实现。 具有不同触发条件的 CI/CD 流水线管理着这两个世界之间的互动，从解决方案生命周期的开始开始。 流水线/工作流甚至可以用于在整个 开发者旅程中创建这些自动化。
让我们详细看看如何 使用 Azure Pipelines 自动化一些最常见的步骤： 步骤：
-
创建开发者分支：我们可以使用以下 Bash 脚本来创建 一个分支：
git config user.name $(Build.RequestedFor) git config user.email $(Build.RequestedForEmail) #creating the branch under "dev" folder newbranch=dev/${{ parameters.devbranch }} git checkout -b $newbranch git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" push origin $newbranch -
为 Power Platform 开发者环境提供服务：首先，我们需要通过使用 Microsoft 托管的 Windows 机器上的服务主体登录到 Power Platform 环境，因为 Pac CLI 将身份验证凭证以纯文本形式存储在 Linux 机器上：
pac auth create --applicationId 862e5a17-d38b-43ff-b24f-88a77f59623f \ --clientSecret $(ClientSecret) \ --tenant 4ae51f31-033a-48fa-be48-5ece14d2c081我们还需要使用相同的服务主体登录到我们的 Azure 租户，以查明是谁触发了此 Azure Pipeline：
az login --service-principal \ -u 862e5a17-d38b-43ff-b24f-88a77f59623f \ -p $(ClientSecret) \ --tenant 4ae51f31-033a-48fa-be48-5ece14d2c081 AADObjectID=$(az ad user show \ --id $(Build.RequestedForEmail) \ --query id \ --output tsv) $(Build.RequestedForEmail) system variable contains the email address of the user who started the pipeline. We use the Microsoft Entra ID’s user object ID to create a Power Platform developer environment on behalf of this user (the command, per se, runs under the name of the service principal and not on behalf of our users):pac admin create --name “dev-US_XXX_Y” \
–type Developer \
–user $AADObjectID
After creating the Power Platform environment, we need to assign the developer (who has started the pipeline) to it as the System Administrator:获取环境 ID（倒数第二行包含此信息）
rawOutput=$(pac admin list --name dev-us_XXX_Y | tail -n 2)
environmentId=$(echo $rawOutput | cut -d ’ ’ -f 2)
#为创建开发者环境的用户添加系统管理员角色
pac admin assign-user --environment $environmentId --user $AADObjectID --role “系统管理员”
开发者环境
Power Platform 中的每个用户最多可以免费创建三个开发者环境 。
-
导出解决方案,导入解决方案,复制环境, 和备份，针对该环境。 如果我们希望自动化服务连接创建过程，也是可行的。 我们需要创建一个 JSON 文件，将其作为有效载荷发布到REST端点上，供 Azure DevOps 服务使用（参见AzDO/.pipelines/config-tokenizer.yml在第六章文件夹中的 GitHub 仓库）：{ "authorization": { "parameters": { "tenantId": "GUID", "applicationId": "GUID", "clientSecret": "secret" }, "scheme": "None" }, "createdBy": {}, "data": {}, "isShared": false, "isOutdated": false, "name": "ConnenctionName", "owner": "library", "type": "powerplatform-spn", "url": "DataverseURL", "administratorsGroup": null, "description": "", "groupScopeId": null, "operationStatus": null, "readersGroup": null, "serviceEndpointProjectReferences": [ { "description": "", "name": "ProjectName", "projectReference": { "id": "ProjectID", "name": "ProjectName" } } ] }我们可以使用以下 Bash 脚本来标记这个 JSON 文件（参见
AzDO/.pipelines/create-service-connection.yml在第六章文件夹中的 GitHub 仓库）：# Set the filename filename="config_tokenizer.json" # Read the JSON file json_string=$(cat .pipelines/$filename) # Replace the value new_json_string=$(jq '.authorization.parameters.clientSecret = "$(ClientSecret)"' <<< "$json_string") new_json_string=$(jq '.authorization.parameters.tenantId = "$(tenantId)"' <<< "$new_json_string") new_json_string=$(jq '.authorization.parameters.applicationId = "$(applicationId)"' <<< "$new_json_string") new_json_string=$(jq '.url = "${{ parameters.ppdevenvironmentURL }}"' <<< "$new_json_string") new_json_string=$(jq '.name = "${{ parameters.ppdevenvironment }}"' <<< "$new_json_string") new_json_string=$(jq '.serviceEndpointProjectReferences[0].projectReference.id = "$(System.TeamProjectId)"' <<< "$new_json_string") new_json_string=$(jq '.serviceEndpointProjectReferences[0].projectReference.name = "$(System.TeamProject)"' <<< "$new_json_string") new_json_string=$(jq '.serviceEndpointProjectReferences[0].name = "${{ parameters.ppdevenvironment }}"' <<< "$new_json_string") # Write the modified JSON data back to the file echo $new_json_string > config.json如果我们想要在本地执行 这个脚本，那么我们可以使用
az devopsCLI 命令来自动创建我们的 服务连接：echo $(PatToken) | az devops login --organization $(System.CollectionUri) az devops service-endpoint create \ --organization $(System.CollectionUri) \ AzDO/.pipelines/import-solution.yml in the Chapter06 folder of the GitHub repo):steps:
- checkout: git://PowerPlatform/Copilot@${{parameters.sourceBranch}}
displayName: ‘检出源分支’
persistCredentials: true
- task: PowerPlatformToolInstaller@2
inputs:
DefaultVersion: true
- task: PowerPlatformPackSolution@2
inputs:
SolutionSourceFolder: '$(System.DefaultWorkingDirectory)/src/$(solutionName)' SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip' SolutionType: 'Unmanaged'- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)/Solution' ArtifactName: 'Solution' publishLocation: '容器'- task: PowerPlatformImportSolution@2
inputs:
authenticationType: 'PowerPlatformSPN' PowerPlatformSPN: ${{parameters.serviceconnection}} SolutionInputFile: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip' AsyncOperation: true MaxAsyncWaitTime: '60'- task: PowerPlatformPublishCustomizations@2
inputs:
authenticationType: 'PowerPlatformSPN' PowerPlatformSPN: ${{parameters.serviceconnection}}We use `${{parameters.serviceconnection}}` as a string parameter of the pipeline, which represents the name of the service connection previously created.We can put these steps together into one pipeline or keep them separately. We can also chain these pipelines by using other trigger conditions, such as `branch created`. For instance, a new dev branch is created under the `dev/*` condition looks, as follows:trigger:
- dev/*
经过这些自动化步骤之后，我们最终得到了一个开发分支，可以在上面开始我们的工作。 建议使用 Azure DevOps 中的可用工具将一个或多个工作项分配给该分支；否则，后续提交的 PR 将会被自动拒绝（如果配置了推荐的分支策略）。
下图显示了如何分配 分支到 Issue 工作项：
图 6.4 – 将分支链接到工作项
在 Power 平台环境中进行更改 应该在开发分支上反映出版本控制系统中的更改。 为了实现这一点，我们需要创建另一个管道（Export-to-Git），导出我们的托管和非托管解决方案，解包并提交更改到我们的开发分支。 我们在 第五章 中看到了这些构建模块。除了该管道外，我们还需要添加一个步骤来导出未托管的解决方案，并以 Both 类型解包解决方案。要将更改提交回分支，我们可以在 PowerPlatformExportSolution@2 和 PowerPlatformUnpackSolution@2 构建任务完成后，执行以下 Git 命令作为 Bash 脚本：
- checkout: git://$(System.TeamProject)/$(Build.Repository.Name)@${{parameters.targetBranch}}
displayName: 'Checkout Source Branch'
persistCredentials: true
# Configure email/name and checkout git branch
- script: |
git config user.name $(Build.RequestedFor)
git config user.email $(Build.RequestedForEmail)
git checkout origin/${{parameters.targetBranch}} --track
[[Adding here those PowerPlatformExportSolution@2 and PowerPlatformUnpackSolution@2 steps discussed earlier.]]
- script: |
#!/bin/bash
set -e
# Set the path to the directory containing the solution
solution_dir="$(Build.SourcesDirectory)/src/$(solutionName)"
# Find all Solution.xml files in the solution directory and its subdirectories
find "$solution_dir" -type f -name "Solution.xml" | while read -r file; do
# Replace the content of the <Version> tag with 0.0.0.0
sed -i 's|<Version>.*</Version>|<Version>0.0.0.0</Version>|g' "$file"
done
displayName: "Set version number to 0.0.0.0"
- script: |
rm -rf ./out/$(solutionName).zip
rm -rf ./out/$(solutionName)_managed.zip
git add --all
git commit -am "Solution is committed" --allow-empty
git -c httpO.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" push origin ${{parameters.targetBranch}}
通过这个管道的帮助，我们的开发人员可以不断地将他们的更改提交回他们自己的 专用开发分支，进行特性开发。 我们有意将解决方案的版本号设置为 0.0.0.0 ，以避免冲突的合并，并通过 Azure 管道管理版本号。 当开发人员准备好时，他们可以提交 PR 回到 父分支。
让我们讨论一些额外的 DevOps 设计原则和建议 与我们的 DevOps 过程相结合：
-
PowerPlatformPackSolution@2构建任务可以随时从源代码控制中打包我们的解决方案。 这是一个压缩步骤，实际上是将我们的文件夹打包成 ZIP 文件，因此不需要长时间的编译时间。 当然，如果我们有 需要构建的代码组件，例如 PowerApps 组件框架 (PCF) 控件或 Dataverse 插件，或者我们针对同一清单（解决方案）目标多个环境，则值得创建专门的 CI 管道。 -
Export-to-Git管道，我们可以提交 PR 来将我们的更改合并到测试分支，然后再合并到生产分支。 我们可以引入 CD 管道，该管道在目标分支上的 PR 完成后执行。 分支触发：trigger: SolutionChecker or performing automated tests. We can introduce approval processes for staging environments (test and production) to control when changes are approved by release managers or environment administrators, with the help of Azure DevOps Services environments. -
解决方案的版本号 - 何时需要设置它们？ 如前所述，随着 DevOps 的兴起，我们希望只维护一个版本，即我们应用程序在生产中的最新版本。 我们使用版本控制和版本号来追踪更改到 源代码：
# Solution version in source control is not used. Instead, create version at build time from the current build number. - pwsh: | Get-ChildItem -Path "$(Build.SourcesDirectory)\$(RepoName)\${{parameters.solutionName}}\SolutionPackage\**\Solution.xml" | ForEach-Object { (Get-Content $_.FullName) ` -replace '<Version>0.0.0.0<\/Version>', '<Version>$(Build.BuildNumber)</Version>' | Out-File $_.FullName } displayName: 'Update Solution XML with Build Number' name: 1.0.$(Date:yyyyMMdd)$(Rev:.r)这意味着在构建/部署过程中，版本 是实时计算的，使用 Azure 管道的构建名称。 这提供了解决方案版本与生成该版本的管道之间的一对一关系。 该版本。
-
导出到 Git管道中，我们可以引入一个参数，该参数期望部署父分支当前版本的分支名称。 如果我们不想以这种方式覆盖我们的工作，我们可以使用诸如git rebase等 Git 命令将我们的开发分支恢复到父分支的最新版本。 之后，我们需要使用另一个管道将解决方案导入到我们的 开发环境。
总的来说，我们可以通过以下方式管理我们的开发工作 四个管道：
图 6.5 - 管理解决方案的管道
我们可以以同样的方式创建 GitHub 工作流。 那些 Bash 和 PowerShell 脚本可以轻松迁移到 GitHub 工作流，还可以建立与 Azure 类似的分支和仓库结构，并分配 Power Platform 环境。 DevOps 服务。
Power Platform 目录
除了这种 CI/CD 交付到 Power Platform 环境之外，Power Platform 还提供了一个新的概念，用于管理我们可重用的软件包。 该 Power Platform 目录 是一个软件包管理器，包含解决方案模板、PCF 组件、端到端解决方案以及其他可重用资产。 它基于我们在专业开发场景中发布软件包到不同的包管理库时使用的相同概念，例如 NuGet、npm、Maven 和 Pip。 Power Platform 中的目录是一个功能，允许开发者和创建者轻松发现并使用组织内的 Power Platform 模板和代码组件。 它提供了一个私有的中央位置，用于查找和安装最新且最可靠的组件版本，提供能够立即产生价值的模板。 对于管理员和业务审批人而言，目录作为一个唯一的权威来源，用于存储和维护 Power Platform 工件，允许他们策划和控制内容，加速创作者和开发者的价值。 它还为在敏感的监管和法定场景中使用批准的组件和模板启用了审批工作流，提供具有设置 和元数据的管理功能。
为了将目录带入一个专用环境（建议提供一个单独的环境，例如 目录），我们需要将其作为 Dynamics 365 应用从 AppSource 安装： https://appsource.microsoft.com/product/dynamics-365/powerappssvc.catalogmanager-preview?flightCodes=dde212e5c66047c59bf2b346c419cef6。
安装此 D365 应用后，我们可以提交并部署以下资产 到其中：
-
Dataverse 解决方案 (已管理或未管理) 或 软件包部署器软件包 （企业模板也可以 发布到 目录中）
-
模板 用于 Power App 或 Power Automate 流程
-
Power Platform 代码优先组件 如自定义连接器 或 Power Apps 组件框架 (PCF) 控件
Power Platform 目录 引入了额外的安全角色来管理目录项的生命周期—— 目录提交者 用来提交项目到目录， 目录只读成员 用来发现和安装 目录中的项目， 目录批准者 用来批准提交到 目录的项目， 以及 目录管理员 用来管理目录。 我们也从目录中获得了这种企业级的安全性。
我们的 Azure 管道和 GitHub 工作流不仅可以面向环境，还可以面向目录。 Pac CLI 提供了适当的命令，将我们的解决方案、自定义连接器和 PCF 组件提交到目录。 以下脚本创建一个提交到我们的 mpa_ITBase_managed 解决方案（我们在 第四章 用于管理的管道），并从企业模板提交一个新的 目录项：
# Power Platform Catalog Manager application's GUID
pac admin list --application 83a35943-cb41-4266-b7d2-81d60f383695
# environment is the "Catalog" environment
pac catalog list --environment 0b90d036-e017-e840-9287-b1de3d95e252
# create a submission json file
pac catalog create-submission
# update the generated json file
pac catalog submit --environment 0b90d036-e017-e840-9287-b1de3d95e252 --path .\submission.json --solution-zip .\mpa_ITBase_managed.zip
这些脚本也可以代表服务 主体运行。 默认情况下，提交需要由目录管理员批准，但我们可以更改配置，使某些发布者，例如在 Azure 管道或 GitHub 工作流中运行的服务主体，获得 自动批准。
下图展示了 mpa_ITBase_managed 解决方案：
图 6.6 – Power Platform 目录管理器
Power Platform 目录
Power Platform 目录 将在它们变为 管理环境的一部分 后， 正式 发布。
现在让我们继续讨论管道模板和可重用的工作流，它们可以在大规模上提供我们的 Azure 管道和 GitHub 工作流的可重用性。
Azure 管道模板和可重用的 GitHub 工作流
回顾我们前一节中的 Azure 流水线 ，我们可以说，这其实是一个非常好的起点，可以让所有工作自动化。 然而，如果我们需要支持数百甚至数千个应用程序，那么在每个包含这些解决方案的存储库中保留三到四个流水线的方法将变得更加复杂。 随着我们开发的应用程序越来越多，这些 Azure 流水线的不同版本将会并行存在。 如果能有一个集中式存储库，包含这些流水线的业务逻辑，且只在调用它们之前定制一些参数，那就太好了。 这就是 Azure 流水线模板和可重用 GitHub 工作流背后的理念。
Azure 流水线模板 使我们能够创建可重用的业务逻辑，这些逻辑可以在我们的 YAML 流水线实例中使用。 这些模板还可以用来控制流水线中允许的内容，通过定义调用者应遵循的策略。 例如，我们可以通过使用一个充当保护措施的模板来强制执行任务执行约束，确保执行的任何任务都符合我们组织的 安全指南。
例如，以下 AzDO/.pipelines/template/include-paccli-steps.yml 位于 Chapter06 文件夹中的 GitHub 仓库）：
# File: templates/include-paccli-steps.yml
steps:
- bash: |
echo "Installing Pac CLI"
dotnet tool install --global Microsoft.PowerApps.CLI.Tool
displayName: "Installing Pac CLI"
使用此模板的流水线文件会在 Linux 上执行，然后在 Windows 代理上执行（参见 AzDO/.pipelines/azure-pipeline-template.yml）：
# File: azure-pipelines.yml
jobs:
- job: Linux
pool:
vmImage: 'ubuntu-latest'
steps:
- template: templates/include-paccli-steps.yml
- job: Windows
pool:
vmImage: 'windows-latest'
steps:
- template: templates/include-paccli-steps.yml
我们还可以对 Azure 流水线模板 文件进行参数化，调用者流水线可以根据其 定制需求设置这些参数。
相同的 概念，称为 workflow_call。以下可重用的工作流将在目标平台上安装 Pac CLI。 该工具的版本号和目标平台是此流程的参数（参见 GitHub/.github/workflows/install-paccli.yml）：
on:
workflow_call:
inputs:
version:
required: true
type: number
platform:
required: true
type: string
description: "platform"
jobs:
installpac:
runs-on: ${{inputs.platform}}
steps:
- name: install pac cli
shell: bash
run: |
echo "version number: ${{inputs.version}}"
dotnet tool install --global Microsoft.PowerApps.CLI.Tool
要从其他工作流中调用我们的工作流 ，我们需要在我们的 调用者 GitHub 工作流中创建一个专门的任务（参见 GitHub/.github/workflows/Deploy.yml）：
name: Call a reusable workflow
on:
workflow_dispatch:
jobs:
call-paccli-workflow:
uses: jovadker/ppmanaged/.github/workflows/install-paccli.yml@main
with:
version: 8
platform: ubuntu-latest
call-workflow-windows:
uses: jovadker/ppmanaged/.github/workflows/install-paccli.yml@main
with:
version: 8
platform: windows-latest
这个概念在 Azure DevOps 和 GitHub 中的真正力量在于，我们可以将模板 和可复用的工作流放置在同一代码库中的不同位置，甚至放在不同的 Git 代码库中。 如果我们查看为启动开发人员环境、创建服务连接、以及分别从/向环境导出/导入解决方案而创建的管道，我们现在可以将这些模板或可复用的工作流放置在专用的 Git 代码库中。 不同的项目和解决方案可以通过使用这个可复用的概念来调用我们的模板。 相反，我们可以通过减少管理大量项目的整体工作量来集中改进和维护这些工作流。 项目。
除了可复用的 工作流，GitHub 还提供了所谓的 GitHub 启动工作流。GitHub 启动工作流也是存储在组织的 GitHub 代码库中的模板。 当我们在 GitHub 用户界面中创建新工作流时，这些模板会显示出来。 创建工作流后，模板会被复制到我们的代码库中，至此，我们将实例与模板解耦。 我们可以使用 GitHub 启动工作流帮助项目基于我们的 可复用工作流来设置它们的工作流。
现在我们已经了解了管道模板和可复用工作流，接下来让我们学习一下 Power Platform 的 ALM 加速器，它在背后大量使用了这个概念。
Power Platform 的 ALM 加速器
Power Platform 的 ALM 加速器 是一个帮助开发人员自动化 Power Platform 软件开发工作流的工具。 尽管 它是 卓越中心 (CoE) 启动工具包的一部分，该工具包是帮助组织开始采用 Power Platform 的组件和工具的集合，但它也可以作为独立的解决方案安装在我们的 Dataverse 环境中。
ALM Accelerator 包括 Azure 管道模板、Azure 管道和 Power Platform 应用程序，帮助专业开发人员在项目中实现 DevOps 和 ALM。这个加速器包被称为ALM Accelerator for Advanced Makers（AA4AM）解决方案，包含了最初由微软 CoE Starter Kit 工程团队开发的参考实现。成功实现后，团队决定将其开源，并使每个组织都能使用，证明了如何在 Power Platform 中实现健康的应用生命周期管理。我们可以直接使用这些管道和应用程序，或者根据我们的组织需求对其进行自定义，当然，我们也可以从这个团队几年前设计的基本概念中学到很多东西。
我们可以找到关于加速器的全面文档，了解如何安装它，如何基于可用的管道模板创建管道，以及如何在 Azure DevOps 仓库中管理我们的 Power Platform 解决方案。
本章前面讨论过的分支、环境和管道模板，对于理解 ALM Accelerator 如何在后台工作至关重要。加速器的主要功能如下：
-
有一个模型驱动的应用程序，ALM Accelerator for Power Platform Administration，用于创建和管理部署配置文件。部署配置文件描述了解决方案在我们环境中的 CD 流程。它在概念上与我们如何定义 Power Platform 管理管道相同。建议为每个 Power Platform 解决方案创建一个部署配置文件，因为该配置文件还包含有关 Azure DevOps 项目、Git 仓库和目标分支的信息，以及相应的 Power Platform 环境。
-
另有一个画布应用程序，ALM Accelerator for Power Platform，为开发人员提供了一个 UI，并在给定的 Power Platform 环境中可视化解决方案和分配的部署配置文件。
-
通过 ALM Accelerator for Power Platform 画布应用程序，我们可以轻松创建一个分支，并将我们的解决方案版本（更改）多次提交到该分支。
-
Canvas 应用程序提供了一种通过定义的环境移动我们更改的方式。 每次部署（发布）都是对父分支的 PR。 在 Azure DevOps 中完成 PR 后，管道将解决方案导入到部署配置文件中定义的分配环境。
-
建议为每个解决方案创建一个仓库。 该仓库包含我们的管道，利用了加速器提供的管道模板。
-
我们可以添加更多环境，并创建我们在本章开头讨论的相同分支结构。
-
Canvas 应用程序使用自定义连接器，并调用 Azure DevOps Services 的 REST API 端点与 定义的管道进行交互。
-
该
coe-alm-accelerator-templatesGitHub 仓库包含了 ALM 加速器使用的管道模板。 我们需要将此仓库分叉到我们的 Azure DevOps 项目中，作为一个额外的 Git 仓库。 -
我们可以根据我们 组织的需求自定义管道模板。
-
Power Platform 的 ALM 加速器 仅适用于 Azure DevOps Services。
下图展示了 Power Platform 的 ALM 加速器 的工作原理：
图 6.7 – Power Platform 的 ALM 加速器
我们可以看到所选环境中可用的未管理解决方案（开发者环境）。 我们可以使用 提交解决方案、 部署解决方案和 删除解决方案 按钮来触发我们的管道，提交我们的更改，或 启动 PR。
Power Platform 的 ALM 加速器
通过观察本章中前面展示的广泛灵活性 以及管道在托管环境中的有效性，我们应该考虑将 Power Platform 的 ALM 加速器作为一个工具，以帮助我们熟悉各种设计模式和概念。 然后，这些可以被纳入我们自定义的 Azure DevOps 管道，并随后集成到我们的 GitHub 工作流中。
现在，我们已经准备好在组织中操作和管理大量的项目和解决方案。 确保我们应用程序质量的最后一件事是 自动化测试。
DevOps 和 Power Platform 管道中的自动化测试
测试自动化和自动化测试 是 ALM 和 DevOps 流程的核心部分。 没有自动化 测试，我们无法 与其他开发人员共享解决方案，无法作为独立的 SCRUM 团队共同合作解决方案，而且每次修改解决方案时都是一项巨大的挑战，因为我们无法知道我们的应用程序会在回归测试中跌落多远。 为了避免回归并实现高测试覆盖率，我们需要建立与定制开发项目相同的质量保证流程。 Power Platform 提供了多种工具和框架来为 我们的解决方案创建功能测试。
选择, 设置属性, 断言, 和 追踪. 测试表达式构建测试用例。 真 或 假 在测试中。 如果断言返回 假, 测试 用例失败。
使用 Power Apps 测试工作室创建的测试可以通过 Azure 管道执行。 在 进一步阅读 部分提供的逐步指南（使用 Azure DevOps Pipelines 自动化测试）使用测试的回放 URL 作为自动化测试执行的输入。 在 https://github.com/microsoft/PowerAppsTestAutomation 下提供的仓库 MSTest 测试方法使用 AppMagic.TestStudio.GetTestExecutionInfo() MSTest 测试方法然后根据这些结果决定成功或失败。 测试方法的结果还会写回我们的 Azure 管道，我们可以直接在 Azure DevOps 服务的 构建结果中查看测试结果。
Power Apps 测试引擎 是测试 PowerApps 画布应用的最新方法，使用基于 Playwright 的引擎。 Playwright 因其稳定性 和性能、简便的设置、对 Chromium、Firefox 和 WebKit 的统一 API 支持，以及 JavaScript、Python 和 C# 的官方绑定而广受欢迎。 Playwright 最初由微软开发，现已开源并发布供 社区贡献。
PowerApps 测试引擎允许我们使用直观的 Power Fx 语言以 YAML 格式编写测试， 文档对象模型 (DOM) 抽象化使得我们可以使用在设计阶段建立的控件名称引用来编写测试。 这种方法意味着测试作者不需要具备 JS 知识 或对与应用程序视觉输出相关的浏览器 DOM 的了解。 以下 YAML 文件 展示了一个这样的例子：
testSuite:
testSuiteName: Regression test suite
testSuiteDescription: ''
persona: User1
appLogicalName: vadkerti_contentgenerator_48e05
appId: ''
onTestCaseStart: ""
onTestCaseComplete: ""
onTestSuiteComplete: ""
networkRequestMocks:
testCases:
- testCaseName: Test with empty input
testCaseDescription: ''
testSteps: |
=
SetProperty(Prompt.Text, "Writing some test");
Select(SystemPrompt);
SetProperty(Prompt.Text, "");
Select(SystemPrompt);
Select(Prompt);
Select(Button4);
Assert(IsMatch(TextInput4.Text, "I'm sorry, I'm not sure what you are asking. Can you please provide more context or clarify your question?<|im_end|>"), "Different output");
testSettings:
filePath:
browserConfigurations:
- browser: Chromium
device:
screenWidth: 0
screenHeight: 0
locale: en-US
recordVideo: true
headless: true
enablePowerFxOverlay: false
timeout: 30000
environmentVariables:
filePath:
users:
- personaName: User1
emailKey: user1Email
passwordKey: user1Password
我们可以从 Power Apps 测试工作室 下载这个 YAML 文件 并导入 到我们的 PowerApps 测试引擎。
测试引擎还支持 连接器模拟，允许我们在应用程序中围绕连接器和连接创建模拟。 因此，我们可以将应用程序与第三方生产服务隔离进行测试。 此外，测试引擎支持截图和视频录制，允许我们在测试执行的任何时候截屏，并通过视频记录文档化测试序列，这对于故障排除未通过的测试和分析实际用户体验非常有帮助。 未通过的测试场景。
其他我们可以在管道执行期间调用的知名工具，借助 Pac CLI 和 PowerShell 模块， 是 AppChecker (pac solution check) 用于 画布应用程序。
在测试 Microsoft Copilot Studio时，我们可以使用 PVA 测试框架，一个可以在 GitHub 上找到的示例解决方案。 它演示了如何使用 API 和 Direct Line 通道对 Microsoft Copilot Studio 聊天机器人进行测试。 该框架确认机器人在多种情况下按预期运行，包括 以下情况：
-
测试自然语言理解模型以触发 正确的话题。
-
验证多个匹配话题的选项（“您是指…”如果用户意图 模糊不清，副驾驶助手会提出此问题）
-
进行负载测试 的大规模测试
-
完整的 端到端对话测试
-
测试 自适应卡片的功能
-
在 CI/CD 部署管道中添加一个测试步骤，以防测试失败时防止部署 测试失败
我们可以手动创建 对话脚本 ，或者我们可以使用 PVA 测试框架 从 Dataverse 导出现有对话 ，并以 CHAT 格式进行转换。然后，我们可以借助 PVA 测试框架将这些 CHAT 文件转换为 JSON，并让它们通过 Direct Line REST API 端点执行。 该框架可以轻松集成到我们的 Azure 管道和 GitHub 工作流中，因为它是一个.NET 6 控制台应用程序，可以在基于 Windows 的 托管代理上运行。
要测试 基于模型的 Power Apps 和 Power Pages 网站，我们可以使用其他 网页测试 框架，例如： 以下内容：
-
Selenium 测试框架 是一个自动化测试工具集，允许开发人员创建强大的基于浏览器的回归自动化套件和测试。 它可以扩展并分配脚本到多个环境，并支持广泛的编程语言。
-
Playwright 是一个跨浏览器、跨平台、跨语言的 可靠的端到端网页应用测试工具。 它支持所有现代渲染引擎、本地移动模拟、自动等待、网页优先的断言、追踪和完全隔离。 Playwright 使用其 自有 API 与浏览器进行交互。
-
Appium.io 用于移动应用程序测试：Appium 是一个免费开放源代码的软件套件和生态系统，旨在促进跨各种应用平台的用户界面自动化。 这包括移动操作系统（iOS、Android 和 Tizen）、网页浏览器（Chrome、Firefox 和 Safari）、桌面环境（macOS 和 Windows）以及电视操作系统（Roku、tvOS、Android TV 和 Samsung）。 其目标是使任何移动应用程序的自动化成为可能，无论使用什么编程语言或测试框架，完全访问后端 应用程序编程接口 (APIs)和 数据库 (DBs)都可以在 测试脚本中进行访问。
-
Cypress 是一个基于 JavaScript 的端到端测试 框架，建立在 Mocha 上。 它旨在简化为 Web 应用程序设置、编写、运行和调试测试的过程。 Cypress 可以测试任何在 Web 浏览器中运行的内容，并特别擅长处理现代 JavaScript 框架。 Cypress 的一些关键优势包括更快且更可靠的测试、减少的故障率、支持详细报告的仪表盘、并行 测试 执行，以及支持 行为驱动开发 (BDD) 和 测试驱动开发 (TDD) 测试。
-
JMeter 是由 Apache 软件基金会开发的开源工具，用于负载测试和分析各种服务的性能。 JMeter 是用 Java 编写的，可以用于测试各种应用程序和协议的性能和功能行为，例如 HTTP (超文本传输协议)， SOAP (简单对象访问协议)， FTP (文件传输协议)，以及 LDAP (轻量级目录访问协议)。 它 提供了一个功能齐全的 IDE、动态 HTML 报告、多线程框架以及一个高度可扩展的核心，支持可插拔的采样器 和插件。
测试 Power Automate 云流和桌面流是比在浏览器或移动设备上执行 UI 自动化测试更复杂的工程挑战。 截至写作时，没有推荐的框架来实现针对我们的云流和桌面流的集成和系统测试。 由于这些组件被视为业务逻辑层的一部分，我们可以通过它们前面的 UI 组件进行测试，作为 端到端测试。
相反，我们可以通过调用其相应的 REST API 端点并将其结果与我们 期望的结果进行比较，提供部分解决方案来测试 HTTP 触发和 Webhook 触发的云流。
正如我们在 第五章中学习到的， OnDeploymentCompleted 事件可以用于测试我们在部署到目标环境后 的解决方案，该环境被表示为一个部署 阶段。 我们的 Power Automate 云流作为该事件的事件处理程序，可以调用 Azure 管道或 GitHub 工作流执行代码优先的专业开发测试自动化脚本（类似于我们在 第五章中如何调用 GitHub 工作流）来将我们的解决方案提交到 Git 仓库。 下一个部署阶段的预审批门（OnApprovalStarted 或 OnPredeploymentStarted）可以检查前一个环境中测试执行的结果。 如果测试通过，部署到下一个环境 可以继续进行。
最后，我们可以使用其他 Microsoft Azure 服务，如 Azure 负载测试 服务，来对我们的 JMeter 进行测试 Power Platform 解决方案。 JMeter 还提供录制功能，而 Azure 负载测试服务可以模拟数百个并行用户同时与 我们的应用进行交互。
根据解决方案的类型，我们需要选择具有适当深度和广度的测试工具。 我们需要设计和交付的业务或任务关键应用越多，我们就应该在这一 DevOps 领域投入更多的时间和精力。
总结
在本章中，我们探讨了 DevOps CI/CD 流程的高级模式，并学习了如何建立一个强大的分支策略，反映我们解决方案的开发、测试和生产环境。 我们检查了许多自动化创建分支、使用服务连接启动 Power Platform 环境、以及使用各种 Pac CLI 脚本导入和导出解决方案的示例。
我们还深入了解了 Power Platform 目录，作为 Power Platform 的包管理解决方案。 此外，我们还了解了 Power Platform 的 ALM 加速器，以及该解决方案如何使用管道模板、分支策略和环境管理。 最后，我们熟悉了可以与 Power Platform 解决方案一起使用的测试自动化框架。
在下一章中，我们将更进一步，学习在 Power Platform 上实现 DevSecOps 流程。
进一步阅读
-
az devopsCLI： https://learn.microsoft.com/en-us/cli/azure/devops?view=azure-cli-latest -
Windows Subsystem for Linux： https://learn.microsoft.com/en-us/training/modules/wsl-introduction/
-
Azure DevOps 批准 流程： https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass
-
Power Platform 目录： https://learn.microsoft.com/en-us/power-platform/developer/catalog
-
Azure DevOps 管道 模板： https://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops&pivots=templates-includes
-
GitHub 启动 工作流： https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
-
GitHub 可重用 工作流： https://docs.github.com/en/actions/using-workflows/reusing-workflows
-
Power Platform 的 ALM 加速器： https://learn.microsoft.com/en-us/power-platform/guidance/alm-accelerator/overview
-
ALM 的源代码 加速器： https://github.com/microsoft/coe-starter-kit/tree/main/CenterofExcellenceALMAccelerator
-
ALM 加速器管道 模板： https://github.com/microsoft/coe-alm-accelerator-templates/tree/main
-
Power Apps 测试工作室: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/test-studio
-
Visual Studio 单元测试: https://learn.microsoft.com/en-us/visualstudio/test/getting-started-with-unit-testing?view=vs-2022&tabs=dotnet%2Cmstest
-
使用 Azure DevOps 自动化测试的管道: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/test-studio-classic-pipeline-editor
-
PowerApps 测试引擎: https://learn.microsoft.com/en-us/power-apps/developer/test-engine/overview
-
Azure 负载测试服务: https://learn.microsoft.com/en-us/azure/load-testing/overview-what-is-azure-load-testing
-
Microsoft Copilot Studio 测试框架: https://powervirtualagents.microsoft.com/en-us/blog/automate-testing-of-your-power-virtual-agents-chatbots-with-the-pva-test-framework-sample-solution/
-
Microsoft Copilot Studio 实施指南: https://aka.ms/CopilotStudioImplementationGuide
第七章：Power Platform 中的 DevSecOps 概述
DevSecOps 是一种将安全实践融入整个 软件开发生命周期 (SDLC)的软件开发方法论，包括需求分析、规划与设计、开发、测试和质量保证，直到部署和维护。 Power Platform 是一个现代化的应用程序运行平台，使开发者能够构建自定义应用程序、自动化工作流、创建聊天机器人、设计和发布网站等。 该平台拥有强大的安全模型，确保数据保护并遵守行业标准（超过 90 个合规证书）；由 Azure DevOps 或 GitHub 建立的应用程序生命周期管理和 DevOps 流程，在处理任何类型的 开发项目时，默认部分考虑到这种安全整合。
本章将介绍设置安全的 DevOps 开发项目所需的步骤和行动，涵盖多个环境以及 Microsoft Entra ID支持的身份和访问管理。 我们还将学习如何使用 DevOps 工具大规模启动基于 Power Platform 的开发项目，使开发人员和贡献者能够快速构建和部署应用程序，同时保持安全性和合规性标准。 该平台还提供静态分析工具和报告，用于监控某些类型的安全威胁。 这有助于我们在减少网络风险的同时实现高效的生产力。 我们还将讨论使用开源库的自定义代码的安全影响，并将从 安全的角度检查我们的 DevOps 工具。
本章我们将涵盖以下 主要主题：
-
什么是 DevSecOps？
-
Power Platform 的 安全模型
-
机密扫描和静态代码 分析工具
-
解决方案检查器
-
大规模启动 DevSecOps 项目 的实施
-
DevOps 流程的 安全性
技术要求
要深入了解 DevSecOps 方法和工具，我们需要具备 以下内容：
-
Power Platform 订阅：我们可以注册 Power Apps 开发者计划（ https://www.microsoft.com/en-us/power-platform/products/power-apps/free），如果我们已经有 Microsoft Entra ID 工作帐户，或者我们可以加入 Microsoft 365 开发者 计划（ https://developer.microsoft.com/en-us/microsoft-365/dev-program）
-
Azure DevOps 服务组织：我们可以随时创建一个免费的 DevOps 组织（ https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates）。
-
GitHub 账户和公共 仓库： https://github.com/signup
-
GitHub 高级安全：此功能对公共仓库免费开放； 参见 https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security#about-advanced-security-features。
-
示例和演练 本章讨论的内容可以在以下位置找到 ： https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter07
什么是 DevSecOps？
DevSecOps 代表 的是 开发、安全和运维 以及这些领域的协作，以交付安全的应用程序。 它的原则是在定义 DevOps 过程和方法论后不久建立的。 这个理念相同，就是将 左移 的思维方式应用于安全领域，这与我们在质量保证和后来的运维中应用左移思维方式类似。 它是一个框架，将安全性整合到 SDLC 的所有阶段，从这个角度看，它是软件开发组织在处理安全问题时的一次演进，旨在通过引入“安全第一”的思维文化，并在软件开发生命周期的每个阶段（从设计到交付）自动化安全。 组织广泛采用这种方法，减少发布含有安全漏洞的代码的风险，不仅避免了声誉损失，还避免了因 此类失败而造成的高额财务损失。
如果我们回顾在 第一章 中学习到的 SDLC 的主要阶段（需求分析、规划与设计、开发、测试与质量保证、部署和维护），那么我们可以将安全活动和自动化映射到这些阶段，如下图所示：
图 7.1 – SDLC 中的安全性
这些步骤和活动 以及它们的持续改进构成了 安全开发生命周期 (SDL)。 SDL 是一种 软件开发过程，帮助开发人员构建和设计更安全的软件，满足安全合规要求，同时降低开发成本。 它在各项服务中标准化了安全最佳实践，并最终交付更 安全的产品。
让我们详细查看这些活动，并通过 SDLC 分析相应的 安全范围。
设置
在项目的 初始阶段，我们重点关注两个主要的 安全话题：
-
库存管理 是 安全性的重要元素之一，因为它 catalogizes 我们为客户提供的应用程序和服务。 这是我们的 应用目录 ，其中包含 我们的应用程序（产品）和 服务（服务树）在生产中的资产（源代码位置、发布的二进制文件、版本号、Azure DevOps 项目、Azure 管道、GitHub 项目、GitHub 工作流等）在我们组织内部。 借助库存管理，我们可以轻松找到受安全漏洞影响的组件的应用程序所有者。 在具有成熟 DevSecOps 流程的组织中，库存管理是完全自动化的，这意味着每当启动一个新项目时，就会创建一个新的目录项，并触发工作流来启动 Azure DevOps 或 GitHub 项目、Git 仓库、Microsoft Entra ID 组、服务主体、自托管代理、管道等。
-
访问控制管理 指的是 从工程角度访问应用程序工件，以及相应的底层 DevOps 工具。 我们需要定义框架 和 身份与访问管理 (IAM) 解决方案，用于授予产品所有者、工程师、测试人员、架构师、发布经理和运营团队在与开发项目交互时的访问权限。 我们还需要定义如何处理条件访问策略，例如 强制 多因素认证 (MFA) 以访问生产环境，以及我们在与特权身份管理 （PIM）合作时的程度， 例如，向高特权用户或全局管理员提供“即时”特权访问 Microsoft Entra ID 和 Azure 资源。 启用 PIM 后，这些高度特权的活动会被监控并 审计。 值得注意的是，这种访问控制并非我们要开发的应用程序或服务用于身份验证和授权的控制方式。
计划和设计
在设置好项目的适当访问权限和库存管理后，我们从安全角度深入探讨计划与设计阶段：
-
威胁建模 被用来识别我们系统的潜在威胁，通过潜在攻击者的视角，以及他们对我们的应用程序的可能性和影响，在实施任何缓解措施之前进行评估。它是一个典型的风险管理过程，专注于安全。 市场上有多种工具可用于建模威胁，例如 微软威胁建模工具（请参见进一步阅读部分）。作为冲刺计划过程的一部分，我们可以进行威胁建模演练，并根据风险分析来决定是否应缓解某些威胁，并将这些活动作为产品待办事项，标记为安全类别。
-
SecureString类型用于处理我们代码中的凭证。 -
同行评审指南 用于制定同行评审过程：评审将何时执行，执行的频率以及是否会涉及安全专家。 如今，DevOps 流程已经规定了在有拉取请求时必须进行代码审查，DevOps 工具也会详细记录和支持这些发现。
-
预提交钩子 定义了在提交代码更改到代码库之前，我们执行哪些安全检查，例如，在提交之前检查提交内容是否包含敏感信息。 由于时间限制，预提交钩子只能执行静态代码分析规则集的一小部分，但它们是 防止安全漏洞的必要部分，能立即阻止不安全的提交。 我们可以 使用 IDE 安全插件 来执行本地的轻量级安全分析。
提交（CI）
在通过了预提交钩子和代码审查结果后，下一阶段是执行 CI 构建和相关的安全活动，作为拉取请求验证过程的一部分：
-
依赖管理：如今，定制开发的应用程序在很大程度上依赖于 开源软件包。 目前应用程序中，平均 90%的代码包含基于外部软件包或 库的组件。 术语 软件供应链管理 非常常见，因为我们在应用中使用的这些软件包也使用其他第三方组件，而这些组件又使用其他包，依此类推，形成了一个链条。 如果不刷新我们的供应链，识别和暴露这些第三方包中的漏洞将使我们的应用变得脆弱。 像 GitHub Dependabot 这样的工具可以 识别我们供应链中的漏洞（继承的漏洞），并自动创建 Dependabot 警报，发起拉取请求，将更改提交回我们的主分支。 Dependabot 检查可以在 CI 构建过程中执行。
-
静态应用安全测试 (SAST)：这是对代码进行静态分析和安全扫描 以确保安全性。 市场上有几种工具可以用来对我们的代码库进行这种分析，例如 SonarCloud、Fortify 或带有 CodeQL 的 GitHub 高级安全。 这些工具可以集成到我们的 CI 管道中，以便进一步自定义。 静态代码分析结果的输出为 静态分析结果交换格式 (SARIF)开放标准数据。 基于 SARIF 结果，系统会自动创建代码扫描警报， 并且它们可以作为待办事项进行跟踪。 在使用 GitHub 企业版高级安全功能的情况下，我们还可以使用 GitHub Copilot 来自动修复我们的安全问题， 实现完全自动化。
-
安全单元和功能测试：这些是维护我们代码库高质量的其他方式，旨在避免实现 安全漏洞。
-
安全管道：我们需要谨慎关注自动化管道的安全性：谁可以访问哪些管道，管道机密信息存储在哪里（Azure Key Vault），以及我们是否可以使用托管标识来执行工作流程。 在 CI 构建期间，所谓的 软件材料清单 (SBOMs)会被创建，以跟踪构建管道中使用的组件。 SBOM 是软件组件的列表，包括它们的层次关系、版本号、依赖关系和许可要求，通常以 JSON 格式呈现。 SBOM 有助于透明度和供应链的可追溯性声明，并帮助符合要求的启用。 托管池可以用于构建和签署代码，确保构建的完整性和组件治理。 构建成功后，代码会存储在安全的 构件存储中。
-
凭证扫描：我们 可以使用工具扫描我们的代码库，以减少凭证泄露的风险。
部署（CD）
在这个阶段，我们 查看代码库的整体健康状况，除了在提交阶段检查的内容（这些内容也可以在部署阶段重复检查）。 我们在发布过程中引入了额外的安全检查：
-
动态应用安全测试 (DAST)是一种评估软件应用安全性的技术，它在应用程序运行时进行。 它涉及使用 DAST 工具对 Web 应用程序进行模拟的网络攻击，以识别 SQL 注入、跨站脚本攻击和不安全配置等漏洞。 这种安全测试模拟恶意攻击者的行为，以发现实时应用程序中的安全弱点，使开发人员能够在应用发布之前解决这些问题。 安全管道 是为了避免凭证泄露或在生产环境中执行恶意代码。
-
云配置验证 是验证云资源配置是否正确、安全，并符合最佳实践和政策的过程。 这可以通过自动化工具完成，这些工具扫描云资源的配置文件和设置，并报告任何问题或违规行为（例如生产环境中的配置更改，或 IaC 脚本与实际运行配置之间的不一致）。 验证有助于防止配置错误、安全漏洞和合规问题，确保云资源的正确设置和 管理。
-
基础设施即代码 (IaC) 扫描 是分析 IaC 文件以查找 安全漏洞、配置错误以及是否符合最佳实践和政策的过程。 IaC 扫描工具可以检测政策违规并提出修复建议。 甚至可以使用基于 LLM 的工具提示 GPT-4 模型，检测 IaC 文件中的政策违规，并为任何违规行为提供修复建议。 违规和修复会以 SARIF 文件形式报告。
-
安全验收测试 是验证系统在发布或部署前是否满足已定义的 安全要求和标准的过程。 这种测试通常在新系统、升级或部署时进行，包括对信息安全要求的测试以及遵循安全系统开发实践的测试。 验收测试活动可以在单个组件或集成系统上进行，验证活动可以在测试环境中进行，以确保系统不会引入漏洞。 在选择测试数据或来自运营中信息系统的数据时，必须小心，确保没有捕获任何个人身份信息、密码等机密数据或哈希值。 该数据集。
在成功部署到测试环境并随后部署到生产环境后，SBOM 和证据存储用于跟踪 版本发布。
操作与监控
在这个阶段，成功将我们的应用程序发布到生产环境后，我们需要关注以下 安全相关的活动：
-
持续监控 是 持续跟踪、评估和审查信息系统的安全控制和风险的过程。 这一过程有助于确保安全控制随时间保持有效，并确保系统或其环境的任何变化不会引入新的漏洞。 持续监控可以通过自动化工具和过程来实现，这些工具和过程收集并分析来自各种来源的数据，如日志、网络流量和系统配置。 然后，这些数据被用来识别潜在的安全问题，并生成可以用来提高系统安全性的警报或报告。 该系统的安全性。
-
审计日志 是 用于安全检测的监控对象。 进行管理员监控和扫描，以确保系统的安全性。 我们可以考虑我们解决方案的审计日志，就像我们的 DevOps 工具一样。 审计日志对于理解和检测可能来自可疑来源的变化至关重要。 可疑来源。
-
威胁情报 是 收集、分析和传播当前及潜在网络安全威胁信息的实践。 它帮助组织主动检测和应对安全威胁。 Microsoft 威胁情报是一个云服务，利用全球收集的信号上的机器学习算法来检测和缓解安全风险。 该基础设施用于支持 Azure 服务、传统产品、端点（设备）以及其他企业资产。 其目的是保护全球基础设施，支持如 Microsoft Azure 和 Power Platform 等服务。 安全事件和事件管理 (SIEM)工具，如 Microsoft Sentinel 或 Microsoft Defender for Cloud，利用审计日志通过不同的机器学习算法来检测异常和不寻常的模式。 学习算法。
-
无责事后分析 是一种以非惩罚性的方式分析事件或故障的过程，目的是识别根本原因并改进系统和流程，以防止类似事件再次发生。重点在于学习和改进，而不是指责或惩罚。无责事后分析鼓励开放和诚实的沟通，允许团队成员分享他们的错误并从中学习，而不必担心遭受报复。这种方法培养了持续改进的文化，帮助团队构建更具弹性的系统。
在接下来的部分中，我们将看到我们可以为 Power Platform 解决方案应用哪些活动，以及哪些任务由 Power Platform 的运维团队提供。
现在让我们继续了解 Power Platform 的安全模型，学习其安全设计和原则。
Power Platform 的安全模型
微软 Power Platform 运行在微软 Azure 上，受益于在该超大规模平台上可用的所有 PaaS 安全服务，如 Microsoft Sentinel、Microsoft Defender for Cloud、Microsoft Entra 的全面审计日志等。
微软 Power Platform 的安全模型建立在最小权限访问（LPA）的原则之上，这有助于创建具有更精细访问控制级别的应用程序。Power Platform 利用微软身份平台来授权所有 API 请求，采用广泛认可的 OAuth 2.0 协议。此外，作为 Power Platform 基础数据层的 Dataverse 拥有一个全面的安全模型，涵盖了环境级安全、基于角色的安全以及记录和字段级安全、安全角色、通过安全组和应用用户的业务单元和团队，正如我们在第四章中所了解的。
此外，Power Platform 构建在不同的环境中，这些环境是我们应用程序、流程、连接和其他组件的容器，并具有在创建这些环境时定义的地理位置的安全性和数据访问管理能力。
Power Platform 的架构基于零信任安全原则， 永不信任，总是验证 的哲学。 零信任策略 **要求对每个用户和 设备进行严格的身份验证，无论其位置如何（公司内网或外部边界），并且每次访问公司资源时都会进行此检查。 这种方法通过微软身份平台和 Microsoft Entra ID 的能力得以实现。 每次访问 Power Platform 服务端点时，都需要有效的访问令牌（承载令牌）才能执行该端点。 在服务器端，每次请求到达端点时，都会将访问令牌发送到身份提供者（即 Microsoft Entra ID）以验证其有效性。 这些经过数字签名的访问令牌包含关于调用者的声明，用于身份验证和授权目的。 在识别出调用者后，Power Platform 会结合该端点确定其授权级别。 在此，考虑到自定义和内置安全角色、业务单元层级以及团队分配，这些都是 应用级授权。
下图 展示了 Power Platform 在一个 Microsoft Azure 区域中的架构：
图 7.2 – Power Platform 架构
一组网页 前端服务器包含托管在 Azure 应用服务环境中的 ASP.NET 网站。 应用服务环境 提供了底层的专用计算单元，应用服务计划在其上部署。 应用服务计划可以托管一个或多个应用程序（网站）。 这些都是 Azure 应用服务的一部分。 当访问 Power Platform 服务或应用时，客户端的 DNS 会将请求定向到最近的数据中心，具体由 Azure Traffic Manager 确定。 Azure Traffic Manager 提供了几种路由和负载均衡选项，在 OSI 模型的第 4 层进行，例如性能路由（按延迟选择最接近的端点）、加权轮询和基于地理位置的路由（按 地理位置选择最接近的端点）。
前端集群负责处理登录和身份验证过程。 一旦用户通过验证，他们会收到一个 Microsoft Entra ID 访问令牌（OAuth2 令牌）。 ASP.NET 系统会检查令牌，以识别用户的组织（后台使用的是 多租户 帐户类型的 Azure 应用注册）。 然后，它与 Power Platform 全球后端服务进行通信，通知浏览器该组织租户所在的具体后端集群。 之后，客户端与后端集群之间的所有进一步交互都会直接发生，绕过 网页前端。
对于静态资源，如 JavaScript、CSS 和图像文件，浏览器通常会从 Azure 内容分发 网络 (CDN) 获取它们。
Power Platform 服务的核心 运行在 后端集群 中，提供服务端点、后台服务、数据库、缓存和其他各种元素。 后端集群遍布多个 Azure 区域。 单个区域可能容纳多个集群（在前面的图中表示为 规模组 ），使 Power Platform 服务能够超越单个集群的垂直和水平扩展能力，进行水平扩展。
这些后端集群旨在 保持状态，承载它们所服务的所有租户的完整数据集。 存储某个租户数据的特定集群被称为该租户的主集群。 Power Platform 全球后端服务将有关用户主集群的详细信息提供给 Web 前端集群，后者会将请求定向到适当的主后端集群。 每个环境都驻留在一个规模组内，这是一个集体基础设施，旨在提供可扩展且可维护的资源集合。 一个规模组容纳多个客户组织，每个组织拥有自己的数据库，同时共享服务基础设施。 此设置利用了多种 Azure 服务，例如 Azure SQL、Azure 虚拟机和 Azure Cache for Redis。 这些规模组成对建立，分别对应客户选择的区域。 例如，选择美国作为区域时，会在西部美国和东部美国区域形成规模组。 虽然租户元数据和数据通常驻留在集群内，但数据也可以复制到位于同一 Azure 地理区域中配对区域的次要后端集群。 该次要集群在区域性中断期间作为应急备用，否则保持不活动状态。 此外，分散在集群虚拟网络内各种机器上的微服务也有助于 后端的功能。
DevSecOps 流程和活动由 Power Platform 产品团队实现并运营，我们将其视为 这部分 软件即服务 (SaaS)提供的一部分。 这意味着产品工程团队已经建立了从库存管理、访问控制、提交前钩子、同行评审、SAST 和 DAST 分析、安全管道、IaC 扫描到通过威胁情报进行的依赖性分析等一系列控制和防护措施，涵盖了他们的开发流程。 这一方法经过第三方独立审计员的定期审计和认证。 在开发过程中，这些团队还使用 Microsoft SDL 来确保编码最佳实践和威胁建模。 由此得出的结论是，我们需要专注于平台的定制化和可扩展性点，因为这些是 我们可能引入 漏洞的地方。 这些包括但不限于 以下内容：
-
环境 访问管理
-
自定义开发的 Power Apps 组件框架 （PCF）组件
-
Dataverse 自定义工作流活动和 Dataverse Web 资源（HTML 和 JavaScript）
-
Dataverse 配置和 Dataverse 自定义开发的插件
-
Power Fx 表达式
-
Power Pages 自定义代码（HTML、JavaScript、 和 Liquid）
-
我们自己的 DevOps 流程与 CI/CD 自动化脚本
-
解决方案和 库存管理
-
Fusion 架构组件 在 Microsoft Azure 中
在了解 Power Platform 的安全模型及从安全角度看该 SaaS 产品的优势后，让我们进一步了解可以用于静态代码分析、依赖性检查和 密钥扫描的工具。
密钥扫描和静态代码分析工具
尽管市场上有许多其他 SAST 工具， GitHub 高级安全性 （GHAS）提供了 最全面的静态安全代码分析功能，同时支持 Copilot 安全功能。 GHAS 功能 对于私有 GitHub 代码库如下：
-
代码扫描 使用 CodeQL 或其他 您喜欢的工具来查找漏洞 和编码错误。 结果以 SARIF 格式存储，并在 GitHub 的代码库级别进行管理。
-
CodeQL CLI 是一个独立的 工具，我们可以用它扫描代码库中的漏洞和编码错误。 该 CodeQL CLI 与前述的（代码扫描）一起使用，或者可以在其他 DevOps 工具中使用，例如 GitLab 或 Jenkins。
-
密钥扫描 查找 代码库中的秘密、密钥和敏感令牌。 预提交钩子 也可用来阻止本地提交 在到达代码库并创建新 历史记录之前。
-
自定义自动分类规则 有助于 大规模协调 你的 Dependabot 提示 。使用自定义自动分类规则，你可以决定忽略、推迟或触发 Dependabot 安全 更新。
-
依赖性审查 帮助我们 在将不安全的依赖引入我们的代码库之前进行识别 并提供有关许可证、依赖项和依赖项年龄的信息。
这些高级安全功能在每个公共的 GitHub 仓库中都可以使用，无需额外的 费用。
GHAS for Azure DevOps 于 2023 年 9 月正式发布。 此产品提供的代码扫描、密钥扫描和依赖扫描功能与 GitHub 企业版中的功能相同。 GitHub 工程团队已与 Azure DevOps 团队分享这一功能集，就像几年前 Azure DevOps 团队将构建代理（托管运行器）功能提供给 GitHub 产品组一样。
哪种工具，何时使用？
我们只能在 Azure DevOps 中使用 GHAS 来处理 Azure Git 仓库。 如果我们有一个附加到 Azure DevOps 流水线的 GitHub 仓库，我们需要在 GitHub 端使用 GHAS。 Azure DevOps 中的 GHAS 构建任务将 无法工作。
GHAS 基于 的 代码查询语言 (CodeQL)，可以用于构建不同编程语言的代码分析数据库。 CodeQL 支持 C、C++、C#、Java、Go、Kotlin、JavaScript、Python、Ruby、Swift 和 TypeScript。 CodeQL 将代码视为数据，比传统的静态分析工具更有保障地发现潜在的安全漏洞。 通过创建一个与代码库相匹配的 CodeQL 数据库，你可以对这个数据库执行 CodeQL 查询，以查明代码中的问题。 查询结果将显示为 代码扫描警报 ，当你在 GitHub 和 Azure DevOps 中使用 CodeQL 进行 代码扫描时。
CodeQL 在底层创建了一个关系数据库。 每种语言都有自己的架构，CodeQL 使用 提取器 (每种语言都有独特的提取器)来读取代码文件和编译后的二进制文件（脚本语言除外），并建立代码表达式、抽象语法树、数据流图和控制流图的层次表示。 这些构建块存储在数据库中，安全查询会针对这些表执行，以发现特定语言的漏洞和编码错误。 CodeQL 的数据库是我们执行分析时的快照。 GitHub 提供了适用于任何支持语言的查询包。 查询包 由 组成 CodeQL 套件 (qls) 是查询语言文件集（ql 文件）。 这些查询套件帮助我们立即受益于 GitHub 的安全知识和专业技术，并在我们的代码库上执行这些代码扫描规则。 我们还可以使用 Visual Studio Code 和 CodeQL 扩展编写自己的查询，并可以从现有查询套件中派生，增加我们自己的检查（Windows 驱动验证团队就是这样做的，引入了他们自己的自定义 规则： https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/static-tools-and-codeql）。
CodeQL CLI 是 GHAS 服务的一部分，对学生和学术人员免费。 作为独立工具的 CodeQL CLI 支持 macOS、Linux 和 Windows 操作系统，我们可以将其作为二进制文件下载（请参见 进一步阅读）。
我们可以使用 CodeQL CLI 在本地、Azure DevOps 构建代理，或我们的 GitHub 执行器上执行代码分析。
Azure DevOps 和 GitHub 都提供围绕 CodeQL CLI 的构建任务和操作，便于将代码扫描功能轻松集成到现有的流水线 和工作流中：
图 7.3 – DevOps 工具中的 CodeQL CLI 包装器
由于 在 Power Platform 中有许多地方可以引入自定义代码，建议首先了解如何使用 CodeQL CLI 以及如何设置管道和工作流来执行不同的查询包。 最好的地方是 找到Power Platform 的自定义代码在 PowerApps-Samples 仓库，地址是 https://github.com/microsoft/PowerApps-Samples。让我们检查一下本章中的 GitHub 仓库中的自定义 runcodeql_javascript.ps1 文件：
-
我们可以下载 CodeQL CLI 二进制文件（见 深入阅读 | CodeQL CLI 二进制文件），并将解压后的文件夹位置添加到我们的 环境路径中。
-
然后我们克隆该仓库并导航到 目标文件夹：
git clone https://github.com/microsoft/PowerApps-Samples -
让我们下载 JavaScript 和 TypeScript 的查询包：
codeql.exe pack download codeql/javascript-queries --dir ./codeql-pack/javascript -
让我们为 JavaScript/TypeScript 创建 CodeQL 数据库（目前只有一个 JS/TS 提取器）：
codeql-pack and export the results in a CSV file:codeql.exe database analyze .\codeql-database-js .\codeql-pack\javascript\codeql\javascript-queries\0.8.12\codeql-suites\javascript-code-scanning.qls --format=csv --output=results.csv
-
当然，我们可以分析代码并以 SARIF 格式获取结果：
codeql github upload-results to upload our SARIF file to one of our GitHub repositories (we cannot upload back the results to the original repository due to lack of privileges). We need to create a PAT token that grants us access to the repo (security_event):上传结果到 GitHub 仓库
$env:GH_PAT = “ghp_PAT TOKEN”
$env:GH_PAT | & codeql.exe github upload-results `
--repository=ourrepo/test ` --ref=refs/heads/main ` --commit 18cd21585b94dd16c48dc13bc1365269696a75a4 ` --sarif=javascript.sarif --github-auth-stdinWe also need to have a commit hash ID to which we upload the SARIF result.
对于 C# 项目和解决方案，CodeQL 命令略有不同。 例如，当 我们需要实现 Dataverse 插件时，可以使用 C# 查询包，但在这种情况下，我们还需要在分析过程中构建 Visual Studio 项目（见 runcodeql_dotnet.ps1 文件，位于 Chapter07 文件夹下，在 GitHub 仓库中）：
codeql.exe pack download codeql/csharp-queries --dir ./codeql-pack/csharp
codeql.exe database create --language=csharp --source-root . codeql-database --command "dotnet build .\dataverse\DiscoveryService\DiscoveryService.sln" --overwrite
codeql.exe database analyze .\codeql-database .\codeql-pack\csharp\codeql\csharp-queries\0.8.12\codeql-suites\csharp-code-scanning.qls --format=csv --output=csharp-results.csv
我们使用 --command 参数来为一种或多种编译语言创建数据库。 它需要我们用来构建解决方案的 build 命令，例如 dotnet build <<sln 文件路径>>。如果我们使用的是 Python 或 TS/JS，则不需要此选项。
在大规模代码库的情况下，我们可以使用以下技巧来优化 CodeQL 的运行时：
-
查询包：我们 可以创建自己的查询包，基于公开可用的查询包，也可以创建自己的查询套件，专注于不同的代码扫描和安全扫描分析，这取决于我们在流水线中的时间。 例如，在拉取请求验证构建期间，我们希望通过专注于最关键的安全漏洞来最小化分析的执行时间，而构建主分支时则会执行所有可用的 查询套件。
-
codeql database analyze：如果我们希望使用多个线程运行查询，可以使用--thread参数 。默认值为1，这意味着分析仅在一个线程中运行。 我们可以指定更多的线程来加速查询执行。 要将线程数设置为逻辑处理器的数量，我们可以将此参数设置为0。 -
仅针对部分代码库执行 CodeQL：理想情况下，我们可以拥有拉取请求流水线/工作流，这些工作流不仅包含拉取请求发生的触发条件，还可以 包含 路径过滤器 来过滤源代码中的变更。 这样，CodeQL 只会针对源代码层次结构中已变更的部分执行。 通过这种方式，CodeQL 仅在源代码中已更改的区域运行。
最后，我们深入了解可用的 Azure 流水线构建任务 在 .pipelines/codeql.yml 文件中，该文件位于 Chapter07 文件夹下的 GitHub 仓库中：
- 让我们 导入 https://github.com/microsoft/PowerApps-Samples 到我们的 Azure DevOps 项目中。 我们需要进入 代码库 并点击包含所有仓库的下拉列表，在该列表中我们可以找到 导入仓库 操作项：
图 7.4 – 导入 Git 仓库
在这里，我们可以添加 GitHub 公共仓库的 URL 并 导入 PowerApps-Samples。
- 通过打开项目设置启用 Advanced Security 功能（需要项目管理员权限），然后选择最近导入的仓库。 我们 需要启用 Advanced Security ，方法是切换 按钮：
图 7.5 – 在 Azure DevOps 中启用高级安全功能
-
启用此安全功能后，我们可以导航到 Pipelines，然后我们可以创建一个新的管道 YAML 文件，该文件将存储在新的 Git 仓库中。
-
YAML 文件应如下所示：
trigger: - none pool: vmImage: ubuntu-latest steps: - task: PowerPlatformToolInstaller@2 inputs: DefaultVersion: true - task: AdvancedSecurity-Codeql-Init@1 inputs: languages: 'javascript' querysuite: 'code-scanning' - task: AdvancedSecurity-Codeql-Analyze@1 inputs: WaitForProcessing: true此 YAML 文件将执行与之前使用 PowerShell 对 JavaScript 进行的相同的 CodeQL 分析，通过 CodeQL CLI。
-
代码扫描和密钥扫描警报列在 Repos 下的 Advanced Security 选项卡中，位于 Azure DevOps 中：
图 7.6 – 在 Azure DevOps 中的代码和密钥扫描结果
在 GitHub 的情况下，我们可以通过分叉 PowerApps-Samples 并创建 与代码分析相关的操作（请参阅 .github/workflows/codeql.yml 文件，位于 Chapter07 文件夹中的 GitHub 仓库中）：
name: "CodeQL"
on:
workflow_dispatch:
jobs:
analyze:
name: Analyze javascript
runs-on: ubuntu-latest
timeout-minutes: 120
permissions:
# required for all workflows
security-events: write
# only required for workflows in private repositories
actions: read
contents: read
steps: - name: Checkout repository
uses: actions/checkout@v4
- name: Initialize CodeQL
uses: github/codeql-action/init@v3
with:
languages: javascript-typescript
build-mode: none
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v3
with:
category: "/language:javascript-typescript"
使用 Azure DevOps 管道模板和可重用的 GitHub 工作流，我们可以轻松地在每个项目中引入这些额外的代码扫描和安全分析步骤。 幸运的是，还有另一种方法可以在 Power Platform 解决方案中注入安全验证和代码扫描检查，那就是 解决方案检查器。
解决方案检查器
解决方案检查器 利用 Power Apps 检查服务，通过提交任务到 Power Platform 后端执行代码分析。 有 预定义的 规则集 和 规则 用于覆盖我们解决方案的某些安全建议和编码最佳实践。 解决方案检查器可以以 SARIF 格式报告找到的问题，我们可以轻松将其上传到我们的 DevOps 工具中，例如使用 GitHub 的 GHAS 或 Azure DevOps 的 GHAS。 解决方案检查器检查以下 Power Platform 资产 中的非托管解决方案：
-
Dataverse 自定义 工作流活动
-
Dataverse Web 资源（HTML 和 JavaScript）
-
Dataverse 配置，例如 SDK 消息步骤
-
Power Automate 流程（通过 Power Automate Flow Checker）
-
Power Fx 表达式（通过应用检查器 – Power Apps 检查服务的一部分）
规则集及其规则是预定义并分类的，涵盖了之前列出的组件：插件或工作流活动、Web 资源以及画布应用。 我们可以通过多种方式执行 解决方案检查器，以检查 非托管解决方案：
-
在 Power Apps 创建者门户的 解决方案 面板中。
-
使用
pac solution check命令，带上正确的参数，例如 如下：pac solution check call on that blob using Microsoft.PowerApps.Checker.PowerShell, and respectively the Get-PowerAppsCheckerRulesets cmdlet for fetching the pre-built rulesets and the Invoke-PowerAppsChecker cmdlet for submitting the analysis job to the Power Platform backbone. However, these cmdlets are in the pre-release version and they might change. -
使用 以下 Power Apps 检查器 Web API：Power Apps 创建者门户、PAC CLI 和 PowerShell 模块都依赖于这些 REST API 端点。 我们可以直接调用这些端点，前提是有适当的访问令牌；例如， 美国端点可通过以下 URL 访问： 以下是 https://unitedstates.api.advisor.powerapps.com。
-
使用 托管环境 在导入解决方案到目标环境之前强制执行解决方案检查器运行。 在此，我们可以阻止导入解决方案，如果遇到违反这些规则的情况 。
-
利用
PowerPlatformChecker@2) 在从 Git 仓库导入解决方案的过程中。 此任务在后台使用 PAC CLI。
让我们来看一下在 Azure 管道中执行静态代码分析的构建任务，该任务分析我们的 解决方案（见 .pipelines/solution-checker.yml 在 第七章 文件夹中的 GitHub 仓库）：
trigger:
- none
pool:
vmImage: ubuntu-latest
variables:
solutionName: "PacktCopilotSolution"
steps:
- task: PowerPlatformToolInstaller@2
inputs:
DefaultVersion: true
- task: PowerPlatformPackSolution@2
inputs:
SolutionSourceFolder: '$(System.DefaultWorkingDirectory)/src/$(solutionName)'
SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip'
SolutionType: 'Unmanaged' - task: PowerPlatformChecker@2
inputs:
authenticationType: 'PowerPlatformSPN'
PowerPlatformSPN: 'dev-US_XXX_Y'
FilesToAnalyze: '$(Build.ArtifactStagingDirectory)/Solution/$(solutionName).zip'
RuleSet: '0ad12346-e108-40b8-a956-9a8f95ea18c9'
PowerPlatformChecker@2 task to perform the solution check. The RuleSet GUID is the solution checker ruleset. There is only one other and that is AppSource certification for submitting solutions for Microsoft AppSource. We need to define a service connection, as we did in *Chapter 6*, to connect to an environment because the AppChecker service job executes solution validations in environments. Although we reference here a local unmanaged solution, that solution is uploaded to the environment before the analysis. The results are not stored in the environment but exported as a SARIF file. The build task also publishes the SARIF result to the artifacts of pipeline results.
In the case of GitHub, we can use the following workflow to achieve the same result (see `.github/workflows/solution-checker.yml` in the `Chapter07` folder of the GitHub repo):
名称：解决方案检查器
触发：
workflow_dispatch:
作业：
solutioncheck:
在：ubuntu-latest
环境：
解决方案：mpa_ITBase
步骤：
- 使用：actions/checkout@v3
- 名称：安装 Power Platform 工具
使用: microsoft/powerplatform-actions/actions-install@v1 - 名称: 打包未管理的解决方案
使用: microsoft/powerplatform-actions/pack-solution@v1
使用：
解决方案文件夹: ${{ env.Solution }}
解决方案文件: ${{ env.Solution }}_unmanaged.zip
解决方案类型：未管理
- 名称：检查解决方案
使用: microsoft/powerplatform-actions/check-solution@v1
使用：
环境网址: https://yourorg.crm.dynamics.com
应用程序 ID: 862e5a17-d38b-BBBB-FFFF-88a77f59623f
客户端密钥：“${{ secrets.CLIENTSECRET_DEV }}”
租户 ID：4ae51f31-033a-XXXX-YYYY-5ece14d2c081
microsoft/powerplatform-actions/pack-solution@v1，还将 SARIF 结果上传到 GitHub 工作流运行的工件中。
管理发现
无论是使用带有 SARIF 结果的解决方案检查器、GHAS，还是其他代码和依赖扫描工具执行 SAST，在收集结果后，我们还需要管理这些发现。 我们可以通过接受这些风险来减轻风险，例如在测试代码中的安全警报不被修正，或者我们可以引入新的问题或工作项，根据发现和相应描述的漏洞 在 **常见弱点枚举** (**CWE**) 数据库中。 现代 DevOps 工具支持将代码扫描、依赖扫描和密钥扫描警报链接到工作项或问题，并在开发 生命周期中引入修复需求。
现在我们已经熟悉了解决方案检查器、GHAS 功能以及与 SDLC 方法论相关的 DevSecOps 流程中的任务，我们将这些知识与来自 *第六章*的自动化 DevOps 流程结合起来。
大规模启动 DevSecOps 项目
在 *第六章*中，我们学习了如何为我们的 Git 仓库分配解决方案并相应地设置底层分支来启动 Power Platform 环境。 我们在 GitHub 中创建了管道模板和可重用的工作流，以提供以下自动化功能：
+ 启动新的 Power Platform 开发者环境
+ 为这些 Power Platform 环境创建服务连接
+ 从开发者环境导出解决方案到 Git 分支
+ 通过拉取请求或直接将解决方案从 Git 仓库和分支导入目标环境，或导入到我们的 开发分支
我们可以在这段旅程中迈出一步，自动化整个 Power Platform 解决方案的开发过程。 首先，让我们引入一个新术语：工作负载。 **工作负载** 由一个或多个相互配合的解决方案组成，旨在实现复杂的业务需求。 我们可以将它们视为包部署器包的输入解决方案，例如我们在 **企业模板** 中学到的内容，在 *第四章*中学到的内容。要为工作负载或独立解决方案设置一个企业级的 DevSecOps 项目，我们需要完成以下额外的自动化任务：
1. 为所有者和贡献者创建 AAD 组（Microsoft Entra ID 组）。 必须至少有两个所有者在 `所有者` 组中。 在大多数情况下，我们建议指定一个预算所有者和一个技术所有者来负责 项目。
1. 为每个工作负载创建测试和生产环境，或者使用现有的共享环境来托管更多的解决方案 。
1. 为这些环境创建 服务主体，使用 `pac admin create-service-principal` 和之前创建的 `所有者` AAD 组 。
1. 创建一个 Azure DevOps 项目，并将 `所有者` AAD 组分配给 `贡献者` 组， **贡献者** 组分配给 Azure DevOps。
1. 为工作负载或解决方案在 Azure DevOps 项目中创建一个 Git 仓库，并设置分支策略 。
1. 为这些环境创建服务连接，使用我们创建的服务主体。 这正是我们在 *第六章*中所做的。
1. 创建使用位于单独专用库中的管道模板的 CI/CD 管道，并配置它们以使用这些新的服务连接 作为参数。
最终，我们可以实现以下的 项目设置：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_7.jpg>
图 7.7 – DevSecOps Power Platform 项目
我们可以在此看到 这里的 `所有者` 和 `贡献者`) 可以在项目中工作。 成员变更被记录到 **Azure Log Analytics 工作区** 并 由 SIEM 解决方案监控，如 Microsoft Sentinel（威胁情报）。
我们可以借助 的帮助 **Azure 管道** 位于一个单独的 Azure DevOps 项目中。 让我们详细查看这些步骤 ：
1. 创建 AAD 组：
要创建 AAD 组，我们可以使用以下脚本（参见 `create-aad-group.sh` 在 `第七章` 文件夹中的 GitHub 仓库）：
```
#!/bin/bash
set -e
# Variables
SERVICE_PRINCIPAL_APP_ID="<your-service-principal-app-id>"
SERVICE_PRINCIPAL_SECRET="<your-service-principal-password>"
TENANT_ID="<your-tenant-id>"
GROUP_NAME="<your-group-name>"
# Login as the service principal az login --service-principal -u $SERVICE_PRINCIPAL_APP_ID -p $SERVICE_PRINCIPAL_SECRET --tenant $TENANT_ID # Create the AAD group az ad group create --display-name $GROUP_NAME --mail-nickname $GROUP_NAME # get the user object id AADObjectID=$(az ad user show \
--id $userPrincipalName \
--query id \
--output tsv) # add a member to the group pac admin create commands to create Power Platform developer environments. To create a sandbox or a production environment, we can use the following script (see create-powerplatform-env.sh in the Chapter07 folder of the GitHub repo):
```
#!/bin/bash
set -e
# 定义环境变量
SERVICE_PRINCIPAL_APP_ID="<your-service-principal-app-id>"
SERVICE_PRINCIPAL_SECRET="<your-service-principal-password>"
TENANT_ID="<your-tenant-id>"
ENV_NAME="YOUR_ENV_NAME"
REGION="YOUR_REGION"
CURRENCY="YOUR_CURRENCY"
LANGUAGE="YOUR_LANGUAGE"
# 使用服务主体登录到 Power Apps pac auth create --applicationId $SERVICE_PRINCIPAL_APP_ID --clientSecret $SERVICE_PRINCIPAL_SECRET \
--tenant $TENANT_ID # 创建一个新环境 pac admin create --name $ENV_NAME --region $REGION \
--currency $CURRENCY --language $LANGUAGE \
--type 生产环境
rawOutput=$(pac admin list --name $ENV_NAME | tail -n 2)
environmentId=$(echo $rawOutput | cut -d ' ' -f 2) #启用托管环境 pac admin set-governance-config \
--environment $environmentId \
pac admin set-governance-config 命令以启用托管环境功能。
```
```
1. 创建 服务主体 用于环境：
正如我们在 *第五章*中所做的，我们可以使用以下 PAC CLI 命令来创建一个分配给新创建环境的服务主体：
```
AzureKeyVault@2 build task.
```
1. 创建一个 Azure DevOps 项目：
在这里，我们需要使用 一个 `System.AccessToken` ，并且我们可以引用这个令牌来执行管理或全组织范围的操作。 通过这种方式，我们可以消除 个人访问令牌的使用，并且我们可以在集合级别为构建服务帐户授予访问权限和特权。 为此，我们需要禁用 **将作业授权范围限制为当前项目（针对非发布管道）** 和 **将作业授权范围限制为当前项目（针对发布管道）** 选项，位于 **项目设置** 中的 **设置** 面板，在将托管我们管理管道的项目中，如下图所示：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_8.jpg>
图 7.8 – System.AccessToken：项目与组织范围
如果这些切换按钮被禁用，我们需要在组织级别关闭它们。 最后，我们需要在我们的管道中授予权限，使用 `$(System.AccessToken)` 系统变量来执行以下脚本（请参见 `.pipelines/setup-azure-devops-project.yml` ，位于 `Chapter07` 文件夹中的 GitHub 仓库）：
echo $(System.AccessToken) | az devops login --organization $(System.CollectionUri)
az devops project create --name ${{ parameters.projectName }} --org $(System.CollectionUri)
aadAdminGroupId=$(az ad group show --group $(AADGroupForAdmin) --query id -o tsv) echo "Admin group id: $aadAdminGroupId" azureDevopsAdminGroupDescriptor=$(az devops security group list --organization $(System.CollectionUri) --project ${{parameters.projectName}} | jq -r '.graphGroups[] | select(.displayName=="Project Administrators") | .descriptor') echo "Azure DevOps Admin Group Descriptor: $azureDevopsAdminGroupDescriptor"
# Add the AAD group to the Administrators groups in Azure DevOps
collectionUri=$(System.CollectionUri)
orgnamewithouthttps=${collectionUri//https:\/\//} curl -u :$(System.AccessToken) \
-H "Content-Type: application/json" \
-d "{\"originId\": \"$aadAdminGroupId\"}" \
az devops security group membership add --group-id $azureDevopsAdminGroupId --member-id $aadAdminGroupId --org $(System.CollectionUri) command doesn’t work across projects.
1. Create a Git repository:
When creating a new Azure DevOps project, a default Git repository with the name of `project` and a default team is created. To create a repository, we can use the `az repos create` command with the appropriate parameters. We need the following variables in our Bash script:
```
# 变量
organizationURL="<Your-Azure-DevOps-Organization-URL>"
project="<Your-Azure-DevOps-Project>"
repository="<Your-New-Repository-Name>"
pat="<Your-Personal-Access-Token>"
main 分支：
```
```
organizationName=$(basename $organizationURL) git clone https://$organizationName@dev.azure.com/$organizationName/$project/_git/$repository cd $repository git checkout -b main echo "# $repository" >> README.md git add .
git commit -m "初始提交"
main 分支通过引入对拉取请求中关联工作项的检查，防止直接提交（请参见 GitHub 仓库中create-gitrepo-and-branch-policy.sh，位于Chapter07文件夹）：
```
az repos policy work-item-linking create \ ....--branch "refs/heads/main" \
--enabled true --organization $organization --project $project \
--repository $repositoryId --blocking true --detect false
```
```
2. Create service connections for Power Platform environments:
We did this exercise in *Chapter 6*, in the *Branches and* *environments* subsection.
3. Create CI/CD pipelines on pipeline templates:
To create an Azure pipeline that uses a pipeline template from a different Git repository in a different Azure DevOps project, we can use the `resources` keyword in our pipeline YAML file to specify the repository containing the template. Then, we can reference the template in our pipeline. Here is an example for this (see `.pipelines/azure-pipelines-using-template.yml` in the `Chapter07` folder of the GitHub repo):
```
资源：
仓库：
- 仓库：templates
类型：git
名称：OtherProject/TemplateRepo
引用：refs/heads/main
端点：MyServiceConnection 步骤： #或阶段：
- 模板：.pipelines\ include-paccli-steps.yml@templates
--yml-path 选项。要创建这些 YAML 文件，我们可以使用先前讨论过的 Git 命令提交基线流水线，这些流水线已经引用了丰富了秘密扫描和静态代码分析的流水线模板。
```
At the end of these steps, we have the new Azure DevOps project and the new Git repository with pipelines in place that use the service connections to connect to the Power Platform environments and leverage pipeline templates located in a centralized repository governed by Microsoft Entra ID.
We can realize the same approach in GitHub. The only difference here is that we need to configure our GitHub organization to use Microsoft Entra ID through the **SAML protocol**. GitHub can provision enterprise accounts with the help of a **system for cross-domain identity management** (**SCIM**) configuration. This means we can add Microsoft Entra ID accounts to GitHub Enterprise organizations and, respectively, repositories, and those users can sign in.
Microsoft Entra ID
Regarding the DevOps tools we use, the main security takeaway is that we need to embrace Microsoft Entra ID accounts and, respectively, groups to manage access to projects, repositories, pipelines, work items, workflows, and so on. From the administration perspective, we want to manage only memberships of Entra ID groups to grant or remove access to DevOps services and we do not allow individuals account-level access to our services.
Of course, there are many other tasks that we can introduce in our development life cycle stages. One of the most crucial activities is Inventory Management as discussed in the *Setup* section of this chapter. Inventory Management can be realized within Power Platform on Dataverse as well. The setup of new development projects can be managed with the help of Power Automate cloud flows that execute those previously discussed Azure DevOps pipelines behind the scenes. The Inventory Management repository can store the metadata about our projects, such as who the owners are, where the source code/solution packages are located, which Entra ID groups are created, which Power Platform environments are spun up, and so on.
However, as illustrated in the following figure, there are numerous additional tasks, including those activities we discussed at the beginning of the chapter in conjunction with custom development projects, that occur at different stages of the SDLC of Power Platform solutions:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_9.jpg>
Figure 7.9 – DevSecOps activities in Power Platform solutions
For instance, we can introduce more security analysis tasks in our pipelines, such as using GHAS or CodeQL for SAST, we can create our own build farms for our dedicated builds, apply code signing for our binary components or even for our Power Apps native mobile apps (wrap the app), perform DAST, execute test automation during CI/CD steps, and also set up advanced monitoring to read and analyze the DevOps audit logs or even the application logs. This is only the tip of the iceberg since projects and organizations are continuously improving their DevSecOps practices and, with that, their security postures as well.
We now delve into our final topic, the security of our established DevOps processes.
Security of DevOps processes
Creating DevSecOps processes and setting up whole development projects fully automated from scratch is necessary to infuse security tasks in every phase and stage of the development life cycle. On the other hand, we need to consider our established DevSecOps processes for security vulnerabilities and the attack surface as well. In the previous sections, we have seen that with the help of Microsoft Entra ID groups, we can control and guardrail access to our running projects, but it is only one of the first steps to create more secure methods in those processes. We need to continuously monitor the activities of our engineers and DevOps teams, such as accessing repositories and executing workflows/pipelines by logging them to Log Analytics workspaces. We can then use threat intelligence tools such as Microsoft Azure Sentinel to discover unusual patterns throughout the application life cycle. We can also create threat models using Microsoft’s Threat Modeling Tool on our own CI/CD pipelines to play around with security scenarios, such as how to avoid vulnerable code injections through DevOps tools, or how to avoid granting access to a developer in production environments via DevOps pipelines or GitHub workflows from risk and probability perspectives.
Mission-critical workloads operating in highly regulated industries and environments, such as the US government cloud or deployments in the financial sector, require even more guardrails in place. We can fully isolate Power Platform development tenants from production ones. The handover between these separate tenants can happen through **Azure Service Bus** or other messaging queue services, as the following figure shows:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_07_10.jpg>
Figure 7.10 – Isolated tenants
On the development side, Azure pipelines or GitHub workflows build the managed and unmanaged solutions and place them in Azure Blob Storage. They also queue new messages in the message queue that contain the metadata information about the deployment, such as which solution from which blob container with which version the production side pipelines should deploy to. They also contain the SAS tokens to access Blob Storage from the production tenant. On the production side, Power Automate cloud flows pick up the queue message triggered by the Service Bus condition and execute the deployment based on the queue message to the targeted environments. With that, there is no direct, synchronous connection between development and production tenants. We apply the **asynchronous design pattern** here (pulling model) to terminate the original synchronous deployment call to our production environment.
Summary
In this chapter, we explored the DevSecOps process, delving into its evolution, the concept of a shift-left mindset, and the integration of security tasks within our SDLC. We then acquainted ourselves with the security architecture and guiding principles underpinning Power Platform. Our journey continued with an examination of GHAS, leveraging CodeQL to conduct SAST. We also investigated the solution checker, utilizing Azure DevOps build tasks and GitHub Actions to perform the platform’s built-in analysis. Our deep dive extended into the realms of the Azure CLI, Azure DevOps scripts, pipelines, and pipeline templates, enabling us to construct an Azure DevOps project embedded with security from the ground up in a fully automated manner. Lastly, we dedicated time to understanding the security threats that could potentially compromise our DevOps pipelines or workflows and discussed strategies to mitigate these risks.
In the next chapter, we will craft a tangible solution, applying every aspect of DevOps and ALM through practical, hands-on walkthroughs.
Further reading
* DevSecOps controls: [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls)
* **Security Development Life Cycle**(**SDL**) Practices: [https://www.microsoft.com/en-us/securityengineering/sdl/practices](https://www.microsoft.com/en-us/securityengineering/sdl/practices)
* Threat Modeling: [https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling)
* Microsoft threat modeling tool: [https://aka.ms/threatmodelingtool](https://aka.ms/threatmodelingtool)
* GitHub Dependabot: [https://docs.github.com/en/code-security/dependabot](https://docs.github.com/en/code-security/dependabot)
* CodeQL: [https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql)
* Security in Power Platform: [https://learn.microsoft.com/en-us/power-platform/admin/security/overview](https://learn.microsoft.com/en-us/power-platform/admin/security/overview)
* GitHub Advanced Security for Azure DevOps: [https://azure.microsoft.com/en-us/products/devops/github-advanced-security](https://azure.microsoft.com/en-us/products/devops/github-advanced-security)
* CodeQL CLI binaries: [https://github.com/github/codeql-cli-binaries](https://github.com/github/codeql-cli-binaries)
* CodeQL query packs: [https://github.com/github/codeql](https://github.com/github/codeql)
* CodeQL analysis: [https://docs.github.com/en/code-security/codeql-cli/getting-started-with-the-codeql-cli/preparing-your-code-for-codeql-analysis](https://docs.github.com/en/code-security/codeql-cli/getting-started-with-the-codeql-cli/preparing-your-code-for-codeql-analysis)
* Solution checker: [https://learn.microsoft.com/en-us/power-apps/maker/data-platform/use-powerapps-checker](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/use-powerapps-checker)
* PAC CLI for solution checker: [https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/solution#pac-solution-check](https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/solution#pac-solution-check)
* Microsoft.PowerApps.Checker.PowerShell module: [https://learn.microsoft.com/en-us/powershell/module/microsoft.powerapps.checker.powershell/invoke-powerappschecker?view=pa-ps-latest](https://learn.microsoft.com/en-us/powershell/module/microsoft.powerapps.checker.powershell/invoke-powerappschecker?view=pa-ps-latest)
* System access token: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml)
* Work item branch policy: [https://learn.microsoft.com/en-us/rest/api/azure/devops/policy/configurations/create?view=azure-devops-rest-7.1&tabs=HTTP#work-item-policy](https://learn.microsoft.com/en-us/rest/api/azure/devops/policy/configurations/create?view=azure-devops-rest-7.1&tabs=HTTP#work-item-policy)
* GitHub enterprise accounts: https://docs.github.com/en/enterprise-cloud@latest/admin/managing-your-enterprise-account/about-enterprise-accounts
第八章：展示 ALM 和 DevOps 实现
在本章中，我们将通过一个动手练习，使用真实的例子，结合代码片段和逐步说明。 我们将使用 Power Platform 企业模板 Power Platform 企业模板 来演示 DevOps 流程的端到端场景。 该模板是 员工奖励模板，我们可以用它来表扬 他人出色的成就。 可用的解决方案 提供了一个基于模型的应用程序（Kudos 管理应用），用于管理奖励、选择退出用户并创建徽章，这些徽章可以在画布应用中使用，填写奖励内容。 这个画布应用，称为 Kudos 应用 在解决方案中，提供了一个用户界面 供组织中的用户使用。 由于 Kudos 解决方案依赖于 员工体验基础解决方案 ，我们将学习如何通过引入多个 GitHub 工作流 在发布火车中同时管理两个解决方案，并利用部署包。 我们将为此应用定义分支策略，并深入了解不同的 GitHub 工作流，以及 DevSecOps 任务来管理这些解决方案的开发。 我们将介绍待办事项管理，并使用分支策略来保护我们的主分支，避免意外更改。 我们将为 Kudos 应用创建测试，并引入 监控 到我们的应用和流程中。 最后，我们将学习 功能开关 以及如何使用它们启用或禁用 我们应用中的某些功能。
在本章中，我们将涵盖以下 主要主题：
-
练习 – 存储库管理和分支策略 对于应用程序
-
练习 – 构建 CD 流水线和一个 发布火车
-
练习 – 待办事项管理 在 GitHub 中
-
练习 – 测试解决方案
-
练习 – 监控应用程序
-
练习 – 引入 功能开关
技术要求
要深入了解 DevSecOps 方法和工具，我们需要具备以下内容：
-
Microsoft Azure 订阅：我们可以通过 https://azure.microsoft.com/en-us/free注册 Microsoft Azure 订阅。如果我们拥有 Visual Studio 订阅或是 Microsoft 认证培训师，可以通过 MSDN 订阅加入，每月获得 150 美元的信用额度。
-
Power Platform 订阅：如果我们已经拥有 Microsoft Entra ID 工作账户，可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free），或者可以加入 Microsoft 365 开发者计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。
-
GitHub 账户和公共 仓库：（https://github.com/signup）
-
GitHub 高级安全功能 对于公共 仓库免费提供： https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security#about-advanced-security-features。
-
示例和操作指南 将在本章中讨论，并位于 以下位置： https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter08。
-
Azure CLI：我们可以通过安装指南直接在机器上安装 Azure CLI（https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install），或者可以通过 Azure 门户使用 Azure Cloud Shell 获取交互式 Bash 或 PowerShell 会话。
-
GitHub Codespaces：GitHub 每月为个人提供 60 小时的计算资源，免费使用。 要创建并启动 GitHub Codespaces，只需拥有一个 GitHub 账户。
-
.devcontainer/devcontainer.json。
练习 – 应用程序的仓库管理和分支策略
在我们深入实际操作之前， 值得先了解一下 Power Platform 企业模板中的 Kudos 应用。 我们可以通过访问企业模板的官方文档 了解更多关于该解决方案的信息： https://learn.microsoft.com/en-us/power-platform/enterprise-templates/hr/employee-kudos/install-and-set-up。我们为本书提供的仓库中包含了此解决方案的源代码，包含了我们将在整个练习过程中使用的额外扩展和工作流。
在本练习中，我们 将创建一个公共的 GitHub 仓库 ，该仓库将托管本章的应用程序，并且我们将 设置我们的分支策略并创建 部署 Kudos 应用到 Power Platform 生产环境的前置条件。 我们将采取以下步骤：
| 步骤 | 描述 |
|---|---|
| 1. | 克隆示例仓库到我们自己的 GitHub 公共仓库中。 |
| 2. | 创建我们的 Power Platform 生产环境，该环境将托管 Kudos 应用以及我们将在 GitHub 工作流中使用的服务主体。 该服务主体的凭证存储在 GitHub secrets 中。 |
| 3. | 创建一个 Microsoft Entra ID 组（Azure AD 组），该组将包含可以使用 该应用程序的用户。 |
| 4. | 在生产环境中创建 Kudos 应用的连接。 |
| 5. | 创建部署设置文件，以管理 CI/CD 工作流中的连接引用，并执行Release to Production 流程，将 Kudos 应用部署到 生产环境中。 |
| 6. | 基于 GitHub flow 定义我们的分支策略。 |
| 7. | 创建我们的第一个分支保护规则，以强制对主分支的拉取请求 进行保护。 |
表 8.1 – 练习步骤
为了简化接下来的 脚本执行 和 后续步骤 及章节的操作，我们将使用 GitHub Codespaces。GitHub Codespaces 提供的计算资源 和开发容器托管在 GitHub 云端。 我们已经准备了一个包含各种工具的容器，例如 GitHub CLI、 Git CLI、 PAC CLI以及 Azure CLI，这些工具已预装在其中。 其配置文件位于以下位置： 直接位于 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/blob/main/.devcontainer/devcontainer.json。
要启动容器，我们需要在网页浏览器中导航至本书的 GitHub 仓库（https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform），然后点击 代码 按钮，再点击 在主分支上创建代码空间 按钮，如下图所示：
图 8.1 – 在 GitHub 中创建代码空间
点击按钮后， 系统会解析 devcontainer.json 文件， 该文件位于 .devcontainer 文件夹中，然后 基于该配置， 在后台创建一个新的 Docker 镜像 。 该镜像将作为容器运行，并且在新的浏览器窗口中，Visual Studio Code 将很快启动，预装了在 JSON 文件中描述的功能：
图 8.2 – 浏览器中的代码空间
在 终端 窗口（通常是 Bash，但也可以使用 PowerShell ）中，我们 将开始创建我们自己的 代码库，按步骤进行：
-
copilot suggest或copilot explain参数，用于在不切换上下文的情况下与 GitHub Copilot 进行交互。Gh copilot suggest将我们的自然语言提示转换为正确的 GitHub CLI 命令，并附带适当的参数，而gh copilot explain则用自然语言描述我们感兴趣的命令。 我们可以使用以下脚本，在我们自己的 GitHub 企业组织中创建一个名为Kudos的仓库（如果可用），或者在登录后使用我们自己的 GitHub 账户（GitHub Codespaces 默认提供有限访问 GitHub 管理端点的权限）：export GITHUB_TOKEN= gh auth login gh auth switch # move out of the book repoto "/workspaces" cd .. gh repo create Kudos --public --clone git clone https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform.git克隆后，我们可以将
Chapter08文件夹中的文件和文件夹复制到我们的Kudos文件夹中（即 git 仓库）：cp -rT ./Mastering-DevOps-on-Microsoft-Power-Platform/Chapter08/ ./Kudos然后，我们可以使用以下脚本将文件添加、提交并推送到 新仓库：
# use the credentials of gh CLI in Git commands gh auth setup-git git config --global user.email "ouremail@address.com" git config --global user.name "Our Name" git add . git commit -m "Baseline Kudos app" git branch -M main git push -u origin main这样，我们 就拥有了新 仓库中的一切，将在 我们的 动手操作练习中使用：
图 8.3 – 我们自己的仓库与 Kudos 应用程序
在我们的新仓库中， 也有一个 .devcontainer 文件夹，里面包含 GitHub Codespace 定义。 在这里，让我们在主分支上创建自己的 codespace，并再次通过 GitHub 进行身份验证，以便获得对 仓库的写权限：
export GITHUB_TOKEN=
gh auth login
gh auth switch
此外，如果 我们已经正确完成了每个准备步骤，并且现在打开 Actions 标签 ，我们应该看到可用的 GitHub 工作流，如下图所示：
图 8.4 – Kudos 应用程序的 GitHub 工作流
我们将很快使用这些工作流，将我们的 Kudos 应用程序部署到 Power Platform 生产环境中。
-
pac admin create命令，而创建服务主体时，我们应用pac admin create-service-principal命令。 所以，让我们使用交互式登录在 GitHub Codespaces 或本地创建我们的 Kudos 应用程序的生产环境：pac auth create pac admin create --name Kudos-Prod --region Europe \ --currency EUR \ gh repo create command in our GitHub codespace, the default repository is our Kudos repository. Otherwise, we can use gh repo set-default owner/repo command to set it as default. -
创建 AAD 组：如果我们使用服务主体将解决方案部署到目标环境，那么解决方案中的应用将归服务主体所有。 为了让其他人访问这些应用，我们需要 创建一个 Microsoft Entra ID 安全组 （我们在 第七章中学习了如何操作）。 我们需要被分配 组管理员 Microsoft Entra 内置角色，才能管理组的创建和成员分配。 让我们执行以下 脚本来创建 Microsoft Entra ID 组：
az login az ad group create --display-name $GROUP_NAME --mail-nickname $GROUP_NAME # get the user object id AADObjectID=$(az ad user show \ --id $userPrincipalName \ --query id \ --output tsv) # add a member to the group \.github\workflows\share-app.ps1, we can share the Kudos app with the created security group. At the time of writing, there is no PAC CLI command that can be used to share an app with Entra ID groups; that’s why we had to use Set-AdminPowerAppRoleAssignment -PrincipalType "Group" -PrincipalObjectId $GroupID -RoleName CanView -AppName $AppName -EnvironmentName $EnvironmentName cmdlet here. The security group’s object ID needs to be provided as an input parameter to the script. The GitHub workflows available in the repository also expect this AAD group ID as input. -
准备 Power Platform 生产环境：Kudos 应用程序包含四个 Power Automate 云流和 Power Apps 画布应用，这些应用使用连接引用及其对应的连接，已为 Dataverse、 Office 365 Outlook 和 Office 365 Users 连接器创建。 这些 连接引用 用于在其他环境中使连接 可调整。 这些 连接器 是连接的定义；就像 面向对象编程 （OOP）中的类一样，它们是基于 OpenAPI REST API 规范， 并在环境中实例化为 连接 （即面向对象编程中的对象）。 当我们使用解决方案创建流、应用及其他 Power Platform 资产时，每次在流或应用中启动新的连接时，都会在解决方案中自动创建一个 连接引用 。 如果我们在解决方案外工作并在 我的流下创建流，则会创建直接连接，而不是连接引用。 然而，PAC CLI 可以代表服务主体在我们的生产环境中创建 Dataverse 连接，使用以下脚本：
pac connection create [--environment] --tenant-id --name --application-id --client-secretOffice 365 Outlook 和 Office 365 用户 连接器需要服务账户 和真实用户账户，而不是服务主体，用于在 Outlook 和 Office 365 API 中进行身份验证。 我们不能将 O365 或 M365 许可证分配给服务主体。 这就是为什么我们需要在部署解决方案之前，在目标环境中创建这些 连接。 我们可以在 PowerApps 制作门户 中的 连接 面板，通过点击 + 新建连接 按钮，如下图所示：
图 8.5 – Kudos 应用的连接
创建三个 连接后，我们应该看到与图中显示相同的结果。 最后，我们需要将这些连接与服务主体和之前在 步骤 2中创建的应用用户共享，通过点击三个点并选择 共享 菜单项 在 连接：
图 8.6 – 与服务主体共享连接
让我们通过 引入部署 设置文件 来在部署中使用这些连接。
-
部署设置文件：为了在解决方案部署期间使用这些连接，我们需要使用一个所谓的 部署设置文件。该文件已经为解决方案生成，脚本如下：
pac solution create-settings --solution-zip .\mpa_Kudos_1_0_0_36.zip此命令提取
\src\mpa_Kudos\deploymentSettings.json文件，该文件位于 GitHub 仓库中：{ "EnvironmentVariables": [], "ConnectionReferences": [ { "LogicalName": "mpa_KudosDataverse", "ConnectionId": "[Dataverse]", "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps" }, { "LogicalName": "mpa_KudosO365", "ConnectionId": "[O365]", "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365users" }, { "LogicalName": "mpa_KudosOutlook", "ConnectionId": "[Outlook]", "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365" }]}缺失的
ConnectionId值会在 GitHub 工作流运行时 设置。 这些值 是我们工作流的输入参数。 要从我们的 Power Platform 环境中获取这些值，我们 需要点击 Power Apps maker portal 中的连接 Power Apps 创建者门户 并复制连接的 ID 从相应的 URL 中。 下图展示了 Dataverse 连接的连接 ID，突出显示在 URL 中：
图 8.7 – URL 中的连接 ID
第一个 GUID 在 URL 中是环境 ID，而 第二个 GUID 是连接 ID。 以下示例突出了 第二个 GUID：
https://make.powerapps.com/environments/<<Environment GUID>>/connections/shared_commondataserviceforapps/\.github\workflows\cd-to-prod.yml contains the default values of these connection IDs, which we can overwrite and commit back to the main branch. With everything in place, we can deploy the Kudos app from the main branch to our production Power Platform environment, by starting this workflow with the gathered connection IDs:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_8.jpg>
Figure 8.8 – The Release to Production workflow with parameters
To store these connection IDs, we can alternatively use **GitHub environments**. In the case of our developer branch, we will use a dedicated GitHub environment to pre-configure these values later in this chapter.
1. **Create our branch strategy**: At the beginning of our development project, we need to design which branching and merging strategy we will use. In *Chapter 5*, we learned about the **GitHub flow**, and this is what we are going to create for the Kudos application. The following figure shows our strategy and the direct mapping between Power Platform environments and Git branches:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_9.jpg>
Figure 8.9 – The branch strategy
The arrows between the Power Platform environments and Git branches represent the code and deployment flows. A production environment can handle only `dev/DEV-US_XXX_Z` branch represents a short-lived feature branch containing the implementation of a user story or a bug fix.
1. `main` in the **Branch name pattern** field, and we need to select the **Require a pull request before merging** checkbox, as shown in the following figure:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_10.jpg>
Figure 8.10 – The branch protection rule for main
At the bottom of the page, we need to click on the **Create** button. With this setting, we ensure that only pull requests are allowed to our main branch. Note that, by default, **Require approvals** is checked, which means at least someone else should review our pull requests. Since we cannot assign a pull request to ourselves, if we work alone, it is recommended to uncheck **Require approvals**. However, it is obviously not best practice to do so in a real-world project. Besides this setting, we need to define the type of merge that we want to allow developers to do. It is recommended to use **squash merging**, which combines all commits from the head branch into a single commit in the target branch. This significantly reduces the commit history, since all changes we commit in our developer branch sequentially will be combined into one commit after a successful pull request to the parent branch. We can force this type of merge by going to the **Settings** menu in GitHub and, under the **General** blade, removing every other merge type:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_11.jpg>
Figure 8.11 – Enforcing squash merging
Checking only **Allow squash merging** will force the pull requests to be squash commits. The other two options, **Allow merge commits** and **Allow rebase merging**, will copy the commit history of the child branches into the main branch, leading to large history nodes in the commit history.
If we encounter any issue in the previous steps, we can use the following settings to get verbose logging of the commands.
* `GH_DEBUG` environment variable. If its value is `1`, it provides more insights, but if we set this variable to `api`, then we will see every REST API call to the GitHub endpoints:
```
export GH_DEBUG=gh 命令执行将会在标准输出中打印详细的跟踪信息。
```
* `--debug` flag to the end of every command that we want to troubleshoot:
```
az login --debug
```
* **The PAC CLI**: At the time of writing, the PAC CLI doesn’t offer any flag or environment variable to enrich the verbose logs in the standard output. If we need to troubleshoot PAC CLI commands, we can only use the log available under the following:
```
%userprofile%\.dotnet\tools\.store\microsoft.powerapps.cli.tool\1.30.7\microsoft.powerapps.cli.tool\1.30.7\tools\net6.0\any\logs\pac-log.txt
```
Now, we are fully prepared to make some changes to the Kudos application. Let’s understand the existing GitHub workflows and their roles in the DevOps processes.
Exercise – building CD pipelines and a release train
In the GitHub repository, we will find the following prebuilt GitHub workflows to manage the life cycle of our development project, end to end:
1. `.github/workflows/setup-dev-environment.yml`, this workflow creates a developer branch with the name provided before the workflow execution (the branch name follows the naming rule, `dev/branch_name`). The pipeline spins up a Power Platform developer environment with the same name used for the branch. We need to add the work account that we use in the Power Platform tenant to create the developer environment on behalf of our account. At the end of the workflow, we can see additional steps that grant **System Administrator rights** to our work account and to the service principal that we created for the production environment earlier. Let’s execute this workflow with the following parameters:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_12.jpg>
Figure 8.12 – Workflow inputs of “Setup dev environment”
After a successful run, we will see a new Power Platform developer environment with the name `DEV-US_XXX_Z` and a branch with the name `dev/DEV-US_XXX_Z`.
1. `dev` prefix. In our case, it is `dev/DEV-US_XXX_Z`. We can create the GitHub environment by opening the `DATAVERSE_CONNECTION_ID`2. `O365_CONNECTION_ID`3. `OUTLOOK_CONNECTION_ID`
We can see how we’ve introduced the variables in the following screenshot:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_13.jpg>
Figure 8.13 – The GitHub environment with connection IDs
As a next step, we need to create these three `KudosSPN`), and copy the connection IDs from the appropriate URLs into the `deploymentSettings.json` file. Our workflow expects to find this information in the assigned GitHub environment with the matching name. Let’s execute the *Import to dev* workflow located under `github/workflows/import-to-dev.yml` from the dev branch, to import the **unmanaged solutions** to the developer environment:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_14.jpg>
Figure 8.14 – The Import to dev workflow
We need to select our recently created developer branch to use its name to find the right environment in the Power Platform tenant:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_15.jpg>
Figure 8.15 – Executing the workflow on the dev branch
When everything is set up right according to the previous steps, we will see the GitHub workflow running during the execution of the job. The `import-to-dev` job will run in the `dev/DEV-US_XXX_Z` environment, displaying the GitHub environment name in the job’s rectangular box of the workflow run (`Import to dev`), as shown in the following figure:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_16.jpg>
Figure 8.16 – The GitHub workflow import-to-dev job
After the successful run, we have only one task left, which is to turn on the **Power Automate cloud flow**, *Kudos App – Notification email*, by opening the Kudos solution and viewing the flow under the **Cloud flows** solution asset. We will not see the flows under **My flows** because these flows are intentionally not shared with us.
When we examine the YML file of the workflow in detail, we can see that this pipeline uses a `deploymentSettings.json` file with the right connection IDs. Finally, we execute the `microsoft/powerplatform-actions/import-solution@v1` action to import the unmanaged solutions with the right deployment configurations to our Power Platform environment. We also import data to the `Badge`, with the help of the `microsoft/powerplatform-actions/import-data@v1` GitHub action.
*The branch name is the glue that ties the Power Platform environment, the Git branch, and the GitHub environment together to help developers easily find their* *own environments/configurations.*
1. `\.github\workflows\commit-to-dev.yml`, this workflow has been built to easily commit the changes made in the Power Platform developer environment back to the developer branch. We can make changes by going directly to the Kudos solution in the **maker portal** and opening the canvas app, (the Kudos app) for editing. On the main screen of the application, let’s change the textbox to include the current date, as shown in the following figure:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_17.jpg>
Figure 8.17 – Editing the Kudos App in the developer environment
We need to save the app and publish the customizations before executing the *Commit to dev branch* GitHub workflow. If we want to run the app locally in this environment, we also need to share the application within the solution with our account. The *Commit to dev branch* expects no input parameter; we only need to set the branch to our developer branch. If we started the workflow directly on the main branch, it would fail because of the branch protection rules that are applied. Under the hood, this workflow exports both solutions as managed and unmanaged (`microsoft/powerplatform-actions/export-solution@v1`) and also unpacks them to the right folders in the developer branch (`microsoft/powerplatform-actions/unpack-solution@v1`). Finally, the flow commits the changes to the dev branch. As we did earlier, we use the branch name to find the **Power Platform environment URL** to export the solutions from the right Dataverse instance, with the help of the following Bash script snippet:
ref=${{ github.ref }}
branch=“${ref#refs/heads/dev/}”
echo “$branch”
工作流在 dev 分支上执行，所以我们需要从 dev 分支获取环境 URL rawOutput=$(pac admin list --name $branch | tail -n 2)
environmentURL=$(echo $rawOutput | cut -d ’ ’ -f 3) echo “Environment URL: $environmentURL”
设置 env.devEnvironmentURL
echo “devEnvironmentURL= e n v i r o n m e n t U R L " > > " environmentURL" >> " environmentURL">>"GITHUB_ENV”
In the final line, we create an environment variable with the value of the URL to use in the upcoming actions within the GitHub job. We hand over this URL to other jobs in the workflow by using the `outputs` and `needs` keywords in the YML file.
1. `dev/DEV-US_XXX_Z` branch to `main`. The pull request will compare the two branches and list every change that has been made since the creation of the developer branch. We can use **GitHub Copilot** to generate a summary of these changes by clicking the Copilot icon on the pull request page:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_18.jpg>
Figure 8.18 – A Copilot-generated pull request summary
By clicking the **Merge** button, our pull request will close and the changes will merge back to the parent branch. Usually, we delete developer branches after a successful pull request, but this time, let’s keep our dev branch to execute some additional exercises in the upcoming sections.
1. `\.github\workflows\cd-to-prod.yml`, this workflow deploys the latest version of the main branch to the production environment, as we discussed in the previous section. We can execute this workflow to deploy the latest version of the Kudos app to the production environment.
In *Chapter 6*, we learned about the `0.0.0.0.` in Azure DevOps Services during the development phase. We can apply the same concept in GitHub by introducing a reusable workflow located under `\.github\workflows\set-version-number.yml`. This workflow has two parameters; one is the source folder of our solutions, and the other is the version number to be set. The workflow checks out the repository, searches for the `Solution.xml` file under the source folder, and replaces the inline version tags with the version number, provided as an input parameter:
- shell: bash
run: |
在解决方案目录及其子目录中查找所有 Solution.xml 文件 find ${{ inputs.source_folder }} -type f -name “Solution.xml” | while read -r file; do
使用输入的版本号替换标签中的内容 sed -i 's|.*| i n p u t s . v e r s i o n n u m b e r < / V e r s i o n > ∣ g ′ " {{ inputs.version_number }}</Version>|g' " inputs.versionnumber</Version>∣g′"file"
done
The final action in the flow commits back the changes to the branch on which the workflow runs.
We need to add this reusable workflow to the *Commit to dev branch* workflow to set the version number of the solutions to `0.0.0.0`. Let’s update the workflow in the dev branch (`dev/DEV-US_XXX_Z`) with the following lines, directly adding them to the end of the workflow:
set-version-number:
needs: [ commit-to-dev-kudos ]
name: 将版本号设置为 0.0.0.0
uses: jovadker/ppdemo/.github/workflows/set-version-number.yml@main
with:
source_folder: src/
version_number: "0.0.0.0"
Let’s commit the changes locally and push them back to the remote repository. We can work in `dev/DEV-US_XXX_Z`) and create another codespace:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_19.jpg>
Figure 8.19 – A GitHub codespace on the dev branch
After launching the newly created codespace, we can add the workflow snippet (the GitHub job with the name `set-version-number`) to the end of the file, as shown in the following figure:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_20.jpg>
Figure 8.20 – The commit-to-dev.yml file in the GitHub codespace
After saving the file in the VS Code editor in the browser, we can navigate to the source control icon on the left menu and commit our changes, by providing a commit message and clicking on the **Commit** button:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_21.jpg>
Figure 8.21 – A Git commit in a GitHub codespace
After clicking on the **Commit** button, we should not forget to click on **Sync Changes** to push back the changes to the remote origin.
To test the GitHub workflow upon our changes, we can start it on the branch, `dev/DEV-US_XXX_Z`, and see how the two solutions and their `Solution.xml` files are updated. Similarly, we can introduce this job to other flows if we plan to maintain a homogenous versioning in our solutions.
Version number – 0.0.0.0
If we use the `0.0.0.0` version number, then the solutions imported to Power Platform developer environments will also have this version. This approach is ideal for multiple developers working on the same solution or project, since they will not override the versions by committing their changes back to developer branches and later, through pull requests, to the main branch.
Finally, we can leverage the releases feature of GitHub to publish our new versions. **GitHub releases** offer an easy way to package our software, along with release notes and links to binary files, for other people to use. We can manage these releases in GitHub workflows; the platform provides a special trigger that we can use to add our solutions to a release, and there are actions available in the **GitHub marketplace** to create releases within workflows. We will create our release by executing a new GitHub workflow that builds our solutions, using **MSBuild**, creates a deployment package, and publishes the generated artifacts as part of the new release version.
The Kudos application provides `MSBuild` and `dotnet` CLIs. We can create these `.cdsproj files` at any time by executing the following PAC CLI command in the `solution` folder:
pac solution init --publisher-name developer --publisher-prefix dev
This command creates a wrapper around our solution, if empty, and then it will create an empty solution under the `src` folder, into which we can copy our solution files (XML and JSON files).
In *Chapter 4*, we learned about deployment packages and the `.csproj` file under the `DeploymentPackage` folder:
pac package init --outputDirectory DeploymentPackage
cd .\DeploymentPackage pac package add-solution --path <>\mpa_EmployeeExperienceBase_managed.zip
pac package add-solution 命令将之前由 MSBuild 构建的托管解决方案作为引用添加到此 .csproj 文件中。设置部署包后，我们可以使用 dotnet publish -c Release 命令来构建部署包的发布版本。
部署包
我们在 GitHub 仓库中创建了一个文件夹结构，其中两个解决方案和 `DeploymentPackage` 文件夹位于 `src` 文件夹下。 在 `csproj` 文件中， `DeploymentPackage` 文件夹引用了两个解决方案的发布构建，分别是 Employee Experience Base 和 Kudos。
最后，我们可以通过使用 *GitHub Release* 工作流来创建我们的 GitHub 发布，该工作流位于 `/.github/workflows/create-release.yml`。该工作流的高层步骤和关键要点如下：
1. `/.github/actions/set-version-number-action/action.yml`，它设置了 Power Platform 解决方案的版本号。 正如我们之前所看到的，可重用的工作流需要作为作业运行，这意味着 GitHub 运行器将在完成可重用工作流作业并继续下一个作业后清理本地仓库。 如果我们不希望提交版本号，我们需要将所有操作都运行在同一个作业中。 这就是为什么我们创建了这个 复合操作。
1. `MSBuild` 和 `dotnet` CLI 可用于我们的构建操作。 我们使用以下命令构建解决方案：
```
proj file contains the references to the cdsproj files under the solutions folders. We generate the deployment package with the dotnet publish -c Release /p:Version=${{inputs.release_version}} command by setting the version of the package to the one provided as the workflow parameter. After having the binaries generated, we upload every build artifact to the GitHub artifact store.
```
1. `gh cli` 命令用于创建一个 GitHub 发布：
```
gh release create ${{inputs.release_version}} --title "${{inputs.release_title}}" --generate-notes ${{ env.solution_release_folder}}/*.*
```
通过使用 `generate-notes` 参数，GitHub 发布说明将自动生成。 我们还通过引用文件夹及其内容将二进制文件附加到创建的发布中， `${{` `env.solution_release_folder}}/*.*`。
现在，让我们使用默认参数执行此流程，并在完成后检查是否能在 GitHub 仓库的主页上看到 **Releases**下的一个名为 **Initial release**的发布。打开它后，我们应该能发现关于第一次发布的更多细节——例如， 附加的资产：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_22.jpg>
图 8.22 – 包含 Power Platform 包的 GitHub 发布
包部署器
该 `.pdpkg` （ `pac package deploy --package` `.\bin\Release\mpa_Kudos_DeploymentPackage.1.0.0.pdpkg.zip` 在另一个租户上进行部署。 这些包 还可以上传数据并为 解决方案准备目标环境。
通过 GitHub 发布，我们可以 将我们的开发项目结果分发给负责生产租户的 IT 运维团队，而无需直接将我们的开发租户和工作流与 生产租户连接。
如果在尝试运行 工作流时遇到问题，请考虑以下 故障排除选项：
+ **检查运行日志**：第一步是检查工作流运行的日志。 GitHub 为每个工作流步骤提供详细日志，这可以帮助我们识别错误发生的地方。
+ `ACTIONS_STEP_DEBUG` 密钥用于启用步骤调试日志，提供每个步骤的更详细输出。 步骤日志的详细输出可以帮助我们诊断问题。
+ **在本地运行工作流**：我们可以使用诸如 **act** ([https://github.com/nektos/act](https://github.com/nektos/act))等工具在本地机器上运行工作流。 这可以帮助我们在受控的环境中调试工作流。
+ `.yml` 工作流文件格式正确，且所有必需字段都已包含。 语法错误或缺失字段可能导致工作流失败。 我们需要非常小心地更改 YML 文件中的行缩进，因为仅一个额外的空格就可能导致语法错误。
+ **检查外部更改**：有时，外部依赖项或环境的变化会导致工作流失败。 我们需要确保所有外部服务和依赖项 都是正常运行的。
现在，让我们进入下一个话题，深入了解 待办事项管理。
练习 – GitHub 中的待办事项管理
在 *第一章*中，我们了解了为何跟踪我们的活动、用户故事、变更请求和 bug 修复在任何代码库中都是至关重要的。 让我们回顾一下 关键要点：
+ 我们希望在每个冲刺前规划好开发人员的工作 以便集中精力 处理最关键的 功能 **特性**, **缺陷**和 **问题**。整个 **冲刺规划过程** 基于一个健康的 **产品待办事项** ，每个开发人员 和产品负责人 都需要 维护它。
+ 健康的待办事项管理只允许计划中的源代码更改 ，以避免 **黄金镶嵌** (开发人员添加不属于活动范围的额外功能) 和 **范围蔓延** (当项目团队在不调整项目成本或时间表的情况下，处理客户请求的功能) 。
+ **待办事项管理** 提供 **向后追溯性** 以及追溯 从生产环境中运行的应用程序到生成该应用程序的源代码 的能力。 **二进制文件** 的生成。 我们可以利用这些信息进行根本原因分析，发现哪个工作项跟踪的更改导致了生产环境中的问题。
Azure DevOps 服务 和 GitHub 提供了这些需求工程 和问题管理功能，具备先进的项目管理特性，例如安排我们的活动并分配给团队成员 在冲刺中。
为了保持 GitHub 中健康的待办事项管理，我们可以 改进最小 `pull_request` 操作，目标是 main 分支并执行以下操作：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_23.jpg>
图 8.23 – 触发拉取请求的工作流，用于分支保护
我们的工作流关键部分如下所示（位于 `/.github/workflows/pr-check.yml` ）：
name: Pull request check
on:
pull_request:
types: [edited, synchronize, opened, reopened]
branches: [ "main" ] jobs:
prcheck:
runs-on: ubuntu-latest
steps:
- name: Check for comments in PR id: check-comments run: |
# every pull request is an issue as well
#- we can address them through /issues/ endpoint
comments=$(curl -s -H "Authorization: token ${{secrets.GITHUB_TOKEN}}" \
"https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments") if [ $(echo "$comments" | jq '. | length') -eq 0 ]; then
echo "There is no comment added to the PR." echo "no_comments=true" >> $GITHUB_OUTPUT else
echo "Comments are added to the PR." echo "no_comments=false" >> $GITHUB_OUTPUT fi
shell: bash
- name: Fail if no comments
run: |
if [[ "${{ steps.check-comments.outputs.no_comments }}" == "true" ]]; then
echo "No comments added to the pull request. Failing the build." exit 1
fi
shell: bash
我们使用 `curl` 通过 REST API 端点查询属于该问题的评论 （https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments ），因为每个拉取请求也被建模为一个 `no_comments`，因此。 下一步操作会使用前一步操作的输出，判断构建是否通过。 如果工作流失败，拉取请求将被阻止，无法合并。 工作流还会在开始时检查拉取请求是否添加了描述，采用相同的方法。 我们可以通过回溯写描述并添加评论来修正我们的拉取请求。 此外，我们还可以使用 GitHub Copilot 根据子分支和 父分支之间的更改生成拉取请求描述：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_24.jpg>
图 8.24 – 使用 GitHub Copilot 生成 PR 描述
我们只需要点击 Copilot 图标，然后底层的 **GPT-4 模型** 会生成拉取请求的摘要 ——在我们的案例中， **该拉取请求对** **Readme.md 文件进行了微小的更改……**。
如果我们想要在拉取请求中引入更复杂的检查，以配合待办事项管理，我们可以访问这个 `verify-linked-issue` （[https://github.com/marketplace/actions/verify-linked-issue](https://github.com/marketplace/actions/verify-linked-issue)），它会检查拉取请求是否至少关联了一个 问题。
现在我们已经建立了严格的仓库和工作管理控制，接下来我们进入下一个话题， **质量保证**。
练习 – 测试解决方案
在 *第六章*中，我们深入探讨了 **质量保证** (**QA**) 主题，并了解了 可用于端到端 UI 测试的工具和框架 ，例如 **Power Apps 测试引擎**，或开源的 Web 测试框架，如 **Selenium**、 **Playwright**、 **Appium** 或 **Cypress**。我们还得出结论，Power Automate 云流和 **桌面流** 被视为我们的业务逻辑层，我们可以通过 UI 组件进行端到端测试。 在本节中，我们将进行以下操作：
+ 在我们的 Power Platform 开发环境中，为 Kudos 应用创建一个 Power Apps 测试工作室的测试 （`DEV-US_XXX_Z`）。
+ 将其作为测试套件下载 **YAML 文件** 并提交到我们的开发 分支（记得这个分支 仍然存在）。
+ 在本地运行，借助 PAC CLI。
+ 将这一步引入到我们的 *提交到开发分支* GitHub 工作流中。
我们还有一些先决条件 用于这个测试 自动化场景：
+ 为了能够在 CI/CD 过程中执行我们的测试，我们还 需要一个没有 **多因素认证** (**MFA**) 的用户在我们的开发租户中；可以通过 *进一步阅读* 部分中的链接了解更多信息（Power Apps 测试引擎）。
+ 我们还需要在 **解决方案** 页面下共享 Kudos 应用 **Microsoft Entra** **ID 用户**。
+ 我们必须将此用户添加到开发环境（`DEV-US_XXX_Z`）中，**Power Platform 管理中心**，并且我们需要为该用户分配内置的**安全角色**，**基本用户**和自定义角色**Kudos 员工**，这样才能访问由 Kudos 解决方案创建的自定义表格，其中包含徽章以及已经共享的 Kudos。
+ 我们需要代表测试用户第一次交互式启动该应用，且不启用 MFA，授予他们对 Kudos 应用、Office 365 用户和 Office 365 Outlook 中使用的连接的访问权限。
+ 最后，我们需要与该用户共享*Kudo 应用 – 与发送者共享 Kudo*，*分配给接收者*，以及*Kudos 应用 - 通知邮件*云流程，作为*仅限运行的用户*在 PowerAutomate 云流程 UI 中。
我们可以通过使用`/test/SmokeTestSuite.yaml`文件来轻松记录我们的测试，继续进行这项练习。
一旦我们有了 YAML 文件，我们需要进行一些更改，以便能够在`0x0`中运行，像是`102x768`像素（`screenWidth` `X screenHeight`）：
testSettings:
filePath:
browserConfigurations:
- browser: Chromium
device: screenWidth: 1024screenHeight: 768 locale: en-US recordVideo: trueheadless: true enablePowerFxOverlay: false
timeout: 30000
除了这些更新之外，我们可以将`headless` 参数设置为`false`，以便在 Chromium 浏览器中进行本地测试，跟踪 UI 操作。要在本地执行此测试 YAML 文件，我们可以使用以下 Bash 脚本：
export user1Email="USEREMAIL"
export user1Password="PASSWORD"
pac test run --test-plan-file ./test/SmokeTestSuite.yaml -env 4d3c1075-FFFF-GGGG-VVVV-40c6f5edd705 --tenant 4ae51f31-XXXX-YYYY-ZZZZ-5ece14d2c081
我们需要将测试用户的电子邮件地址和密码设置为环境变量，并且还需要提供测试文件位置、环境 ID 和租户 ID。成功执行后，我们将在`TestOutput`文件夹中找到测试结果及视频录制，文件格式也将是`.webm`。
要在 GitHub 中执行此测试，我们需要 创建两个额外的 `TESTUSER` 和 `TESTUSERPSW`，并且 – 与我们在本章开始时创建的其他三个（`PPAPPID`, `PPAPPSECRET`, 和 `PPTENANTID`）类似。
我们提前创建了一个 GitHub 工作流，以便在开发分支上轻松执行我们的 `SmokeTestSuite.yaml` 文件。 此工作流位于 `/.github/workflows/run-test.yml` 并使用以下 Bash 脚本运行 测试：
- name: Run test shell: bashrun: | set -e ref=${{ github.ref }} branch="${ref#refs/heads/dev/}"
echo "$branch"
# Get the environment Id rawOutput=$(pac admin list --name $branch | tail -n 2) environmentId=$(echo $rawOutput | cut -d ' ' -f 2) export user1Email="${{secrets.TESTUSER}}" export user1Password="${{secrets.TESTUSERPSW}}" DEV-US_XXX_Z). Based on the branch name, the workflow finds our developer environment and then calls pac test run with the appropriate parameters.
To avoid feature regression and maintain the high quality of our solution, we can introduce this step in our *Commit to dev branch* GitHub workflow to fail fast and early in the development process. All we need to do is to append the entire job, called `test`, from the `/.github/workflows/run-test.yml` as the first job in the workflow, as we want to only allow new commits landing in the branch when our automated tests pass:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_25.jpg>
Figure 8.25 – The Commit to dev branch with a placeholder for “test” job
Additionally, we can introduce this quality check in our pull request triggered workflow (*Pull request check*), in the production workflow (*Release to Production*), or even in the release workflow (*GitHub Release*) based on our preferences. Some of these workflows need to be extended, for instance, to be able to spin up new Power Platform environments, deploy the release candidate, and execute the tests. Only our imagination and project costs can limit our QA investments.
Now, our application is ready to run in production. There is only one task left, which is to get real-time insights and telemetry data about our application’s runtime characteristics and behavior. Let’s discover what monitoring options we have in Power Platform.
Exercise – monitoring the applications
After publishing our application to the production environment, we want to understand how it performs, how users interact with the application, and how far the application is stable and can run without errors. As Microsoft Power Platform runs on **Microsoft Azure**, it can leverage the existing Azure **platform-as-a-service** (**PaaS**) services to provide real-time telemetry data collection and analysis for the Power Platform portfolio – Power Apps, Power Automate, Copilot Studio, Power Pages, and even Dataverse. Azure’s PaaS service is **Azure Application Insights**, which is tidily connected to **Azure Monitor** and **Azure Log Analytics workspaces**. Azure Application Insights is an **Application Performance Management** (**APM**) solution that can be used in live production monitoring scenarios. Application Insights provides application dashboards, application maps, live metrics, transaction search, availability view, failures view, performance view, monitoring alerts, workbooks, and so on. With Application Insights, we can also discover the usage patterns of our users, how people interact with the app, and how the churn rate or the conversion rate looks. It also visualizes the user journey on web applications. The Application Insights service offers machine learning-based analysis of telemetry data (called **Smart Detection**) to identify anomalies or performance degradation before outages or blackouts occur. If the built-in detection features are not enough, we can write our own queries to look for anomalies with the help of **Kusto Query Language** (**KQL**). We can introduce our custom alerting and notifications based on the query results of KQL scripts that can trigger **Azure Playbooks**, **Azure Logic Apps**, **Azure Functions**, **Azure EventHub**, and **custom Webhooks**. The custom webhooks can trigger Power Automate cloud flows to react to the anomalies and outriders in the Power Platform. Last but not least, Application Insights provides SDKs, available in JavaScript, Java, C#, Node.js, and Python, based on the **OpenTelemetry framework**.
Since Power Apps are browser-based applications and the web player that hosts the apps in the browser is based on `react-native` in the native mobile apps through **wrap functionality**, it is a very straightforward approach to embrace Application Insights’ capabilities in our low-code/no-code platform. We can add Application Insights’ endpoint directly to the canvas app – in our case, to the Kudos app. We just need to edit the app in the developer environment through the Kudos solution and select the **App** node in the tree view on the left side:
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_26.jpg>
Figure 8.26 – Application Insights in Power Apps Studio
On the right side, among the properties of **App**, we will find the **Instrumentation key** field, and here, we should provide the instrumentation key of our Application Insights instance. Let’s create an Application Insights instance in our Azure subscription:
交互式登录
az login
选择正确的订阅
az account set --subscription baa70448-593c-4dc7-8a91-c92cf7eaf66e
az group create --location westeurope --resource-group KudosApp.AI.RG workspace=$(az monitor log-analytics workspace create \
–resource-group KudosApp.AI.RG \
–workspace-name KudosWorkspace \
–location westeurope --query id --output tsv)
az monitor app-insights component create \
–app KudosAppInsights \
–location westeurope \
–workspace $workspace \
instrumentationKey 密钥。我们现在可以将该密钥添加到 Kudos 应用并试用，查看数据如何被导入到应用程序 洞察 仪表板。
Canvas 应用洞察
要查看遥测 信息，我们需要在 Power Platform 管理中心启用 Canvas 应用洞察。 转到 **设置**，它列出了所有租户设置，然后选择 **Canvas 应用洞察** 项。 在右侧的 **Canvas 应用洞察** 面板中，我们可以开启此 功能。
当然，我们不希望直接在画布应用中存储仪表密钥。 使仪表密钥与应用程序独立的最简单方法是引入一个新的环境变量，但在撰写本文时，仪表密钥属性尚不支持此方法。 我们可以做的是更新我们的部署管道，并将仪表密钥替换为正确的值，该值存储为 `json 文件` 在我们的解决方案文件夹中 – `/src/mpa_Kudos/src/CanvasApps/src/mpa_KudosApp/AppInsightsKey.json`。这个文件包含了我们可以在 GitHub 工作流中替换为正确的仪表密钥。
尽管我们的解决方案中没有自定义聊天机器人， **Microsoft Copilot Studio** 同样支持这种与 Azure 应用程序洞察的集成 。 我们可以在 **设置** 中配置 Azure 应用程序洞察实例的连接字符串 ，位于 **Copilot 详细信息** 菜单下的 **高级** 标签页，如下图所示：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_27.jpg>
图 8.27 – Microsoft Copilot Studio 中的应用程序洞察
在这里，我们需要提供 完整的连接字符串，格式如下：
InstrumentationKey=XXXXXXXX-YYYY-YYYY-YYYY-XXXXXXXXXXXX;IngestionEndpoint=https://westeurope-5.in.applicationinsights.azure.com/;LiveEndpoint=https://westeurope.livediagnostics.monitor.azure.com/;ApplicationId=TTTTTTTT-ZZZZ-ZZZZ-ZZZZ-SSSSSSSSSSSS
我们可以在 **概览** 页找到此字符串，属于我们的 Azure 应用程序 洞察实例。
对于 **Power Pages 网站**，我们需要注入跟踪用户在网站上操作的代码片段，并将遥测数据发送到 Azure 应用程序洞察终端。 我们只需获取文档中提供的客户端 JavaScript 代码片段 并将其作为内容片段添加到我们的 **Power Pages** **管理** 应用程序中：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_28.jpg>
图 8.28 – Power Pages 中的应用程序洞察
代码片段本身 可以在此链接找到： [https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript-sdk?tabs=javascriptwebsdkloaderscript](https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript-sdk?tabs=javascriptwebsdkloaderscript)，只需要更新连接字符串为 我们自己的。
除了画布应用、自定义 聊天机器人和 Power Pages 网站外，Azure Application Insights 作为通用的 APM 框架 可用于监控 **模型驱动应用**、Power Automate 云流，以及 **Dataverse 诊断和性能事件**。这可以通过使用 **将数据导出到 Application Insights** 功能实现，该功能可在 Power Platform 管理中心中使用，如果我们拥有付费/高级 Dataverse 许可证的话。 对于我们来说，这意味着我们可以创建导出包，将选定环境中的遥测数据推送到我们的 Application Insights 服务，而无需将端点或连接字符串注入到 Power Platform 资产中。 我们无需在解决方案中准备或创建任何内容；环境和此导出作业将负责遥测数据的摄取。 建议每个环境使用一个 Application Insights 实例，并且请注意，此功能仅在托管 环境中开启和支持。
遥测数据的延迟摄取
在 **服务级别协议** (**SLA**) 中规定的遥测数据流交付时间框架 从支持此功能的 Power Platform 产品到 Application Insights 的交付时间为 24 小时。
如果我们想要收集 来自这些 Power Platform 资产的实时遥测数据，我们可以创建自己的扩展，例如 以下内容：
+ 在模型驱动应用中，我们可以创建一个 **Power Platform 组件框架** (**PCF**) 控件，该控件显示在 UI 中并通过客户端 JavaScript 连接到 Application Insights 端点。
+ 通过 Power Automate 云流，我们可以使用在 Dataverse 中记录的有关开始时间、持续时间、结束时间、状态（例如失败、取消或成功）和执行操作 的信息，并借助 **Dataverse 插件**将其发送到 Application Insights 端点。 监控这些流的另一个选项是使用 Power Automate 中新内置的 **自动化中心** 面板：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_29.jpg>
图 8.29 – Power Automate 自动化中心
在这里，我们可以可视化记录在 Dataverse 中的数据，并且可以在右侧使用 Copilot 获得 故障排除的帮助。
+ 使用 Dataverse，我们可以开发一个 **自定义 Dataverse 插件** ，将这些信息发送到 Application Insights 端点，并借助 **C# SDK**。
正如我们所见，Azure Application Insights 是一个企业级的应用程序性能管理 PaaS 解决方案，我们可以轻松地将其集成到我们的 Power Platform 产品组合中。
现在，我们将深入探讨最后一个主题——功能标志的世界，以及它们能为我们的 Power Platform 解决方案带来什么。
练习 - 引入功能标志
在自定义开发项目中， **功能标志** 用于启用或禁用应用程序的功能。 敏捷团队非常受益于这一概念，因为具有重大影响和较长开发周期的功能，跨越多个冲刺，可以在完全开发之前对最终用户保持隐藏。 考虑一些功能，例如启用 Microsoft Azure 中的 Copilot 功能或在公共仓库中提供 GitHub Copilot。 这些功能在向公众发布之前，都是在功能标志下开发的。 我们也经常使用功能标志来为一组用户（例如参与 Beta 测试活动的用户）启用新功能。 上述的 Copilot 功能最初是作为专门客户的私人预览版提供的，之后进入了公共预览阶段，最终它们变得 全面可用。
特定于解决方案的 **环境变量** 在 Power Platform 中可以提供此功能标志能力，前提是我们 在新功能前使用它。 要在 Power Platform 解决方案中将环境变量用作功能标志，我们可以按照 以下步骤操作：
1. 在我们的解决方案中创建一个环境变量。 这可以通过选择 **新建** | **更多** | 解决方案中的 **环境变量** 来完成，我们正在 进行的工作。
1. 设置环境变量的数据类型，可以是 `布尔值`、 `选项集`，或 `文本`，具体取决于我们为 功能标志所需的类型。
1. 在我们的解决方案组件中使用环境变量，例如 Power Automate 流、Power Apps 画布应用或自定义连接器。 对于 Power Apps，我们可以使用 `LookUp()` PowerFX 函数来访问环境变量的值，对于 Power Automate，我们可以使用 Dataverse 的 `执行外部操作` ，并选择操作 名称 `RetrieveEnvironmentVariableSecretValue`。
1. 将我们的解决方案部署到不同的环境，并根据我们的功能标志设置更改环境变量值。 这使我们能够根据 环境设置启用或禁用某些功能或功能。
让我们为我们的 Kudos 应用解决方案引入一个功能标志 来控制登陆页面上需要显示哪个标签——是原始的标签，还是我们在 *练习——构建 CD 管道和发布列车* 一节中早些时候创建的标签：
<https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_08_30.jpg>
图 8.30 – 作为功能标志的环境变量
我们定义这个 环境变量，数据类型为 `布尔` ，并将其默认值设置为 `featureFlagLabel`。
要在画布应用中使用 PowerFX 读取环境变量的值，我们可以使用以下方法：
+ 确保我们已将 `环境变量值` 表添加到我们的画布应用的数据源中。
+ 使用 `LookUp()` 函数，结合我们环境变量的架构名称——例如， `LookUp('环境变量值', '环境变量定义'.'架构名称' = "``YourEnvironmentVariableSchemaName").Value`。
+ 这将检索我们指定的环境变量的当前值。 。
让我们打开我们的 Kudos 应用来编辑 从我们的解决方案中，然后引入新的数据源， `环境变量值`。之后，我们需要将 `文本` 属性从 `lblTitle_LandingScreen` 的静态文本更改为 以下内容：
If( IsBlank(LookUp('Environment Variable Values', 'Environment Variable Definition'.'Schema Name' = "mpa_featureFlagLabel").Value),
"Employee Kudos",
If( LookUp('Environment Variable Values', 'Environment Variable Definition'.'Schema Name' = "mpa_featureFlagLabel").Value = "no",
"Employee Kudos",
"Employee Kudos - April 2024"
)
)
正如我们在本章第一节中所学到的，部署设置文件不仅包含连接引用，还包含环境变量。 我们的 `deploymentSettings.json` 文件位于 `\src\mpa_Kudos\deploymentSettings.json`。在 `cat` 命令的帮助下，我们已经在 GitHub 工作流中更新了此文件（*发布到生产环境* 和 *导入到开发环境*），关于连接引用：
newDataverseId="${{ github.event.inputs.dataverseConnectionId }}"
newO365Id="${{ github.event.inputs.o365IdConnectionId }}"
newOutlookId="${{ github.event.inputs.outlookIdConnectionId }}"
cat ${{ env.solution_source_folder}}/${{ env.kudos_solution_name }}/deploymentSettings.json | jq --arg dataverseId "$newDataverseId" --arg o365Id "$newO365Id" --arg outlookId "$newOutlookId" '.ConnectionReferences[] |=
if .ConnectionId == "[Dataverse]" then .ConnectionId = $dataverseId
elif .ConnectionId == "[O365]" then .ConnectionId = $o365Id
elif .ConnectionId == "[Outlook]" then .ConnectionId = $outlookId
else . end' > temp.json && mv temp.json ${{ env.solution_source_folder}}/${{ env.kudos_solution_name }}/deploymentSettings.json
类似地，我们可以更新此 JSON 文件中的环境变量值，以便在部署管道中完全自动化它们。 我们只需 将 `.ConnectionReferences[]` 数组替换为 `.EnvironmentVariables[]` 数组来调整 我们的变量。
在本节中，我们学习了如何利用环境变量将功能标志添加到我们的应用程序和 云流中。
总结
在本章中，我们踏上了一段激动人心的旅程，深入探讨了 DevOps 和 ALM 原则的实际应用。 我们通过各种实践练习，掌握了从存储库分支策略到构建稳健的 CD 管道、有效管理待办事项以及强制执行分支保护规则等内容。 我们还深入探讨了解决方案的自动化测试，通过 APM 监控应用程序在运行时的性能，并利用功能标志的强大功能。 这些练习不仅仅是理论上的；我们还将其应用于一个真实世界的例子，利用 GitHub 作为我们首选的 DevOps 工具。 通过这些实践教程，我们将 DevOps 和 ALM 的每一个环节编织成了一个 [实践 经验的画卷。](https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview)
[在接下来的章节中，我们将深入探讨](https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview) 融合架构，并查看如何在我们的 Power Platform 解决方案中利用 Azure PaaS 服务。
进一步阅读
+ Power Platform 企业版 模板： [https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview](https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview)
+ Kudos 应用程序： [https://learn.microsoft.com/zh-cn/power-platform/enterprise-templates/hr/employee-kudos/install-and-set-up](https://learn.microsoft.com/zh-cn/power-platform/enterprise-templates/hr/employee-kudos/install-and-set-up)
+ GitHub CLI： [https://github.com/cli/cli](https://github.com/cli/cli)
+ GitHub CLI 与 GitHub Copilot： [https://docs.github.com/zh-cn/copilot/github-copilot-in-the-cli/using-github-copilot-in-the-cli](https://docs.github.com/zh-cn/copilot/github-copilot-in-the-cli/using-github-copilot-in-the-cli)
+ 预填充连接 引用： [https://learn.microsoft.com/zh-cn/power-platform/alm/conn-ref-env-variables-build-tools#get-the-connection-reference-information](https://learn.microsoft.com/zh-cn/power-platform/alm/conn-ref-env-variables-build-tools#get-the-connection-reference-information)
+ GitHub 环境： [https://docs.github.com/zh-cn/actions/learn-github-actions/variables#using-the-vars-context-to-access-configuration-variable-values](https://docs.github.com/zh-cn/actions/learn-github-actions/variables#using-the-vars-context-to-access-configuration-variable-values)
+ GitHub 输出： [https://docs.github.com/zh-cn/actions/using-jobs/defining-outputs-for-jobs](https://docs.github.com/zh-cn/actions/using-jobs/defining-outputs-for-jobs)
+ GitHub 作业和 需求： [https://docs.github.com/zh-cn/actions/using-jobs/using-jobs-in-a-workflow](https://docs.github.com/zh-cn/actions/using-jobs/using-jobs-in-a-workflow)
+ GitHub 复合 操作： [https://docs.github.com/zh-cn/actions/creating-actions/creating-a-composite-action](https://docs.github.com/zh-cn/actions/creating-actions/creating-a-composite-action)
+ GitHub 拉取 请求： [https://docs.github.com/zh-cn/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests](https://docs.github.com/zh-cn/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
+ GitHub 市场： [https://github.com/marketplace](https://github.com/marketplace)
+ Power Apps 测试 引擎： [https://learn.microsoft.com/zh-cn/power-apps/developer/test-engine/overview](https://learn.microsoft.com/zh-cn/power-apps/developer/test-engine/overview)
+ 使用 Power Apps 测试 工作室： [https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/working-with-test-studio](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/working-with-test-studio)
+ Azure 应用程序洞察 概述： [https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview](https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview)
+ 指标 警报： [https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/tutorial-metric-alert](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/tutorial-metric-alert)
+ 操作 组： [https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups)
+ Power Apps 与应用程序 洞察： [https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/application-insights](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/application-insights)
+ 应用程序洞察 集成概述： [https://learn.microsoft.com/en-us/power-platform/admin/overview-integration-application-insights](https://learn.microsoft.com/en-us/power-platform/admin/overview-integration-application-insights)
+ 将数据导出到应用程序 洞察： [https://learn.microsoft.com/en-us/power-platform/admin/set-up-export-application-insights](https://learn.microsoft.com/en-us/power-platform/admin/set-up-export-application-insights)
+ Power Pages 和应用程序 洞察： [https://learn.microsoft.com/en-us/power-pages/go-live/telemetry-monitoring](https://learn.microsoft.com/en-us/power-pages/go-live/telemetry-monitoring)
+ 环境 变量： [https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables)
+ Power Automate 自动化 中心： [https://learn.microsoft.com/en-us/power-automate/automation-center-overview](https://learn.microsoft.com/en-us/power-automate/automation-center-overview)
第三部分：探索 DevOps 最佳实践及未来发展
在本部分中，我们将探索构建融合团队的可能性，在这些团队中，专业开发者和 DevOps 工程师可以帮助低代码/无代码开发方法的实施。 我们将了解文化如何在更快的开发周期中发挥重要作用，以及构建可重用组件的重要性。 我们将看看 Microsoft Azure 云服务如何与 Power Platform 解决方案进行集成。 专业开发者将了解 Power Platform 的可扩展性，并能够利用自定义代码组件，扩展 Power Platform 的功能。 我们将通过研究人工智能如何改变我们开发业务应用程序的方式，来总结本章内容，探讨它如何帮助我们构建定制的副驾驶，不仅支持我们的 DevOps 流程，还能丰富我们的 业务解决方案。
本部分包括以下章节：
-
第九章， 实施融合开发方法
-
第十章， 在 Power Platform 中实现专业开发者扩展性
-
第十一章， 通过设计最佳实践管理环境生命周期
-
第十二章， 展望副驾驶、ChatOps 和 AI 驱动的应用程序
第九章：实现融合开发方法
Power Platform 采用低代码/零代码方法，允许接近业务流程的公民开发人员利用他们对业务问题的了解来设计并更快地将新应用投入使用。 然而，他们所面临的挑战可能会变得更加复杂，或是功能需求超出了他们的能力，因此需要专业开发人员支持开发过程，帮助公民开发人员避免 重复性的任务。
在本章中，我们将探讨组织如何将不同的角色联系在一起，构建有效的团队，合作解决挑战，并为组织提供数字化的业务解决方案。 我们将从聚焦融合开发方法的基本理解及团队如何通过不同角色进行表现开始。 接着，我们将介绍一些好的开源开发实践，这些实践同样适用于低代码/零代码，并深入了解 Power Platform 中一个支持这些实践的工具。
最后一部分将集中讨论 Azure 云与 Power Platform 之间的集成。 这里将重点介绍特定的 Azure 服务，如 Azure API 管理服务，它作为 Azure 与 Power Platform 之间的集成服务。 此外，还将涵盖一些在与 Power Platform 集成场景中经常使用的其他常见 Azure 服务。 最后，我们将通过构建低代码应用与 代码优先解决方案的集成示例来结束。
本章将涵盖以下主要内容： ：
-
什么是融合 开发方法？
-
Microsoft Azure 和 Power 平台的结合
-
Azure 和 Power Platform 的集成示例 场景
技术要求
本章将连接 Power Platform 解决方案与 Azure 服务。 为了跟上进度，我们建议提前准备好以下要求： ：
-
Power Platform 订阅：如果你已经拥有 Microsoft Entra ID 工作账户，可以注册 Power Platform 开发者计划（https://powerapps.microsoft.com/en-us/developerplan/）；或者，你也可以加入 Microsoft 365 开发者计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。
-
Azure 订阅：你可以按照此网站上的指导，注册一个免费的 Azure 账户： https://azure.microsoft.com/en-us/free。注册完成后，可以通过以下 网址 https://portal.azure.com/访问 Microsoft Azure 门户。
-
Visual Studio：如果你无法访问其他版本的 Visual Studio，可以使用免费的 Community Edition（https://visualstudio.microsoft.com/vs/community/）。 一些示例展示了 Power Platform 工具在 Visual Studio 中的功能，这些功能在 Visual Studio Code 中不可用。 在其他情况下，你也可以使用 Visual Studio Code (VS Code) 和 Power Platform Tools 扩展。 VS Code 可以在以下网址找到： https://code.visualstudio.com/。
-
示例 本章讨论的示例位于以下 代码库： https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter09。
什么是融合开发方法？
本节介绍不同团队成员如何通过一个名为 融合开发方法的概念进行协作，以实现项目目标。 我们将解释这是什么，以及它如何弥合公民开发者与专业开发者之间的差距。 我们还将解释 Power Platform 如何受益于来自开源开发世界的实践，最后将我们的开发环境配置为连接 Power Platform。
融合开发涉及整合不同的团队及其技能，以促进业务能力的数字化，并提供价值。 这一术语首次由 Gartner 定义，指的是一个跨学科的数字商业团队，结合了技术和业务领域的专业知识，负责交付数字产品。 Gartner 的研究表明，与传统的集中式团队相比，实施分布式融合团队可以更快地加速实现组织数字化转型的进程。 你可以在这篇文章中阅读更多关于 Gartner 研究的内容： 页面： https://www.gartner.com/en/articles/why-fusion-teams-matter。
在 Power Platform 的世界里，融合开发方法 将低代码/无代码开发方法与传统软件开发方法以及 IT 运营相结合，用于管理资源和平台。 这些多学科团队合作的目的是利用团队所掌握的知识，并通过使用低代码/无代码工具来扩展应用程序现代化或业务流程的数字化。 它帮助组织在快速变化的商业环境中实现业务转型的成功，在这个环境中，必须尽早提供市场上可用的商业解决方案，以获得 竞争优势。
我们可以将融合团队的成员分为三种不同的 角色组：
-
公民开发者：这一群体由具备商业知识、理解 商业 流程和商业挑战的人组成，他们决心将现有的业务流程数字化。 在这里，我们可以找到商业用户、业务分析师和业务工程师。 他们将使用支持低代码/无代码开发方法的工具，如 Microsoft Power Platform，以可视化的方式设计和构建项目的某些部分。 这可能包括在 Power Apps 中构建应用程序的前端原型，或在 Power Automate 中支持业务流程的工作流。
-
专业开发人员：这是一个由经验丰富的专业开发人员组成的团队 他们精通多种编程语言，能够解决复杂的应用程序开发挑战。 通过使用传统的软件开发工具，如 Visual Studio，他们将主要为低代码解决方案构建扩展。 他们的工作将侧重于开发后端 API、集成场景或由公民开发人员在其低代码/无代码项目中使用的自定义代码组件。 如果可能，建议专业开发人员也使用与公民开发人员相同的低代码开发工具，以支持开发更简单的任务 并将自定义解决方案集成到新开发的解决方案中。
-
IT 专业人士/DevOps 工程师：最后一组是 IT 专业人士，他们将负责管理资源 这些资源将会 运行新建的业务应用程序，以便以受管理和受管控的方式使用，并与组织的 IT 政策对齐。 在这一组中，我们会找到 DevOps 工程师，他们将负责管理业务解决方案的 DevOps 流程。 他们将确保项目与 DevOps 实践对齐，例如确保 CI/CD 管道正常运行，并确保业务解决方案的所有组件都 得到正确的版本控制。
下图展示了各个角色如何相互连接并协作以实现构建 业务解决方案的目标：
图 9.1 – 融合开发方法
此外，我们应该 在融合开发方法中引入另外两个人物角色，这将为 融合团队带来好处。
第一个角色是 融合团队领导。他们的职责是监督 整个项目的开发并协调团队成员，负责沟通和 项目交付。
第二个角色是 解决方案架构师 角色。 建议在项目的规划和设计阶段引入解决方案架构师，因为他们将深入研究技术细节并帮助创建解决方案的高级架构设计，关注设计模式，分享关于工具和技术选择的建议， 等等。
融合团队的规模建议与敏捷团队规模的普遍建议非常相似。 没有一种适合所有的标准；这将取决于项目的复杂性和组织的成熟度。 然而，我们应该保持融合团队的 小型 规模，以保持团队的自主性和敏捷性。 团队。
团队规模在 5 到 7 人之间被认为是合适的敏捷团队规模。 这通常与亚马逊的 “两块披萨规则” 有关，该规则表示团队应该足够小，能够被两块披萨喂饱。 小型团队有助于提高沟通和协作效率，同时保持敏捷性。 这包括迅速适应团队面临的挑战的能力，而不会引入 必要的瓶颈。
融合团队 本身可能是一个临时的， 短期团队。它的目的是解决一个特定的业务问题，一旦完成，团队解散，团队成员继续他们的正常工作例程——例如，公民开发者，可能是业务用户和业务分析师，将继续他们的工作，而软件开发人员可能会回到另一个传统的软件 开发项目。
如前所述，在某些方面，融合开发 与敏捷文化有所重叠。 融合开发方法遵循精益方法论，我们在 第一章中进行了描述。精益方法论的理念是专注于在快速迭代的开发中交付价值。 融合团队可以在冲刺中工作，以跟踪和交付工作，使用 DevOps 工具和项目规划工具，例如 Azure Boards。
Power Platform 中融合开发方法的常见示例
融合团队汇聚在一起解决业务问题。 在规划和设计阶段，这些挑战被深思熟虑，任务在利益相关者之间分配。 接下来，我们将提供几个例子，展示通过融合方法，专业开发人员和公民开发人员如何通过 技术解决方案来解决这些问题。
自定义连接器到后端 API
我们经常 在组织中看到，已经有一套系统和服务正在被旧有应用程序和业务流程所使用。 如果我们只希望现代化前端应用程序或从头开始构建一个全新的应用程序，但利用一些后端服务，我们可以在 Power Platform 中使用自定义连接器，将后端服务与 Power Platform 应用程序连接起来。 在 Power Platform 中构建自定义连接器可以帮助组织解锁对这些 API 的访问，并允许开发者在任何潜在的 新场景中重用它们。
如果我们正在构建新的 API，我们可以记住它们可能会在 Power Platform 中使用。 因此，在构建应用程序、流程和助手时，构建和使用自定义连接器是一种常见做法，尤其是在使用 Power Platform 服务时。 从角色的角度来看，举个例子，我们可能会看到专业开发人员构建新的 Web API，公民开发者在 Power Apps 应用程序中使用它们，IT 运维人员则负责管理 Power Platform 环境，构建数据丢失防护策略，并描述 所需的基础设施，使用 基础设施即代码 (IaC) 方法，这将用于配置所需的基础设施，包括 Azure API 管理，以运行支持服务。 DevOps 工程师将与专业开发人员一起，确保 CI/CD 管道已配置好，以自动化的方式构建和部署应用程序和 API。
一旦自定义连接器构建并部署到 Power Platform，我们可以在 Power Automate 中重用它，将我们旧有系统和服务的能力引入到 Power Automate 流程 所实现的业务逻辑中。
Copilot Studio 现在还提供了在自定义助手中直接使用连接器，包括自定义连接器的能力。
通过 PCF 控件扩展
有时，Power Pages 或 Power Apps 画布和 模型驱动应用中提供的控件可能不足以满足需求。 也许我们正在寻找一个图形上更丰富的组件，或者只是一个执行特定任务的自定义组件。 在这种情况下，我们可以联系专业开发人员 支持我们通过使用 Power Apps 组件框架 (PCF) 构建自定义代码组件。 PCF 组件是可重用的，并能增强 用户体验。
这是另一个很好的例子，展示了专业开发人员如何运用他们的软件开发技能。 通过使用 TypeScript 编程语言，他们开发了一个组件，市民开发人员可以将其添加到他们在 Power Apps 中构建的应用程序或在 Power Pages 中构建的网站中，以改善用户体验或实现某些额外的 业务场景。
虽然之前使用自定义连接器的示例让专业开发人员几乎可以与 Power Platform 分离，因为他们只关注 Web API 和代码组件，但专业开发人员应该了解 Power Platform，因为每种应用类型（画布应用、模型驱动应用或网站/门户）都有其独特的开发最佳实践 和限制。
在自定义助理中启用复杂技能
另一个 融合方法的例子与在 Copilot Studio 中构建自定义助理或机器人有关。 Copilot Studio 允许通过 Power Automate 流程、连接器、插件和 Copilot 框架技能扩展自定义助理的功能。 如果使用现有连接器并构建与 Copilot Studio 集成的流程是市民开发人员可以完成的事情，那么构建技能操作则需要专业开发人员的参与。 。
技能 是一个可以为另一个机器人/技能消费者执行一系列操作的机器人，通常是面向用户的机器人。 它支持多轮操作，例如进行产品订单，而与 Power Automate 流程集成的则仅支持单轮操作，例如获取 包裹的状态。
在这种情况下，专业开发人员将使用 Copilot 框架 SDK 构建一个技能，然后该技能将在自定义助理机器人中由市民开发人员使用，该机器人将在 Copilot Studio 中构建。
所有这些示例有一个共同点——可重用性。 让我们看看在 Power Platform 中构建目录如何帮助组件的可发现性和可重用性。
通过开源开发实践增强协作
组织将以快速的 速度实施 新应用、流程或聊天机器人。 Fusion 团队将在 Power Platform 中开发许多可以在其他项目中重用的组件，而不是浪费时间重新发明轮子。 我们如何消除组织中的信息孤岛，赋能任何开发者，无论是专业开发者还是公民开发者，让他们了解已经完成的工作，并允许他们在自己的项目中重用这些成果呢？ 在回答这个问题之前，让我们稍微退一步，看看传统软件 开发世界是如何解决这个问题的。
不久前，许多组织 都非常封闭，独立 进行项目工作，缺乏合作。 这导致了重复的工作和开发过程中的低效率。 团队之间相互隔离，合作和沟通非常差，甚至根本不存在。 我们有时也会遇到对新想法或做法的抵触，这些新方法可能会改变团队的运作方式。
然而，如果我们看看开源世界中的软件开发实践，我们可以看到开源软件如何可能与任何人共享，开放供使用和修改。 几乎任何人都可以审查项目，修改和重用开源软件。 这种方法的目标是构建更可靠 和更优质的代码。
这时我们需要引入 InnerSource。InnerSource 是一种开发 方法论，它将开源软件开发的优秀实践应用到一个封闭的群体——组织的员工中。 这意味着软件开发项目将成为组织的私有开源项目。 一个组织的项目。
有趣的是，这种使用 DevOps 工具（如 Azure DevOps 和 GitHub）的开发方式，可以用于任何类型的项目，甚至是软件开发之外的项目。
InnerSource 为软件开发带来了现代化的方法，帮助我们消除传统专有软件在组织中带来的挑战。 在组织中开放地合作将有助于改进创新，因为更多人可以参与项目并做出贡献。 开发人员不必总是从头开始构建项目，因为 InnerSource 有助于 发现性。也许我们的组织内已经存在可以重复使用的东西。 这将推动快速开发，降低开发成本，提高上市时间。 它将改善协作，并且最重要的是，培养开放的文化。
InnerSource Commons Foundation 每年进行的研究称为 InnerSource 状态报告 (可在 https://innersourcecommons.org/找到)，它识别了 InnerSource 的好处和阻碍。 未应用 InnerSource 实践的常见阻碍包括组织文化、独立思维以及对 InnerSource 原则的认知和熟悉度不足。 因此，确保开发人员熟悉这些实践，并在组织中推广这一策略至关重要，这将有助于我们分配资源和时间来实施和释放 InnerSource 的好处。 该组织内。
这些良好的实践也可以应用于低代码/无代码 开发方法。
融合开发团队，尤其是专业开发人员和 DevOps 工程师，使用诸如 Azure DevOps 和 GitHub 等 DevOps 工具执行许多任务，其中 InnerSource 方法是产品的核心。 Azure Boards 或 GitHub Issues 等工具使开发人员能够提出新功能的想法，报告产品中的错误，评论任务等。 拉取请求机制通过构建验证和同行审查确保最终生成物符合所有要求，从而实现更好的结果。 为了进一步支持良好的 DevOps 实践，公司可以通过产品如 Microsoft Teams 扩展其工具集，以改进融合团队的沟通和协作，并 实现 ChatOps。
DevOps 工具的服务和功能 是以帮助 组织更轻松地实现和促进 InnerSource 的方式构建的。 为了让组织了解是否朝着目标前进，他们应该实施定期评审，以了解 InnerSource 的 采用情况。
构建目录流程
在为 Power Platform 开发业务解决方案时，我们还应该考虑如何遵循 InnerSource 最佳实践，允许融合团队共享他们的工作，并允许其他团队重用组件和构建的模板。 虽然在 Azure DevOps 和 GitHub 中打开项目可以让专业开发人员了解组织中有哪些项目，但我们不能指望业务用户按照与专业开发人员相同的步骤进行操作。 还有一种方法可以将我们的工作分享给组织中的任何人。
Power Platform 中的 目录 是所有已部署到目录并需要进行目录化和重用的组件和模板的唯一真实来源。 它以模型驱动应用的形式出现在 Power Apps 中，帮助我们了解组织中已经有哪些资源可用。 Power Platform 目录不是一个版本控制系统，不能替代用于版本控制和 CI/CD 流水线的 DevOps 工具。 然而，它确实增强了 ALM/DevOps 流程，因为它支持通过 PAC CLI 命令进行自动化场景，就像我们在 第六章 中的示例所看到的那样。
组件和模板在目录中作为项目呈现。 专业开发人员和公民开发人员将使用目录了解组织中现有的项目，以及谁发布了这些项目。 它还将用于在新项目中查找和重用组件，或从现有模板开始。 另一方面，IT 运维团队将使用目录的管理功能来控制代码组件 和模板的使用。
我们建议首先在组织中安装一个目录。 然而，在某些情况下，组织需要在 Power Platform 租户中安装多个目录——例如，如果一个组织有非常敏感的项目，必须与其他项目隔离。 在这种情况下，应该安装另一个目录，以提供所需的 隔离级别。
预览功能
请注意， 截至撰写本文时， Power Platform 中的目录 是一个预览功能，因此在功能上有一些限制，例如它不能在使用客户管理密钥的环境中使用。 在预览阶段，目录可以在所有类型的环境中使用，但发布到正式版后，这将仅在 受管 环境中可用。
目录过程
Power Platform 中的目录 遵循从目录项创建到获取阶段的生命周期，新的团队将在此阶段重复使用之前开发的 目录项。
这一过程始于由专业开发人员和公民开发者组成的融合团队，创建组件并构建包含解决初始业务挑战的所有组件的目录项。 这些目录项还包括在正确配置目录项时所需的配置参数。 以确保目录项能被正确配置。
这些目录项随后将提交到目录中，以供重新使用。 一旦提交，IT 管理员和业务线审批人员将审核这些新的目录项并相应地批准它们。 并据此进行批准。
其他专业开发人员和应用程序开发者 将使用该目录查找现有的解决方案和模板。 那些看似适合他们业务问题的目录项将被重新使用。 为了完成配置，开发者必须提供所有必要的配置参数并建立所需的连接。 之后，该目录项将在他们的环境中成功配置。 现在，他们可以在自己构建的解决方案中重复使用这些组件。 他们正在构建自己的解决方案。
从目录管理员开始
在我们开始在 Power Platform 中使用目录之前 ，我们必须首先从 Microsoft AppSource 安装它。 我们应该在环境中分配一个 系统管理员 安全角色，以便能够安装目录管理器。 目录管理器将安装在一个 Dataverse 环境中，该环境的数据库版本应至少为 9.2.22122.00148。我们可以在环境设置中的 版本 卡片上查看 Dataverse 版本。 我们首先需要打开 Power Platform 管理中心 | 环境 ，然后选择该环境，并选择 版本 卡片。
我们建议为目录创建一个单独的 Power Platform 环境。 这样，任何人都可以访问该环境并查看目录项，也可以将目录中的项安装到他们的环境中。
一旦我们完成所有前提条件的检查，就可以继续进行 安装。
我们可以选择通过 PAC CLI 安装目录管理器。 为了做到这一点，我们首先连接到我们希望安装目录管理器的 Power Platform 环境。 在该环境中，我们使用 pac application list 查找我们租户中所有可用的应用。 其中之一将是 mspcat_CatalogManager 或 GUID 为 83a35943-cb41-4266-b7d2-81d60f383695。这个唯一名称或 GUID 可以用来通过 pac application install --application-name mspcat_CatalogManager安装应用到当前环境。 要将应用安装到不同的环境中，使用 --environment <ENV_ID> 并替换为适当的环境 ID 或 URL。 为了验证我们是否已在租户中安装了目录，我们可以使用 pac admin list --application 83a35943-cb41-4266-b7d2-81d60f383695，它将返回安装了目录管理器的环境信息。
如果我们想通过 UI 安装此应用程序，我们需要直接使用此链接进行安装： https://appsource.microsoft.com/product/dynamics-365/powerappssvc.catalogmanager-preview?flightCodes=dde212e5c66047c59bf2b346c419cef6。当提示我们登录 Microsoft AppSource 时，我们需要使用系统管理员帐户登录并点击 立即获取进行确认。这会将我们带到 Dynamics 365 应用 内的 Power Platform 管理中心 以完成安装过程。 最后一步，我们需要选择一个环境来安装此应用程序。 我们需要同意条款和隐私声明，然后可以点击 安装 来安装应用程序。 安装过程 大约需要几分钟时间。 。
图 9.2 – 安装目录管理器应用
安装过程会安装一个新的 Power Apps 应用程序。 安装完成后，我们需要配置目录元数据。 首先，我们需要运行目录管理器。 访问目录管理器是通过 Power Apps 完成的。 我们可以在相应环境的应用程序列表中找到此应用。 只需进入 Power Apps | 应用，将鼠标悬停在 Power Platform 目录管理器 应用名称上，点击 播放 图标运行应用程序，或者点击名称旁边的三个点，再点击 播放 以运行 应用程序。
现在我们已经启动了应用程序，可以通过打开配置组来配置元数据。 在左侧导航栏的最底部，点击 目录，这将打开一个选择区域的选项；从那里，点击 设置。这将打开配置组，我们可以在这里配置 目录， PowerApps 检查器的规则集， 静态分析策略，和 PowerApps 检查器的配置。点击 目录 将打开 目录配置，如 图 9.3所示。 在这里，我们可以更改目录名称、描述、帮助链接和图像，以帮助我们识别该目录。 在右侧的 目录配置中，我们可以启用目录、允许未管理的解决方案（未来功能计划）部署到目录，并启用在目录级别发布的目录项目的全局自动审批。 此最终设置的自动审批，如果在全局级别配置，将覆盖 发布者级别 的设置。
图 9.3 – 目录元数据和配置
要返回到主要的 目录 区域，我们可以点击左侧导航栏中的 主页 导航。 在这里，我们将看到带有操作项的单独仪表板，包含所有审批请求的 审批 部分，包含已发布目录项的 目录 部分，以及部署历史记录。 每个部分的详细信息和说明可以在 这里找到： https://learn.microsoft.com/en-us/power-platform/developer/administer-catalog。
发布新的目录项目
假设我们已经成功 构建了一个我们希望发布到目录并允许其重用的解决方案。 要将项目发布到目录，我们需要一个包含我们希望发布的项目的解决方案或包部署器包，并且还需要一个提交元数据 JSON 文件。
我们将使用 PAC CLI 来操作目录项目。 正如我们已经习惯的那样，我们将启动终端并运行 pac auth create 命令来创建一个认证配置文件（如果我们还没有的话）或重用现有的认证配置文件。 我们可以使用 pac auth list 命令检查现有的认证配置文件。 请记住，当我们需要连接到一个环境，以便在其中发布项目时，我们使用 pac auth create –-environment 或 -env 开关，并提供目录所在环境的名称或 ID。
使用 pac catalog list 将显示我们所有已发布的 目录项目。
现在，我们已经准备好将新的项目发布到目录中。 我们将使用 pac catalog create-submission 命令生成一个默认的提交元数据 JSON 文件，名为 submission.json ，该文件位于终端当前操作目录中（要更改路径，我们可以使用 --path 开关）。 我们需要编辑这个文件，为计划提交的目录项目做准备。
注意
当该预览功能接近正式发布时，这个命令也可能会发生变化。 使用 pac catalog --help 可以查看所有 可能的命令列表。
提交 元数据 JSON 文件包含我们需要更新的提交属性，以使其与我们的目录项目匹配。 使用之前的命令创建的示例文件类似于以下内容：
{
"modelVersion": "1.0.0.0",
"sourcePortal": 526430000,
"operation": "CreateOrUpdate",
"businessJustification": "Business Justification",
"publisherDetails": {
"publisherId": "742d02b8-59ad-4aa4-b95a-bd41cd0459ed",
"publisherDisplayName": "Publisher Display Name"
},
"catalogItemDefinition": {
"id": "1cd8fe87-f508-42ad-8dcd-d12dda7d8668",
"displayName": "Catalog Item Display Name",
"description": "Catalog Item Description",
"offer": {
"type": "Component_Collection",
"deploymentType": "Normal",
"engineeringName": {
...},
"supportName": {...}
},
"packageFile": {...}
}
}
从提交元数据 文件中，提交时需要的四个属性为：发布者、目录项目、工程联系人和 支持联系人。
发布者属性位于 JSON 部分中，描述为 publisherDetails。它们是一个或多个 Microsoft Entra ID 组，这将允许属于该组的用户在未来更新目录项。 当我们提到 publisher时，这可以是一个专注于特定项目的融合开发团队，或者是组织中某个特定部门的开发人员组。 我们建议提供 publisherID 和 publisherDisplayName，因为这些用于验证发布者 是否已存在。
目录项是我们计划发布的解决方案。 我们需要提供 id 和 displayName 以及 engineeringName 和 supportName，因为这些是必需的属性。 工程联系信息帮助那些希望重用该目录项的人了解如果有任何关于该项的问题，应该联系谁。 支持名称 有助于识别谁可以提供支持，如果目录项有任何技术问题。 目录项。
属性的完整描述 可以在此文档 页面中找到： https://learn.microsoft.com/en-us/power-platform/developer/submit-catalog-items。
示例 - 提交项到目录
假设我们有一个模板 应用程序，作为 Power Apps 中的画布应用程序构建。 这将代表我们模板化的画布应用程序。 除了应用程序，我们还可以将其他组件作为解决方案的一部分，例如流程、Dataverse 表格等。 所有这些内容都被打包在 一个解决方案中。
从目录过程的角度来看，在创建阶段，我们正在处理我们的解决方案。在前面的章节中，我们已经看到如何将包创建作为 ALM 过程的一部分。现在，一旦我们准备好导出的解决方案，我们可以通过运行pac catalog create-submission命令来创建提交 JSON 文件。我们需要更新提交属性，以正确反映我们的目录项目。我们将更新业务类别，提供发布者详情，并通过提供 ID、显示名称、描述、联系人以及其他必需的属性来修改目录项定义。一个示例解决方案的提交 JSON 文件示例已上传到本书 GitHub 仓库的章节文件夹中（github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter09）。
当我们准备好 JSON 文件并希望开始提交过程时，我们使用pac catalog submit --path <提交 JSON 文件位置> --solution-zip <解决方案文件位置>。
如果我们希望提交到不同环境中的目录，可以将--environment开关添加到命令中并指定环境。这将产生类似于以下内容的输出：
PS E:\PACKT\CH9> pac catalog submit -p .\claims-submission.json -sz .\Claims_managed.zip
Connected as <your_user@domain>
Connected to... <your environment name>
Creating package for catalog submit request... Tracking ID for this submission is 9dc32d51-9de4-ee11-904d-000d3a1e7712
我们可以使用pac catalog status --tracking-id <提交跟踪 ID> --type submit命令检查提交状态。如果我们是提交到不同的环境，则需要向命令中提供环境名称。type参数允许我们检查install和submit操作的状态。前面的命令将生成类似以下内容的输出，也展示了跟踪 ID 和类型的短别名使用：
PS E:\PACKT\CH9> pac catalog status -id 9dc32d51-9de4-ee11-904d-000d3a1e7712 -t submit
Connected as <your_user@domain>
Connected to... <your environment name>
Status of the Submit request: Submitted
如果状态是Failed Prevalidation，我们可以在 Catalog Manager 中查看错误的详细信息，在Failed Pre-Validation下。
现在我们看到我们的状态为 已提交，目录过程的第二阶段（提交）已完成，我们正进入下一个阶段（批准和存储）。 我们的目录项已提交等待批准。 批准状态可以在目录管理器应用程序的仪表盘部分查看，位于 批准请求状态 或 批准 | 请求。
图 9.4 – 提交的目录项的批准请求
一旦目录项获得批准，它将被存储在目录中，可以通过访问目录管理器并导航到 目录项找到它。 出版商也将显示在 目录出版商 中，工程和支持联系人将被添加到 联系人 信息 列表中。
专业开发人员将在目录项详情中找到一个便捷的属性 ，该属性提供一个 代码库 链接，您可以在目录项的 链接和法律 部分找到它。 这使我们能够告知专业开发人员源代码的位置，这仅仅是之前提到的 InnerSource 方法论的进一步完善，因为现在专业开发人员也可以审查代码并参与到 开发过程中。
示例 – 从目录安装目录项
现在我们进入目录过程的发现阶段 。 在此阶段，应用开发者或专业开发人员会审查目录，或使用 PAC CLI 通过 pac catalog list 命令列出给定目录中的任何目录项。 这将返回环境中的所有目录项。 我们还可以使用 --catalog-item-name 或 --catalog-item-id 作为附加的搜索机制，通过名称 或 ID 仅查找特定的目录项。
一旦我们审查了目录项并决定在开发环境中测试它们，我们可以使用 pac catalog install --catalog-item-id <catalog-item-id> --environment <your environment guid or absolute https URL>进行安装。这将把我们带入目录过程的最后阶段， 称为获取阶段。
请记住，如果我们计划在另一个环境中安装目录项，我们需要在该环境中安装目录管理器 。
一旦我们运行该命令，我们将获得类似 这样的输出：
PS E:\PACKT\CH9> pac catalog install -env https://<orgid>.crm.dynamics.com/ -cid 1cd8fe87-f508-51ad-8dcd-d12dda7d8668
Connected as <user@domain>
Connected to... <your environment name>
Tracking ID for this installation is 34f8e610-a7e4-ee12-904d-000d3a1d5312
要使用 UI 发现、查看和安装可用的目录项，应用程序开发者还可以前往 Power Apps 或 Power Automate 并点击 更多 | 目录 在左侧导航栏中（请注意，这项功能当前处于公开预览阶段）。 这将打开 目录 区域，在此我们可以在租户的一个或多个目录中搜索所有可用的目录项。 在这里，我们将找到所有可重复使用的已发布目录项以及关于个人活动的信息，包括获取目录项或提交新 目录项。
图 9.5 – Power Apps 中的目录区域
我们可以继续使用 获取 按钮，为我们希望在当前环境中安装的每个目录项，按照安装向导进行操作，并完成 安装过程。
现在，无论是通过 UI 还是 PAC CLI 安装的该项，我们都可以使用这个新组件。 如果该解决方案作为未管理的形式部署到开发环境，并计划进一步开发它，我们可以继续按照我们的需求进行开发，然后遵循 ALM 流程将其部署到生产环境中，带着 创建的更改。
别忘了，目录 过程是持续的，涉及到将开发和部署到目录中以便进一步重用。 作为开发人员，我们将在开发阶段花费更多时间，所以让我们来探索一些开发人员在使用 Visual Studio 时可以在 Power Platform 中使用的附加工具。
开发人员使用 Visual Studio 的附加工具
从工具的角度来看，公民开发者 专注于使用低代码/零代码 开发工具，如 Microsoft Power Platform。 尽管专业开发者在可能的情况下也应该使用与公民开发者相同的低代码/零代码工具，但集成和自定义组件则需要自定义编码，针对这些需求，IDE 如 Visual Studio 或 VS Code 将被使用。 一些开发者工具已经在前面的章节中提到并使用过，例如 Power Platform CLI 和 Power Platform Build Tools，结合 Azure DevOps 和 GitHub。 与 VS Code 的 Power Platform Tools 扩展类似，编写代码的 Visual Studio 开发者可以安装 Visual Studio 的 Power Platform Tools 扩展。
Visual Studio 的 Power Platform Tools 扩展可以在 Visual Studio Marketplace 中找到，类似于我们在 第二章 中描述的 VS Code。 作为安装的前提条件，我们需要至少拥有 Visual Studio 2019 或更高版本，并且需要 .NET Framework 4.6.2，如果我们希望构建插件或 工作流活动。
我们可以从 Visual Studio Marketplace 安装扩展（https://marketplace.visualstudio.com）或在 Visual Studio 中安装：在顶部菜单栏中，点击 Power Platform 在搜索栏中，点击 下载。当下载完成后，我们必须重启 Visual Studio，以完成计划中的扩展安装 。
图 9.6 – 为 Visual Studio 安装扩展
卸载可以像安装一样 以类似的方式进行。 进入 扩展 | 管理扩展。这时，选择 已安装 在左侧导航栏中，找到 Power Platform Tools 扩展，然后 点击 卸载。
扩展只有在我们使用 Power Platform 项目模板创建新项目或打开一个已经包含至少一个使用 Power Platform Tools 模板创建的项目时才会可见。
我们还可以在首次连接到 Dataverse 环境后显示 Power Platform Explorer 。 我们可以通过在顶部菜单栏中选择 工具 ，然后点击 连接到 Dataverse…。
图 9.7 – 从 Visual Studio 连接到 Dataverse
这将打开一个新的向导 窗口，我们将在其中使用我们的用户身份验证连接到 Dataverse 环境。 对于登录部署类型，我们选择 Office 365 ，因为这将允许我们使用 Microsoft Entra ID 作为身份验证提供者。 一旦我们通过用户身份验证，我们将被提示选择将要操作的解决方案。
如果所有步骤都成功完成，Power Platform Explorer 应出现在我们面前，并连接到所选解决方案所在的环境。 现在我们有机会探索我们的环境，并将插件添加到选定的表格中，注册 Webhooks，添加工作流活动等等。 请注意，对于开发自定义工作流活动，我们需要安装 Windows Workflow Foundation。可以通过 Visual Studio 安装程序安装，方法是选择 修改 我们用于开发的 Visual Studio 版本。 在安装程序中，打开修改安装的窗口。 在这里，我们选择 单个组件 并搜索 Windows Workflow Foundation。 我们选择它并点击 修改，这将下载并安装该功能。
图 9.8 – Power Platform Explorer
Power Platform Tools for Visual Studio 提供了一套项目模板，使我们能够使用 C# 编程语言开发前述的 Power Platform 插件、定制工作流活动、解决方案模板和用于将解决方案和自定义代码库部署到我们的 Dataverse 环境的包。
使用 Visual Studio 开发后端 API 的开发者，还可以通过 “连接服务” 扩展 Visual Studio 的功能，以便在 Power Platform 中创建自定义连接器。 为了利用此功能，我们需要至少使用 Visual Studio 2022，版本 17.7，并安装 ASP.NET 和 Web 开发工作负载。 目前，这项功能在 Visual Studio for Mac 中尚未启用。 我们的 API 应该作为 ASP.NET Core Web API 项目进行开发。
我们将在 第十章中进一步讨论自定义连接器、代码组件以及专业开发人员的扩展性。
现在我们已经准备好了所有工具，接下来可以看看 Power Platform 如何与 Azure 服务集成。
微软 Azure 和 Power Platform 携手合作
本节将重点介绍与 Power Platform 集成场景中最常用的 Azure 服务。 我们将这些服务分为按其提供的功能进行分组，并简要描述了它们。 对于每个工作负载，我们提供了如何将 Azure 服务与 Power Platform 配合使用的示例。
作为云平台，微软 Azure 使我们能够在云中运行不同的工作负载，例如将我们的应用完全托管在 Azure 中，或者将本地应用与 Azure 服务进行扩展和连接。 正如我们在前面的章节中看到的，当组织在现代化他们的应用或构建新应用时，他们总是有机会选择使用低代码/无代码开发方法来现代化现有应用或构建新应用。 然而，很多时候，场景过于复杂，需要团队作为融合团队来合作，在这个团队中，专业开发人员专注于使用 Azure 提供的服务来开发复杂的场景。 Azure 提供的服务。
微软 Azure 提供了丰富的云计算服务，可以覆盖从计算服务、网络、存储、Web 服务等多个复杂场景。 让我们来看看一些与 Power Platform 广泛集成的 Azure 服务。 我们无法涵盖所有服务，因为选择太多，因此我们建议你访问 Azure 产品 网页，进一步了解这些服务： https://azure.microsoft.com/en-us/products。
应用程序托管服务
Azure 提供了广泛的服务，可以托管应用程序。 这些服务有不同的用途，从可以运行 Spring Boot 应用程序的服务到容器托管服务，再到多用途 Web 托管服务，如 Azure App Service：
-
Azure App Service 是一项托管服务，允许 我们托管 Web 应用程序，Web API 和移动后端。 由于它是托管的 PaaS 服务，云提供商负责维护操作系统和基础设施，而我们专注于构建应用程序。 它是一个可扩展的企业级服务，允许根据负载自动缩放应用程序，同时保持高度 的安全性。
-
Azure Container Apps 是一个无服务器平台，专为运行 容器化应用程序而设计。 与 Azure Kubernetes Service (AKS)相比，后者是一个托管的 Kubernetes 集群，需要我们管理连接到 AKS 集群的节点。而 Azure Container Apps 则提供了一个完全托管的 Kubernetes 服务，可以自动扩展我们的应用工作负载，而无需管理 基础设施。
让我们来看一个 Power Platform 集成示例。 前面提到的两种服务用于运行前端应用程序或后端 API 端点。 我们可以使用它们来运行后台处理作业或构建并运行我们的 Web API。 当我们选择容器作为打包和部署选项时，还可以将我们的微服务部署到 Azure Container Apps 或类似的 Azure 容器运行服务上。 这些 API 将通过 Azure API Management 安全地公开，并作为我们 自定义连接器的后端。
集成服务
Azure 集成服务是一组 Azure 服务，允许组织构建连接不同系统和应用程序的解决方案。 它们可以用于提供高度安全的消息平台，构建 ETL 流程和执行数据转换，或通过 API 安全地公开后端系统供内部和 外部使用：
-
Azure API 管理 (Azure APIM) 使组织能够管理 API 并将它们暴露给其他应用程序， 使得这一过程既快捷又安全。 它由三个组件构成：网关、开发者门户和管理员管理面板。 后台应用程序和数据可以驻留在 Azure 或其他环境中（包括本地环境），同时为客户端提供一个前门， 该前门可以将请求路由到后台，同时保持对请求和响应流的控制。
Power Platform 集成示例：一旦我们准备好了 API，通过 Azure APIM 将它们暴露出来 使我们能够快速在 Power Platform 中创建自定义连接器。 自定义连接器将用于我们的应用程序 或流程。
-
Azure Functions 是一个事件驱动的无服务器计算平台，允许开发人员使用 事件驱动的触发器和绑定将函数连接到其他服务并执行应用程序逻辑。 由于它是一个无服务器平台，云基础设施的管理由云提供商和平台承担， 因此无需担心管理开销。 Azure Functions 通常用于需要处理数据的场景（例如响应事件、数据库更改或读取存储在 Azure Service Bus 中的请求）， 或者当从不同的 IoT 流中捕获数据并需要实时处理时。
Power Platform 集成示例：Azure Functions 用于处理存储在数据存储中的数据，包括 Dataverse。 它允许通过 REST 端点实现 Web API，执行特定的复杂逻辑。 这些 API 可以通过自定义连接器与我们的 Power Platform 解决方案连接，执行 API 操作。
-
Azure Service Bus 是一个异步消息传递云平台， 它允许我们创建可靠的消息传递解决方案。 它的设计目标是实现应用程序解耦并构建 可扩展的系统。
Power Platform 集成示例：它使我们能够在应用程序和后台服务之间启用异步通信，从而将应用程序和服务彼此解耦。 通过在 Power Platform 中使用 Service Bus 连接器，我们可以执行诸如发送或接收消息 到/从队列的操作。
-
Azure Logic Apps 是一个云平台，用于创建 和运行自动化工作流，类似于 Power Automate，但更侧重于专业开发人员和 IT 专业人士。 它具有 Power Automate 没有的一些独特功能，比如利用 Visual Studio 和 VS Code 通过扩展来开发和审查工作流 代码。
Power Platform 集成示例：它可以用于自动化与 Azure 相关的任务或更 复杂的流程，这些流程不一定与 Power Platform 解决方案相关。 我们可以构建自定义连接器，连接到 Logic Apps 工作流，并通过 Power Automate 或 Power Apps 中的自定义连接器运行该工作流。
数据分析
Azure 提供了一套数据分析 服务，帮助我们获取存储在任何地方的数据洞察，支持来自 IoT 设备的实时数据流，处理遥测数据的摄取， 等等：
-
Azure Event Hubs 为集成提供了一个共同的点 ，适用于应用程序需要响应实时事件的场景。 它允许从不同来源摄取实时事件数据。 在处理 IoT 场景或应用程序监控时，使用它非常常见。 由于 Power Platform 包含了 Azure Event Hubs 的连接器，我们可以更容易地构建集成。
Power Platform 集成示例：当 IoT 设备将数据发送到 IoT Hub 时，数据会被 Azure Functions 处理并发送到 Azure Event Hubs。 当事件在 Event Hubs 中可用时，Power Automate 流程会被触发并执行 相应的逻辑。
-
Microsoft Fabric 是一个统一的分析平台 ，连接了如 Azure Data Factory、Azure Synapse Analytics 和 Power BI 等工具。 Fabric 包括 一个多云数据湖，称为 OneLake，它位于上述 Fabric 工具下方，帮助消除数据孤岛。 OneLake 作为一个单一的存储系统，允许组织将来自不同数据源的数据结合起来，包括 Dynamics 365 数据。 一旦数据被表示在 OneLake 中，组织就可以在 Microsoft Fabric 中执行不同类型的分析。
Power Platform 集成示例：最近，Power Platform 引入了与 Microsoft Fabric 的 Dataverse 集成。 它开启了将 Dataverse 连接到 Fabric 的可能性，使用 Link to Fabric，以及一个将 Fabric 连接到 Dataverse 的场景，利用虚拟表。 Link to Fabric 允许组织将数据保留在 Dataverse 中，同时启用 Fabric 中的分析功能，以发现数据中的洞察。 这些洞察可以以虚拟表的格式返回到 Dataverse，这使得开发人员能够在业务流程中利用这些发现。 与之前数据停留在 Dataverse 中类似，在这里，数据驻留在 OneLake 中。
AI 服务
Azure AI 服务 是一组 REST API 和客户端库 SDK ，使专业开发人员能够使用预构建和可定制的 AI 模型创建智能应用，这些模型具有自然语言理解、语音能力、视觉能力等认知功能。 Azure AI 服务是如 Azure OpenAI、Azure AI 搜索、视觉、语音等服务的总称。 以及更多服务。
让我们来看一个 Power Platform 集成的示例。 尽管 Power Platform 包括 AI Builder，利用了一些预构建的模型，Azure AI 服务提供了额外的功能，例如集成语音转文本和文本转语音功能，或者利用其他 AI 模型 在我们的 业务应用中。
数据存储
Azure SQL 数据库 是一个完全托管的关系型数据库。 它是 Azure SQL 的 PaaS 部署，支持 超大规模（无限的数据库存储）和自动扩展。 由于许多组织已经在使用 SQL Server 作为他们的数据库系统，这样的选项使他们能够现代化其数据库，并消除管理 基础设施的需求。
让我们来看一个 Power Platform 集成的示例。 Power Platform 根据客户的数据需求提供支持。 这就是为什么 Power Platform 中有超过 1,000 个连接器，其中之一也是用于连接 SQL 服务器。 这使我们能够构建连接到现有 数据源的应用和流程。
Azure 提供了额外的数据库服务。根据项目的需求，我们可以使用其他关系型数据库，如 PostgreSQL、MySQL 或 MariaDB，或者非关系型数据库服务，如 Cosmos DB。对于这些数据服务中的每一项，都有一个连接器，我们可以使用它来构建我们的自动化流程或业务应用程序，利用现有的数据库。
上述服务只是 Azure 所提供的众多选项中的一小部分。在规划项目时，请咨询具有云计算知识的解决方案架构师或企业架构师，以确定哪些服务最适合计划中的项目。
Azure 和 Power Platform 集成场景示例
本节聚焦于一个实践案例，展示了融合团队如何协同工作。该案例展示了通过使用自定义连接器和 Azure 服务（如 Azure API 管理）将 Power Platform 与 Azure 连接起来。
本章中的示例聚焦于将用 C# 编程语言编写的 Web API 模板与 Power Platform 作为自定义连接器集成，使用 Visual Studio 2022。我们在上一章中已经安装了 Power Platform 工具在 Visual Studio 2022 中。本示例将展示如何通过现代工具，帮助专业开发者构建和测试支持 Power Apps 业务应用程序的 Web API。Web API 将部署到 Azure 服务并通过 Azure API 管理进行暴露。
在这里，我们将介绍两种创建自定义连接器的方法：一种是借助 Visual Studio 2022，另一种是借助 Azure API 管理。
一旦创建了自定义连接器，我们的公民开发者就可以在 Power Platform 中使用这些操作来开发他们的业务解决方案。
下一章将重点介绍 Power Platform 各个组件的 ALM 流程，因此在这里我们将展示融合开发方法的概念。
让我们先从创建 Web API 开始。
使用 Visual Studio 2022 创建 Web API 和 Power Platform 自定义连接器
我们将戴上专业开发者的 帽子，并使用 Visual Studio 2022 中的 ASP.NET Core Web API 模板创建我们的示例 API。 我们这样做是为了展示专业开发者在融合开发团队中使用 Visual Studio 开发项目时所获得的能力，该项目主要部署在 Power Platform 服务上。
当 Visual Studio 启动时，它会欢迎我们进入一个窗口，在这个窗口中，我们可以通过点击 web api来创建一个新项目，选择 C# 语言中的 ASP.NET Core Web API 模板，然后点击 Next，如以下图所示：
图 9.9 – 创建一个新的 Web API 项目
在接下来的 界面中，我们将 提供我们的 GET 操作，名为 WeatherForecast，它已经是 模板的一部分。
作为 DevOps 经验的一部分，我们的任务是对代码进行版本控制，这意味着我们要么在 Azure DevOps 或 GitHub 上创建一个新项目，要么使用现有项目来进行这一部分工作，然后将我们的代码提交到代码库，并进行首次提交。 我们在 main 分支上启用分支保护，并配置其他策略，正如我们在前面的章节中学到的那样。 此时，我们的 API 开发者可以按照 DevOps 最佳实践继续他们的工作。
回到我们的示例，我们可以测试新创建的项目，或者继续开发并删除现有的 WeatherForecast 操作，继续开发业务项目要求的 API 操作。
当我们想测试 已开发的 API 时，我们可以简单地按下 F5 键启动调试过程，或者前往顶部导航栏，展开 调试，并选择 开始调试 以在浏览器中启动我们的 API。 这将打开 Swagger UI，显示我们的 Swagger 文件，其中包含 Web API 中所有存在的操作。 Swagger 提供了一种方便的方式来设计、文档化并使用我们的 API。 它使用 OpenAPI 规范，并提供了一组开源和商业工具来处理 Swagger 文件，该文件采用 JSON 格式描述我们的 API 操作。 OpenAPI 定义在创建自定义连接器时也被 Power Platform 使用 ，并且它必须采用 OpenAPI 2.0（之前称为 Swagger）格式。
当我们准备好 API，并希望在 Power Apps 应用程序或 Power Automate 流程中测试它时，我们可以将 Power Platform 添加为连接的服务。 这样，Visual Studio 将自动为我们在 Power Platform 中创建一个自定义连接器。 为此，我们前往 Visual Studio 中的 Web API 项目。 在 解决方案资源管理器中，我们展开项目，以便看到 连接的服务 | 添加 | Microsoft Power Platform。这将打开一个新标签页，并显示在 连接的服务 部分，出现一个 连接到 Microsoft Power 平台 的窗口：
图 9.10 – 将 Power Platform 添加为连接的服务
这个新窗口包含所有用于创建新自定义连接器的参数。 在创建之前，我们需要确保已经登录。 如果没有，在右上角，我们可以登录并提供正确的用户凭据。 身份验证通过后，我们选择一个 Power Platform 环境，将自定义连接器部署到其中。 在 Power Platform 解决方案 下拉菜单中，我们选择要部署连接器的解决方案。
接下来，我们连接 到自定义 连接器。 在我们的案例中，由于我们第一次创建它，因此我们将点击 + (加号图标)来创建一个新的自定义连接器。 我们将勾选 自动生成 OpenAPI V2 规范 ，以便 Visual Studio 为我们生成 OpenAPI 定义。 最后，我们将通过点击 + （加号图标）创建一个 公共开发隧道 ，点击 选择公共开发隧道，该隧道将用于在自定义连接器与我们实例中的 Visual Studio 之间进行调试。
开发隧道
Visual Studio 中的开发隧道提供了一种快速、安全的方式来测试互联网中的 Web API。 在我们的案例中，Power Platform 服务将创建一个连接，连接我们本地运行 Visual Studio 的机器和一个使用自定义连接器的 Power Platform 服务（即使用自定义连接器的 Power Apps 应用程序）。 这种方法旨在为开发和测试目的创建临时连接，不适用于 生产工作负载。
以下截图展示了 我们如何在连接到 Microsoft Power Platform 后创建一个公共开发隧道。 当我们点击 下一步时，我们会看到 更改摘要 页面，通知我们将在 Microsoft Power Platform 中创建一个自定义连接器。 我们通过点击 完成来确认这一操作。该过程将构建我们的项目，配置开发隧道，生成 Swagger JSON 文件（OpenAPI 规范文件），并在我们选择的 Power Platform 环境中创建一个自定义连接器：
图 9.11 – 创建自定义连接器
现在开发隧道和自定义连接器已创建，如果我们现在运行我们的 API（通过按下 F5 或点击 调试 | 开始调试），我们将看到 Visual Studio 使用 开发隧道 功能，并将我们的 Web API 暴露到公共端点，通知也会在 Web 浏览器中弹出，告知我们这一点。 确认后，开发隧道建立成功，我们可以在 Power Platform 中使用这个自定义连接器，它现在已连接到我们的 Visual Studio 开发环境。 这是调试我们的 Web API 和自定义连接器的非常便捷的方法。 我们现在可以在任何 Power Apps 应用程序或其他 Power Platform 服务中使用这个自定义连接器，并在 Visual Studio 中的 Web API 源代码中设置断点进行调试。 一旦 API 操作被执行，我们就能在 Visual Studio 中看到调试引擎已触发我们设置的断点。 这将帮助我们继续进行 调试/测试过程。
作为一名公民开发者 或应用程序开发者，我们现在可以 在 Power Apps 中看到新创建的自定义连接器。 导航到 Power Automate 或 Power Apps。可以点击左侧导航栏中的解决方案 ，并打开用于从 Visual Studio 部署自定义连接器的解决方案，或者进入 自定义连接器 并找到我们的自定义连接器，然后点击 编辑 (铅笔图标)：
图 9.12 – 打开自定义连接器定义
我们可以看到 API 操作定义中的主机和 URL 正指向 开发隧道（dev tunnel）。
我们可以在 Power Platform 中创建 Power Apps 应用程序、流或其他任何内容，并利用自定义连接器。 只要 Visual Studio 中的开发隧道连接处于活动状态，我们的自定义连接器就能够获取我们将要调用的 API 操作的结果。 使用 pac connector list 命令，我们将能够看到所有在 Dataverse 中注册的自定义连接器及其显示名称和 ID。 例如，我们可以使用关于连接器的信息，从 PAC CLI 创建一个示例画布应用。 该应用 是基于 来自自定义连接器的 OpenAI 定义生成的： 自定义连接器示例：
pac canvas create --msapp <new-msapp-file> --connector-id <connector-id>
使用 Azure APIM 创建 Power Platform 自定义连接器
让我们继续举例。 假设 我们的专业开发人员 正在推进他们的新 Web API。 他们正在使用 DevOps 原则来构建、测试并将 Web API 部署到测试环境中。 测试环境不同于本地开发机器，因为此环境现在已在 Azure 中进行配置。 为了托管我们的 Web API，我们可以选择 Azure 中提供的众多应用托管服务。 我们将使用 Azure 应用服务，这是一个能够托管 Web API 的 PaaS 服务。
与 DevOps 最佳实践一样，我们遵循 IaC 方法，并在 Bicep 或 ARM 模板文件中描述环境。 此 IaC 定义文件也在我们的 Azure DevOps/GitHub 仓库中进行版本控制，因此我们可以跟踪更改并对模板文件执行验证检查。 模板文件。
CI/CD 流水线确保我们的 Web API 作为构件是可部署的，并且我们将其自动部署到新配置的测试环境中。 一旦我们的 API 部署到托管平台，我们就准备好将 Web API 连接到 Azure API 管理。
Azure 服务，如 Logic Apps、App Service、Functions 和 Container Apps，提供了 Web API 与 Azure APIM 之间的无缝集成，用于在 APIM 中注册 API。 然而，Azure APIM 也提供了通过提供定义文件（如 OpenAPI、WSDL、OData 和 WADL）来添加 API 的选项。 当然，我们也可以完全从头开始，手动添加 API 的所有属性和操作。 API。
图 9.13 – 在 APIM 中创建新 API
APIM 提供了一种便捷的 配置 模拟响应的方式。这有助于加快开发进度，因为专业开发人员 可以将所有操作添加到 Azure APIM 中并模拟响应，而 Power Platform 中的应用开发人员则使用这样的 API 并在 Power Platform 中构建其余服务。 例如，公民开发人员使用已包含所有操作的自定义连接器，但响应是由 APIM 模拟的。 一旦后端 Web API 开发完成并准备好使用，专业开发人员会禁用操作上的模拟响应，将逻辑交由 Web API 执行并返回正确的响应。 另一方面，由公民开发人员开发的前端并不会看到任何差异——只有从 API 返回的数据 有所不同。
一旦我们的 API 准备好被使用，我们可以直接在 Power Platform 中从 Azure APIM 创建一个连接器：
图 9.14 – 从 Azure APIM 创建自定义连接器
当我们点击 创建连接器 按钮时，接下来的步骤要求我们提供 API 名称，该名称将用于 自定义 连接器。 我们需要选择我们正在使用的那个。 接下来，我们需要提供 Power Platform 环境和 API 显示名称，因为这将代表将部署到所选环境的自定义连接器。 一旦我们提供了这些信息，就可以通过点击 创建 按钮继续。 之后，一个新的自定义连接器将在选定的 Power Platform 环境中出现，并将准备好供任何 Power Platform 中的应用开发人员使用。
将 ALM 应用于自定义连接器
前面的示例 展示了如何通过 Visual Studio 或 Azure APIM 创建自定义连接器。 然而，如果我们希望使用 CI/CD 流水线将我们的自定义连接器部署到不同的环境，了解如何采用代码优先的方法来操作自定义连接器，并将其部署到不同的目标环境是很有帮助的。 我们将使用 Power Platform CLI 命令来实现 这些目的。
为了使用 PAC CLI 创建自定义连接器，我们需要获取 API 定义文件并生成支持的属性文件。 API 定义文件是一个 OpenAPI 2.0（Swagger）定义文件，描述了 API 及其操作。 我们可以从头开始创建 Swagger 定义文件，或者从我们在 前一个练习中创建的自定义连接器中获取它。
与 API 定义文件一起，我们还需要 API 属性文件。 API 属性文件是一个 JSON 文件，包含我们连接器的支持信息，如认证信息、品牌颜色、发布者信息等。 等等。
可选地，我们可以使用附加文件，如图标文件、脚本文件（CSX 文件）和 设置文件。
我们可以使用 pac connector init 命令从头开始创建一个自定义连接器，并附加其他参数来生成自定义连接器所需的附加文件。 接下来，我们可以看到一个示例，生成一个带有 API 密钥的 API 属性文件，用于验证针对自定义连接器的请求。 它还会生成设置文件、属性文件和脚本文件，所有这些都位于一个单独的 DemoBankAPI 文件夹中：
pac connector init --connection-template "ApiKey" --generate-script-file --generate-settings-file --outputDirectory "DemoBankAPI"
如果我们想从之前创建的自定义连接器生成 API 定义文件，可以使用 pac connector list 命令获取当前环境中所有连接器的列表及其连接器 ID。
找到自定义连接器的连接器 ID 信息后，我们可以使用 pac connector download --connector-id <CONNECTOR-ID> 下载 apiDefinition.json 和 apiProperties.json 以供所选 自定义连接器使用。
此时，我们应该已经将文件提交到仓库，以便任何修改都能进行版本控制。 我们将对文件进行更改，以使其反映目标环境的正确值。 这意味着更改 host 值，该值是我们自定义连接器指向的端点，以及任何其他 属性值。
当我们想要在目标 环境中创建自定义连接器时，可以使用简单的 pac connector create --settings-file .\settings.json 命令，因为设置文件中已包含有关所有支持文件的信息，以及部署到目标环境的环境值。 接下来，我们可以看到一个示例 settings.json 文件：
{
"connectorId": null,
"environment": "1f9283b6-deea-eed7-899c-4da273a3f957",
"apiProperties": "apiProperties.json",
"apiDefinition": "apiDefinition.json",
"icon": null,
"script": "script.csx"
}
在 settings.json 以及任何支持文件（如用于身份验证的 API 属性文件）中的值，应该进行更改和参数化，以确保文件中不会硬编码值，而是只使用变量名，这些变量在 CI/CD 流水线 中根据实际值进行更改。
另一种使用手动定义值的 create 命令变体如下：
pac connector create --environment 1f9283b6-deea-eed7-899c-4da273a3f957 --api-definition-file .\apiDefinition.json --api-properties-file .\apiProperties.json
当我们需要更新目标环境中的自定义连接器时，我们应该使用 pac connector update --``settings-file .\settings.json。
一旦我们在目标环境中创建了自定义连接器，就可以使用它来测试现有应用程序中的操作，或者使用 pac canvas create --msapp <new-msapp-file> --connector-id <connector-id>创建一个新的虚拟应用程序。我们现在准备好 测试我们新部署的 连接器。
总结
本章介绍了采用协作、敏捷和创新方法的重要方面。 组织应该认识到，融合团队可以缩短解决业务挑战的时间，因为这些团队打破了商业用户、专业开发人员和 IT 专业人员之间的传统障碍，通过敏捷的方法 和协同效应。
组织还应该采纳来自开源开发的最佳实践，这些实践增强了组织内部应用开发者的可能性，因为我们赋予开发者发现和重用已有成果的能力。 与传统软件开发工具类似，Power Platform 提供了支持这一体验的所有工具，如目录管理器和与 Azure 的集成。
对于已经在 Azure 上注册并在该公共云上运行业务工作负载的组织来说，Azure 集成更加重要。 考虑到集成，我们调查了 Power Platform 如何与 Azure 服务进行连接的一些常见案例。
我们通过一个专业开发人员在构建 Web API 的示例结束了本章，Web API 将作为 Power Platform 服务的后端使用，并且展示了 Visual Studio 如何促进更快的开发和高效的测试体验。 当 Web API 准备就绪时，我们展示了 Azure APIM 与 Power Platform 服务之间的集成是多么快速和顺畅 。
下一章将聚焦于 Power Platform 中的专业开发人员扩展性。 我们将继续探索专业开发人员在连接器、代码组件等方面的可能性，并通过可在 DevOps 流程中重用的示例。
进一步阅读
-
InnerSource 基础知识： https://resources.github.com/innersource/fundamentals/
-
在 Microsoft Fabric 中查看 Dataverse 数据： https://learn.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-view-in-fabric
-
Azure 和 Power Platform 架构 示例： https://learn.microsoft.com/en-us/azure/architecture/browse/?products=power-platform
-
Visual Studio 中的开发隧道： https://learn.microsoft.com/en-us/connectors/custom-connectors/port-tunneling
-
从 Azure APIM 导出 API 到 Power Platform： https://learn.microsoft.com/en-us/azure/api-management/export-api-power-platform
-
与 PAC 的自定义连接器 CLI: https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/connector
扫一扫
798
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
