ALM 重要注意事项

  • 8 分钟

解决方案架构师需要定义项目的应用程序生命周期管理 (ALM) 策略。 本任务是帮助组织建立正确的解决方案治理过程的一部分。

环境策略

环境是一个容器，用于存储、管理和共享业务数据、应用、流、连接和其他资产以及允许组织成员使用资源的权限。

环境可充当容器，用于分隔可能具有不同角色、安全要求或目标受众的应用。 您选择使用环境的方式取决于您的组织和您尝试构建的应用程序，例如：

  • 可以选择只在一个环境中构建所有应用。
  • 可以创建对应用的测试和生产版本进行分组的独立环境。
  • 可以为公司中的特定团队或部门创建对应的独立环境，每个环境都包含每个访问群体的相关数据和应用。
  • 可以为公司的不同全球分支创建独立环境。

开发环境策略意味着以支持在组织中进行高效开发的方式配置环境和其他数据安全层，同时保护和组织资源。 策略用于管理环境预配和访问以及控制环境资源，在以下方面中发挥着重要作用：

  • 保护数据及访问权限。
  • 了解如何正确使用默认环境。
  • 管理正确的环境数量以避免无序扩展，并节约容量。
  • 便于应用程序生命周期管理 (ALM)。
  • 在逻辑分区中组织资源。
  • 将应用置于专用环境中，从而支持各种操作（服务台）来识别处于生产环境的应用。
  • 确保数据在可接受的地理区域（出于性能和合规性原因）中存储和传输。
  • 确保隔离正在开发的应用程序。

显示环境策略示例的图表。

Microsoft Power Platform 中有以下环境的类型可供使用：

  • 沙盒 - 沙盒环境是 Dataverse 的任何非生产性环境。 沙盒环境与生产环境隔离，可用于安全开发并以较低风险测试应用程序更改。
  • 生产 - 本环境中的应用和其他软件按其预期用途投入使用。
  • 社区（开发人员） - Power Apps 社区计划允许用户访问 Power Apps 高级功能、Dataverse 和 Microsoft Power Automate 以仅供个人使用。 本环境主要用于学习目的。 开发人员环境是单用户环境，不能用于运行或共享应用。 可以将社区计划环境加入 Azure DevOps 管道。
  • 默认 - 为每个租户自动创建单个默认环境，并且该租户中的所有用户共享该环境。 Microsoft 365 服务使用默认环境。
  • 试用 - 试用环境用于尝试新功能或执行概念证明。 30 天后将自动删除试用环境。

重要提示

解决方案架构师需要定义需要的环境数量、环境用途以及环境之间的依赖关系。 正常运行的 ALM 实践应在将任何内容部署到生产环境之前至少使用一个测试环境。 本实践可确保提供应用测试环境，此外也可确保测试部署。

有关详细信息，请参阅环境和环境策略。

处理解决方案和其他非解决方案感知的代码和组件

Microsoft Power Platform 项目包括可以 在环境解决方案内打包的组件和无法 添加到解决方案的组件。 不可添加的组件包括部署在 Azure 中的组件、配置数据和 Power BI 报表。 ALM 计划必须考虑如何处理这些非解决方案感知的组件。

解决方案架构师需要决定是使用解决方案还是源代码管理来管理应用程序生命周期管理。 传统上，Microsoft Power Platform 项目多以环境为中心，但现在许多项目转向以源代码管理为中心。

如果使用以环境为中心的方法，则：

  • 开发环境是所有更改的主副本。
  • 根据开发 > 测试 > 生产直接提升更改。

如果使用以源代码管理为中心的方法，则：

  • 源代码管理是主副本。
  • 从源代码管理重新创建开发环境（此流程可自动执行且可重复）。
  • 将开发环境中的更改签入源代码管理中。

显示以源代码为中心的方法的图表。

以源代码管理为中心的方法鼓励您具有明确的主副本，并且能够为任何跟踪版本重新创建开发环境。 目前，Microsoft 鼓励并构建工具，为以源代码管理为中心的 ALM 提供支持。

注意

