代码组件应用程序生命周期管理 （ALM）

ALM 是一个术语，用于描述软件应用程序的生命周期管理，其中包括开发、维护和治理。 详细信息：具有Microsoft Power Platform的应用程序生命周期管理（ALM）。

本文介绍从 Microsoft Dataverse 中的代码组件的角度使用生命周期管理的特定方面的注意事项和策略：

1. 开发和调试 ALM 注意事项
2. 代码组件解决方案策略
3. 版本控制和部署更新
4. 画布应用 ALM 注意事项

开发和调试 ALM 注意事项

开发代码组件时，需执行以下步骤：

1. 使用 pac pcf init 从模板创建代码组件项目（pcfproj）。 详细信息： 创建和生成代码组件。
2. 实现代码组件逻辑。 详细信息： 组件实现。
3. 使用本地测试工具调试代码组件。 详细信息： 调试代码组件。
4. 创建解决方案项目（cdsproj）并将代码组件项目添加为引用。 详细信息： 打包代码组件。
5. 在 发布 模式下生成代码组件，以便分发和部署。

当代码组件准备好在模型驱动应用、画布应用或门户内进行测试时，可通过两种方法将代码组件部署到 Dataverse：

1. pac pcf push：此命令每次将单个代码组件部署到由 --solution-unique-name 参数指定的解决方案中；如果未指定解决方案，则部署到临时的 PowerAppsTools 解决方案中。

2. 使用 pac solution init 和 msbuild 构建一个 cdsproj 解决方案项目，该项目引用了一个或多个代码组件。 使用 pac solution add-reference 将每个代码组件添加到 cdsproj 中。 解决方案项目可以包含对多个代码组件的引用，而代码组件项目只能包含单个代码组件。

   下图显示了 cdsproj 项目与 pcfproj 项目之间的一对多关系：

   

详细信息： 打包代码组件。

构建 pcfproj 代码组件项目

构建 pcfproj 项目时，生成的 JavaScript 取决于所使用的构建命令以及 pcfproj 文件中的 PcfBuildMode。

通常不要将以开发模式构建的代码组件部署到 Microsoft Dataverse 中。 组件通常太大而无法导入，可能会导致运行时性能降低。 有关详细信息，请参阅部署到Microsoft Dataverse后调试代码组件。

要使 pac pcf push 生成发布构建，需在 pcfproj 文件中通过在 OutputPath 元素下添加新元素来设置 PcfBuildMode，具体如下：

<PropertyGroup>
   <Name>my-control</Name>
   <ProjectGuid>6aaf0d27-ec8b-471e-9ed4-7b3bbc35bbab</ProjectGuid>
   <OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>
   <PcfBuildMode>production</PcfBuildMode>
</PropertyGroup>

下表显示了哪些命令会生成开发版本还是发布版本：

在 上使用的构建命令	开发构建 （仅调试目的）	发布构建
npm start watch	始终
pac pcf push	默认行为，或在 pcfproj 文件中将 PcfBuildMode 设置为 development 时	在 pcfproj 文件中，PcfBuildMode 被设置为生产
npm run build	默认行为	npm run build -- --buildMode production

详细信息： 打包代码组件。

构建 .cdsproj 解决方案项目

构建解决方案项目 (.cdsproj) 时，您可以选择将输出生成为主管或非主管解决方案。 托管解决方案用于部署到该解决方案的开发环境之外的任何环境。 这包括测试、UAT、SIT 和生产环境。 更多信息：托管和非托管解决方案。

SolutionPackagerType 包含在由 pac solution init 生成的 .cdsproj 文件中，但初始状态下被注释掉了。取消该部分的注释，并将其设置为托管、非托管或两者。

 <!-- Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both) -->
 <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
 </PropertyGroup>

下表展示了哪些命令和配置会生成开发构建或发布构建：

在 上使用的构建命令	SolutionPackageType	输出
msbuild	Managed	在托管解决方案中进行开发构建
msbuild /p:configuration=Release	Managed	在托管解决方案中进行发布构建
msbuild	非 托管	在非托管解决方案中进行开发构建
msbuild /p:configuration=Release	非 托管	在非托管解决方案中进行发布构建

详细信息： 打包代码组件。

