Microsoft Power Platform ALM 基础知识
本文介绍实施应用程序生命周期管理 (ALM) 所需的组件、工具和流程。
环境
所谓环境，就是存储、管理和共享您组织的业务数据、应用程序和业务流程的空间。 还充当容器来隔离可能具有不同角色、安全要求或目标受众的应用。 每个环境只能有一个 Microsoft Dataverse 数据库。 更多信息：环境概述
重要提示
当您创建环境时，您可以选择安装 Dynamics 365 应用，例如 Dynamics 365 Sales 和 Dynamics 365 Marketing。 务必在此时确定是否需要这些应用，因为以后不能卸载或安装这些应用。 如果不基于这些应用创建，将来也不需要这些应用，建议不要在环境中安装这些应用。 当您在环境之间分配解决方案时，这将有助于避免依赖关系的复杂性。
ALM 中使用的环境类型
您可以使用 Power Platform 管理中心创建以下类型的 Power Platform 环境：
沙盒沙盒环境是 Dataverse 的任何非生产环境。 由于它与生产环境相隔离，因此，使用沙盒环境可以安全地开发和测试应用程序更改，只有较低的风险。 沙盒环境包含在生产环境中有害的功能，如重置、删除和复制操作。 详细信息：管理沙盒环境
生产此环境中的应用和其他软件按其预期用途投入使用。
开发人员（正式名称为社区）。 通过 Power Apps 开发人员计划，您可以访问 Power Apps 高级功能、Dataverse 和 Power Automate 进行个人使用。 此计划主要用于使用 Power Apps、Power Automate 和 Microsoft Dataverse 进行构建和测试，或用于学习目的。 开发人员环境是单用户环境，不能用于运行或共享生产应用。
默认为每个租户自动创建单个默认环境，并且该租户中的所有用户共享该环境。 租户标识客户，客户可能具有一个或多个与之关联的 Microsoft 订阅和服务。 只要新用户注册 Power Apps，就会自动获得默认环境的创建者角色。 默认环境在离 Microsoft Entra 租户的默认区域最近的区域中创建，并被命名为：“{Microsoft Entra 租户名称}（默认）”
为特定目的（如开发、测试或生产）创建和使用正确的环境。
有关环境的详细信息，请参阅环境概述。
谁应该有访问权限？
定义和管理 Microsoft Dataverse 中的资源和数据的安全性。 Microsoft Power Platform 提供了用于执行任务的环境级管理角色。 Dataverse 包括一些安全角色，这些安全角色定义应用创建者及用户在 Dataverse 中对应用、应用组件和资源的访问级别。
| 环境用途 | 具有访问权限的角色 | 注释 |
|---|---|---|
| 开发 | 应用创建者和开发人员。 | 应用用户不应具有访问权限。 开发人员至少需要“环境创建者”安全角色才能创建资源。 |
| 测试 | 管理员和测试人员。 | 应用创建者、开发人员和生产应用用户不应具有访问权限。 测试用户只应具有足以执行测试的权限。 |
| 生产 | 管理员和应用用户。 用户只应具有足以针对他们使用的应用执行任务的访问权限。 | 应用创建者和开发人员不应具有访问权限，或者只应具有用户级别特权。 |
| 默认 | 默认情况下，租户中的每个用户都可以在具有数据库的 Dataverse 默认环境中创建和编辑应用。 | 强烈建议您创建特定用途的环境，并仅将适当的角色和特权授予需要它们的人员。 |
详细信息：
解决方案
解决方案用于将应用和组件从一个环境传输到另一个环境，或将一组自定义项应用到现有应用。
解决方案具有以下功能：
其中包括元数据和具有配置数据的某些实体。 解决方案不包含任何业务数据。
它们可以包含许多不同的 Microsoft Power Platform 组件，例如模型驱动应用、画布应用、站点地图、流、实体、窗体、自定义连接器、Web 资源、选项集、图表和字段。 请注意，并非所有实体都可以包含在解决方案中。 例如，应用程序用户、自定义 API 和组织设置系统表无法添加到解决方案中。
它们被打包为一个单元以导出和导入到其他环境中，或者被析构并作为资产源代码签入到源代码管理中。 解决方案还用于将更改应用于现有解决方案。
托管解决方案用于部署到不是该解决方案的开发环境的任何环境中。 其中包括测试、用户验收测试 (UAT)、系统集成测试 (SIT) 和生产环境。 托管解决方案可以独立于环境中的其他托管解决方案进行维护（升级、修补和删除）。 作为 ALM 最佳实践，托管解决方案应由生成服务器生成，并应被视为生成项目。
托管解决方案更新会部署到以前版本的托管解决方案中。 这不会创建其他解决方案层。 您不能使用更新删除组件。
修补程序仅包含对父托管解决方案所做的更改。 仅在执行少量更新（与修补程序类似）时，您才应该使用修补程序，并且您可能需要卸载它。 导入修补程序后，它们将位于父解决方案之上的层。 您不能使用修补程序删除组件。
升级解决方案将直接在基础层和任何现有修补程序上方安装新的解决方案层。
应用解决方案升级涉及删除所有现有修补程序和基础层。
解决方案升级将删除已存在但不再包含在升级版本中的组件。
详细信息：解决方案概念
源代码管理
源代码管理（也称为版本控制）是一种系统，用于维护和安全存储软件开发资产并跟踪对这些资产所做的更改。 当多个应用创建者和开发人员处理同一组文件时，更改跟踪尤其重要。 源代码管理系统还使您能够回滚更改或还原已删除的文件。
因为在源代码管理系统中维护的资产是“单一事实来源”—即解决方案的单点访问和修改，所以源代码管理系统可帮助组织实现正常的 ALM。
分支和合并策略
几乎每个源代码管理系统都具有某种形式的分支和合并支持。 分支意味着您需要分离开发的主行，并在不更改主行的情况下继续执行工作。 合并的过程包括将一个分支合并到另一个分支中，例如从开发分支合并到主行分支中。 一些常见的分支策略包括基于主干的分支、版本分支和功能分支。 详细信息：采用 Git 分支策略
使用解决方案的源代码管理过程
在源代码管理系统中使用解决方案时，可使用两个主要途径：
- 导出非托管解决方案并将其解包后放在源代码管理系统中。 生成过程会将打包的解决方案作为非托管解决方案导入到临时生成环境（沙盒环境）中。 然后，将解决方案导出为托管解决方案，并将其作为生成项目存储在源代码管理系统中。
- 将解决方案导出为非托管解决方案，并将其导出为托管解决方案，然后将它们放在源代码管理系统中。 尽管此方法不需要生成环境，但确实需要维护所有组件的两个副本（非托管解决方案中所有非托管组件的一个副本和托管解决方案中所有托管组件的一个副本）。
详细信息：生成工具任务
自动化
自动化是应用程序生命周期中的一个关键部分，可提高 ALM 的效率、可靠性、质量和效能。 自动化工具和任务用于验证、导出、打包、解包和导出解决方案，以及创建和重置沙盒环境。
详细信息：什么是 Microsoft Power Platform Build Tools？
使用共享的源代码管理进行团队开发
请考虑您和您的开发团队如何共同生成项目，这一点很重要。 打破孤岛并建立新的视图和对话会使您的团队能够提供更好的软件。 某些工具和工作流（如 Git 和 GitHub 和 Azure DevOps 中提供的工具和工作流）旨在快速提高通信和软件质量。 请注意，使用解决方案系统中的配置会为团队开发带来挑战。 组织必须协调多个开发人员所做的更改以尽可能避免合并冲突，因为源代码管理系统对合并发生的方式具有限制。 我们建议您避免出现以下情况：多人同时对复杂组件（如窗体、流和画布应用）进行更改。
详细信息：场景 5：支持团队开发
持续集成和部署
您可以使用任何源代码管理系统，并生成管道以开始进行连续集成和连续部署 (CI/CD)。 不过，本指南着重介绍 GitHub 和 Azure DevOps。 GitHub 是数百万开发人员使用的开发平台。 Azure DevOps 为开发人员提供服务，以支持团队计划工作、进行代码开发协作以及构建和部署应用。
首先，您需要：
详细信息：创建您的第一个管道
许可
为了分别使用 Power Apps 和 Power Automate 创建或编辑应用和流，用户将需要具有 Power Apps或 Power Automate 的每用户许可证，或者相应的 Dynamics 365 应用程序许可证。 有关更多信息，请参阅Microsoft Power Platform 许可概述。 我们还建议联系您的 Microsoft 帐户代表来讨论您的许可需求。
ALM 注意事项
当您将 ALM 视为在 Microsoft Power Platform 上构建应用程序所不可或缺的一部分时，它可以大大改进应用的速度、可靠性和用户体验。 它还可以确保多个开发人员（编写代码的传统开发人员和平民开发人员）能够联合参与构建应用程序。
请参阅以下文章，其中介绍了在任何应用程序开发开始时需要考虑的几个事项：