理想情况下，除生产环境之外的所有环境都应丢弃，换言之，可以删除并重新创建开发和测试环境，且不会丢失任何数据。

使用以源代码管理为中心的方法将启用包含生成和发布管道的 Azure DevOps 方法。 使用以环境为中心的方法意味着需要为应用制作者和开发人员定义工作流。 解决方案架构师需要定义将应用从开发环境提升到生产环境的方式和人员。

解决方案架构师还需要定义如何配置每个环境并寻找简化方法。

团队合作

与传统应用开发相比，Microsoft Power Apps 项目在两个重要方面有所不同：

  • 项目团队各成员如何协作创建解决方案
  • 开发方法

Power Apps 是一个可使专业开发人员和平民开发者受益的平台。 在传统开发环境中，只有专业开发人员才能参与应用的实际制作。 使用 Power Apps，所有人都能够使用以前仅对专业开发人员可用的高级功能来构建所需的应用。 Power Apps 使用户无需编写代码即可构建功能丰富的自定义商业应用程序，从而使自定义商业应用程序构建体验实现大众化。

显示开发生态系统的图表。

使用 Power Apps，您可以快速创建可使用的应用版本，因为 Power Apps 提供 WYSIWYG（所见即所得）开发体验。 可以在开发流程的早期体验实际工作应用，如果有新的要求，可以将新功能添加到下一版本中。

Power Apps 开发方法的示意图。

在 Microsoft Power Platform 内自定义和开发组件时出现的问题包括：

  • Microsoft Power Platform 不支持组件版本控制（画布应用除外）。
  • 用户不能同时使用同一 Microsoft Power Platform 组件。
  • 模型驱动应用具有多个组件，每个组件都有自己的编辑器，允许各制作者分开工作。 相反，画布应用只有一个编辑器，一次只允许一个人使用应用。 通过使用画布组件，可以允许多个制作者同时使用同一应用。

解决方案架构师应建立一个工作流，指导应用生成者如何进行更改和提升更改。 应实施主动沟通和工作分配管理，以最大限度地减少制作者之间的冲突。

可以为每个制作者创建一个环境来最大程度减少各制作者之间的冲突。 单个制作者环境能够实现隔离和跟踪，但需要付出额外努力来合并工作并解决冲突。 共享制作者环境可能简单一些，但它无法为应用生成者提供隔离环境，并且缺少详细的更改跟踪信息。

源代码管理

尽管使用的是以环境为中心的方法，但仍需决定解决方案和代码主副本的保存位置。

适应解决方案的开发人员代码资产（如插件、PCF 代码组件和窗体脚本（从 TypeScript 转译而来））应在生成环境中生成，而不是在开发人员桌面上生成。 资产生成后，应将其部署到将从中导出主解决方案的环境中，或者将其构建到将安装的解决方案中。

工具

Microsoft 提供以下多种可在 Microsoft Power Platform 中与 ALM 一起使用的工具和应用：

  • Microsoft Power Platform 管理中心 - 为管理员提供统一门户以创建和管理环境。
  • Power Apps build tools - 通过使用 Azure DevOps 自动执行与 Power Apps 相关的常见生成和部署任务。
  • GitHub - 常用的版本控制系统。
  • Configuration Migration Tool - 支持跨环境移动配置和/或引用数据。
  • Package Deployer - 支持将资产包部署到 Dataverse 实例。 包可以包含解决方案文件和平面文件、自定义代码、HTML 文件和数据。
  • Solution Packager - 一种可将压缩的解决方案文件解包到多个 XML 文件和其他文件中的工具，以便可以通过源代码管理系统实现轻松管理。
  • Microsoft Power Apps CLI - 一种简单的命令行接口，使开发人员能够创建代码组件。
  • 包部署 PowerShell 模块 - 用于将包部署到 Dataverse 环境。
  • Power Apps 检查器 PowerShell 模块 - 与 Power Apps 检查器服务交互，以便您可以运行静态分析作业并下载结果。

注意

适用于 Microsoft Power Platform 的 GitHub 操作当前处于预览版阶段。