使用代码组件进行源代码管理

开发代码组件时，建议使用源代码控制提供程序，例如Azure DevOps或GitHub。 使用 git 源代码管理提交更改时，pac pcf init 模板提供的 .gitignore 文件将确保某些文件不会被添加到源代码管理中，因为这些文件要么由 npm 还原，要么是在构建过程中生成的：

# dependencies
/node_modules

# generated directory
**/generated

# output directory
/out

# msbuild output directories
/bin
/obj

/out由于排除了该文件夹，生成的bundle.js文件（和相关资源）将不会添加到源代码管理中。 当手动构建代码组件，或将其作为自动化构建流水线的一部分进行构建时，bundle.js 会使用最新的代码进行构建，以确保包含所有更改。

此外，生成解决方案时，任何关联解决方案 zip 文件都不会提交到源代码管理。 相反，输出将作为二进制发布工件发布。

将 SolutionPackager 与代码组件配合使用

除了对 pcfproj 和 cdsproj 进行源代码管理之外，SolutionPackager 还可用于以增量方式将解决方案解包为各个组成部分，形成一系列可提交到源代码管理中的 XML 文件。 这样做的好处是，可以以人类可读的格式呈现元数据的完整全貌，从而能够使用 拉取请求 或类似方式来跟踪变更。 每次对环境的解决方案元数据进行更改时，解决方案打包器都用于解压缩，并且可以将更改视为更改集。

注释

目前，SolutionPackager 与使用 pac solution clone 不同之处在于，它可用于以增量方式从 Dataverse 解决方案中导出更改。

如果要将代码组件与其他解决方案元素（如表、模型驱动应用和画布应用）组合在一起，则通常不需要 cdsproj 项目生成。 相反，在重新打包解决方案包以便导入之前，应先将构建产物从 pcfproj 移动到解决方案包文件夹中。

使用 SolutionPackager /action: Extract 解包包含代码组件的解决方案后，其内容将类似于以下所示：

.
├── Controls
│   └── prefix_namespace.ControlName
│       ├── bundle.js *
│       └── css
│          └── ControlName.css *
│       ├── ControlManifest.xml *
│       └── ControlManifest.xml.data.xml
├── Entities
│   └── Contact
│       ├── FormXml
│       │   └── main
│       │       └── {3d60f361-84c5-eb11-bacc-000d3a9d0f1d}.xml
│       ├── Entity.xml
│       └── RibbonDiff.xml
└── Other
    ├── Customizations.xml
    └── Solution.xml

在 Controls 文件夹下，可以看到解决方案中包含的每个代码组件的子文件夹。 其他文件夹包含添加到解决方案的其他解决方案组件。

将此文件夹结构提交到源代码控制时，应排除上面标有星号 (*) 的文件，因为在为相应组件构建 pcfproj 项目时，这些文件会被输出。

唯一必需的文件是 *.data.xml 文件，因为它们包含描述打包过程所需的资源的元数据。 生成每个代码组件后，文件夹中的文件 out 将复制到 SolutionPackager 文件夹中的相应控制文件夹中。 添加构建输出后，包文件夹将包含使用 SolutionPackager /action: Pack 重新打包为 Dataverse 解决方案所需的所有数据。

详细信息： SolutionPackager 命令行参数。

代码组件解决方案策略

代码组件使用 Dataverse 解决方案部署到下游环境。 部署到开发环境后，可以像部署其他解决方案组件一样部署它们。 详细信息： 解决方案概念 - Power Platform。

在解决方案中部署代码组件有两种策略：

1. 分段解决方案 - 使用 pac 解决方案 init 创建解决方案项目，然后使用 pac 解决方案加载项引用 添加一个或多个代码组件。 然后，可以将此解决方案导出并导入到下游环境，而其他分段解决方案将依赖于代码组件解决方案，以便必须先将其部署到该环境中。 这称为解决方案分段，因为整体功能在不同的解决方案段和层之间拆分，解决方案框架正在跟踪相互依赖性。 如果使用此方法，则可能需要多个开发环境-每个分段解决方案都有一个。 详细信息：在Power Apps中使用分段解决方案。

2. 单个解决方案 - 在 Dataverse 环境中创建单个解决方案，然后将代码组件与其他解决方案组件（例如表、模型驱动应用或画布应用）一起添加，进而引用这些代码组件。 此解决方案可以导出并导入下游环境，而无需任何解决方案间依赖项。 采用这种方法时，代码与环境的分支管理就变得非常重要，这样你就可以将更新部署到解决方案的某一部分，而不必一并纳入其他部分正在进行的更改。 详细信息：使用 Microsoft Power Platform 的分支与合并策略。

采用分段式解决方案方法而非混合式单一解决方案方法的原因可能包括：

1. 版本控制生命周期 - 你想要在单独的生命周期中开发、部署和版本控制代码组件，并将其部署到解决方案的其他部分。 这是一种常见方案，在此方案中，你有一个“融合团队”，开发人员生成的代码组件正由应用创建者使用。 通常，这也意味着代码组件将存在于与其他解决方案组件不同的代码存储库中。

2. 共享使用 - 你想要在多个环境之间共享代码组件，因此不希望将代码组件与任何其他解决方案组件耦合。 如果你是 ISV 或开发代码组件，供组织的不同部分使用，而每个部件都有其自己的环境，则这可能是这样。

下图显示了这两种方法的解决方案生命周期概述：

此图描述了以下几点：

1. 使用 PAC CLI 进行推送 - 当代码组件在 Dataverse 中准备就绪可进行测试时，使用 pac pcf push 将其部署到开发环境。 这会创建一个名为 PowerAppsTools_namespace 的非托管解决方案，其中 namespace 是要在其下部署代码组件的解决方案发布者的命名空间前缀。 解决方案提供程序应已存在于目标环境中，必须具有与要用于下游环境相同的命名空间前缀。部署后，可以将代码组件添加到模型驱动或画布应用进行测试。

   注释

   如上所述，将代码组件 cdsproj 配置为用于生产构建非常重要，这样您部署的就是针对生产环境而非开发环境优化的代码。

2. 添加现有代码组件（在 PAC CLI 部署后） - 如果使用单个解决方案方法，部署后，可以将代码组件添加到另一个解决方案。 （该解决方案必须使用与 PowerAppsTools 解决方案相同的解决方案发布者。）

   

3. 生成非托管解决方案项目 - 如果使用解决方案 cdsproj 项目，则可以使用 msbuild非托管解决方案生成，然后将其导入开发环境。

4. 添加现有代码组件（在解决方案项目部署之后） - 与执行 pac pcf push 后的情况大致相同，只要使用的是相同的解决方案发布者前缀，从解决方案项目生成结果中导入的代码组件就可以添加到混合解决方案中。

5. 将单个解决方案导出为托管解决方案 - 然后可将该单个混合组件解决方案导出为托管解决方案，并将其导入到下游环境中。 由于代码组件和其他解决方案组件部署在同一解决方案中，因此它们都共享相同的解决方案和版本控制策略。

6. 将代码组件分段式解决方案导出为托管型 - 如果你使用的是分段式解决方案方法，则可以将代码组件解决方案项目以托管型方式导出到下游环境。

7. 将代码组件分段解决方案构建为托管解决方案 - 如果使用的是分段解决方案，并且不需要非托管解决方案，则可以直接使用托管解决方案 msbuild /p:configuration=Release 生成解决方案项目。 随后可将其导入到需要依赖其代码组件的环境中。

8. 使用分段代码组件解决方案 - 通过托管分段解决方案部署代码组件后，可以生成其他解决方案，依赖于代码组件解决方案。 对代码组件的依赖项将列在解决方案中类型为 66 的 MissingDependencies 部分。 详细信息： 解决方案组件的依赖项跟踪。

9. 在使用该解决方案的解决方案之前部署代码组件分段解决方案 - 导入依赖于分段代码组件解决方案的解决方案时，必须先在目标环境中安装代码组件解决方案，然后才能导入它。

详细信息： 使用解决方案打包和分发扩展。

代码组件和自动生成管道

除了手动生成和部署代码组件解决方案之外，还可以使用自动化生成管道生成和打包代码组件。

• 如果你正在使用Azure DevOps，则可以使用Microsoft Power Platform Build Tool for Azure DevOps。
• 如果使用GitHub，可以使用 Power Platform GitHub Actions。

使用自动化构建管道的一些优势包括：

• 它们更节省时间 - 消除手动操作后，构建和打包组件会更快，因此可以更频繁地执行，例如在每次签入更改时。
• 它们是可重复的 - 一旦生成过程自动化，每次都会执行相同的过程，因此不依赖于执行生成的团队的成员。
• 它们可确保版本编号的一致性 - 当构建管道自动设置代码组件和解决方案的版本号时，您就可以确信，每次创建新构建时，其版本编号都会相对于之前的版本保持一致。 这有助于跟踪功能、bug 修复和部署。
• 它们易于维护 - 由于构建你的解决方案所需的一切都包含在源代码控制中，因此你始终可以通过检出代码来创建新的分支和开发环境。 当准备部署更新时，可以将拉取请求合并到下游分支中。 详细信息：Microsoft Power Platform 的分支和合并策略。

如上所述，代码组件的解决方案管理有两种方法：一种是采用分段的解决方案项目，另一种是采用单个混合解决方案，其中包含其他项目，例如模型驱动应用、画布应用以及已向其中添加代码组件的表。

如果您使用分段代码组件解决方案项目，则可以在 Azure DevOps Pipeline 中构建该项目（使用 Microsoft Power Platform Build Tools），或者在 GitHub Pipeline 中构建该项目（使用 适用于 Microsoft Power Platform 的 GitHub Actions）。 将每个代码组件pcfproj文件夹添加到源代码管理（不包括generatedout和node_modules文件夹），将创建一个项目cdsproj，并且每个代码组件在添加到源代码管理之前使用 pac 解决方案加载项引用进行引用。 然后，管道将执行以下操作：

1. 更新 Solution.xml 文件中的解决方案版本，使其与您的构建版本一致。 解决方案版本保存在属性中 ImportExportXml/Version 。 有关版本控制策略的详细信息，请参阅下文。
2. 在 ControlManifest.Input.xml 文件中更新代码组件版本。 版本存储在属性中manifestversion/control/。 对于所有已构建的 pcfproj 项目，都应执行此操作。
3. 运行带有参数*.cdsproj的MSBuild任务，并使用通配符/restore /p:configuration=Release。 这将生成所有 cdsproj 项目及其引用的 pcfproj 项目。
4. 将构建好的解决方案 ZIP 文件收集到管道发布工件中。 此解决方案将包含在 cdsproj 中作为引用包含的所有代码组件。

如果使用的是包含其他组件的混合解决方案（除了代码组件），则会使用 SolutionPackager 将其提取到源代码管理中，如前所述。 然后，管道将执行以下操作：

1. 按照上述步骤 1 和步骤 2 中所述的方式更新解决方案和代码组件版本。
2. 使用PowerPlatformToolInstaller任务将Microsoft Power Platform生成工具安装到生成管道中。
3. 使用 Npm 任务并执行 ci 命令来还原 node_modules。
4. 使用 Npm 任务并设置 customCommand 参数为 run build -- --buildMode release，以生产发布模式构建代码组件。
5. 将生成的输出复制到相应控件的解决方案打包器文件夹中。
6. 使用 Power Platform 生成工具 PowerPlatformPackSolution 任务打包解决方案。
7. 将构建好的解决方案 ZIP 文件收集到管道发布工件中。

建议将未打包的解决方案元数据以非托管形式提交到源代码管理系统中，以便在后续任何阶段创建开发环境。 （如果仅提交托管解决方案元数据，则很难创建新的开发环境。有两个选项可以执行此操作：

1. 使用 Solution Packager 的 /packagetype:Both 选项，将受管和非受管代码一并提交。 这允许在托管模式或非托管模式下进行打包，但在源代码中存在重复的缺点，这样，更改通常会出现在多个 xml 文件中（托管和非托管版本）。
2. 仅将未托管代码提交到源代码控制（从而获得更干净的变更集），然后在构建管道中，将打包的解决方案导入构建环境，以便随后将其作为托管代码导出，从而将其转换为托管部署工件。

版本管理和更新部署

部署和更新代码组件时，请务必制定一致的版本控制策略，以便可以：

• 跟踪已部署的版本及其包含的功能/修复。
• 确保画布应用可以检测到它们需要更新到最新版本。
• 确保模型驱动应用会使其缓存失效并加载新版本。

常见的版本控制策略是 语义版本控制，其格式为： MAJOR.MINOR.PATCH。

递增 PATCH 版本

将 ControlManifest.Input.xml 代码组件版本存储在控件元素中：

<control namespace="..." constructor="..." version="1.0.0" display-name-key="..." description-key="..." control-type="...">

在向代码组件部署更新时，ControlManifest.Input.xml 中的版本号至少需递增 PATCH（版本号的最后一部分），系统才能检测到该更改。 可以通过直接编辑版本属性或使用以下命令手动完成此操作，以便将 PATCH 版本提前一个：

pac pcf version --strategy manifest

或者，若要为 PATCH 部分指定一个确切值（例如，作为自动化构建流水线的一部分），请使用：

pac pcf version --patchversion <PATCH VERSION>

更多信息：pac pcf version。

何时增加 MAJOR 和 MINOR 版本号

建议使代码组件版本中的 MAJOR 和 MINOR 版本号与所分发的 Dataverse 解决方案保持同步。 例如：

1. 已部署的代码组件版本为 1.0.0 解决方案版本 1.0.0.0。
2. 您对代码组件进行少量更新，并使用 pac pcf version --strategy manifest 将该代码组件的 PATCH 版本号递增到 1.0.1。
3. 在为部署打包代码组件时，Solution.xml 中的解决方案版本会更新为 1.0.0.1，或者在手动导出解决方案时自动递增。
4. 对解决方案进行重大更改，以便将 MAJOR 和 MINOR 版本递增为 1.1.0.0。
5. 在这种情况下，代码组件版本也可以更新为 1.1.0。

Dataverse 解决方案有四个部分，可以在以下结构中考虑： MAJOR.MINOR.BUILD.REVISION

如果您使用的是 AzureDevOps，则可以使用 Build 和 Rev 环境变量（Run (build) number - Azure Pipelines）来设置生成管道的版本号，并使用与文章 Use PowerShell scripts to customize pipelines 中所述方法类似的 PowerShell 脚本。

语义化版本部分	ControlManifest.Input.xml 版本部分 MAJOR.MINOR.PATCH	Solution.xml 版本部分 MAJOR.MINOR.BUILD.REVISION	AzureDevOps 构建版本
MAJOR	MAJOR	严重	使用管道变量 $(majorVersion) 进行设置，或使用上次提交到源代码管理的值。
MINOR	MINOR	轻微	使用管道变量 $(minorVersion) 进行设置，或使用上次提交到源代码管理的值。
---	---	构建	$(Build.BuildId)
补丁	补丁	修订	$(Rev:r)

画布应用 ALM 注意事项

在画布应用中使用代码组件的方式不同于在模型驱动应用中的使用方式。 必须在“插入”面板中选择“获取更多组件”，将代码组件显式添加到应用。 将代码组件添加到画布应用后，该组件将作为应用定义中的内容包含在内。 若要在部署代码组件后更新到新版本的代码组件（且控制版本递增），应用创建者必须先在 Power Apps Studio 中打开该应用，并在更新代码组件对话框中出现提示时选择“更新”。 然后，必须保存并发布应用，以便在用户播放应用时使用新版本。

如果应用未更新或未使用 Skip ，则应用将继续使用旧版代码组件，即使它不存在于环境中，因为它已被较新版本覆盖。

由于应用包含代码组件的副本，因此可以从不同的画布应用在单个环境中并行运行不同的代码组件版本。 但是，不能在同一应用中并行运行不同版本的代码组件。 建议应用创建者在部署新版本时将其应用更新为最新版本的代码组件。

注释

尽管目前，可以导入画布应用，而无需将匹配的代码组件部署到该环境，但建议始终确保应用更新为使用最新版本的代码组件，并且同一版本首先或作为同一解决方案的一部分部署到该环境。

相关文章

使用 Microsoft Power Platform 进行应用程序生命周期管理 (ALM)
Power Apps组件框架 API 参考
创建您的第一个组件
调试代码组件