为什么您的 Power Platform 设置需要一个存储库

代码仓库（Repo）就是用来存储你开发成果的地方。GitHub 可能是最著名的代码仓库（尽管它的功能远不止于此），但还有其他一些，例如 BitBucket、Artificatory 和 Assembla。

它可以存储为代码（可编辑的独立文件）或包（也称为工件），这样做有很多好处，但主要有以下几点：

• 源代码控制（不同的保存版本）
• 冗余（备份）
• 多开发人员协同工作（拆分/合并不同版本）
• 集成部署（开发/测试/生产）

所以你现在的问题是，为什么我需要在 Power Platform 中创建一个代码库？我的应用甚至流程现在都有版本历史记录。每个环境都有一个解决方案副本，我在手动部署或通过 Pipeline 部署时都会存储副本（解决方案副本存储在 Dataverse 中）。但这样做有几个原因，而且比你想象的要简单，让我们深入了解一下。

1. 为什么？——有什么好处？
2. 如何设置

1. 为什么——有什么好处

连接：
Power Platform 存在一个很大的问题，而这恰恰也是它最大的优势——连接。连接功能很棒，你可以使用自己的连接，无需费心设置 SPN（服务主体名称）。但现在问题来了，这些连接是你自己设置的。这意味着我们不应该共享连接（Power Automate 会利用这一点，以及如何避免）。在个人解决方案中，默认设置下这样做没问题，但如果是企业解决方案呢？如果你希望其他开发人员能够更新/维护流程/应用程序，就必须授予他们访问你连接的权限。这不仅会导致安全问题，还可能导致导出问题（如果一个流程使用了其他人的连接引用，你在解决方案中看不到它，因此导出时会缺少它，从而导致依赖关系问题）。

这时代码仓库就派上用场了。开发完成后，代码会被上传到代码仓库并从开发环境中删除。下一个需要继续开发的开发者只需下载并使用自己的连接导入即可。

代码一致性：
我经常看到这样的情况：开发人员将解决方案部署到生产环境后，又在开发版本上进行各种“修改”，尝试新的功能。他们往往就此搁置，等到需要更新时，这些未记录的更改就会导致意想不到的行为和错误。或者反过来，生产环境中存在一个错误，但由于开发版本不同，你无法在开发环境中重现它。

再次访问代码仓库可以确保您始终使用正确的版本。

维护
开发环境很容易变得非常混乱，难以管理和监控。更何况，所有数据都存储在 Dataverse 中，而 Dataverse 的容量有限（而且购买更多容量价格不菲）。一种解决方案是销毁环境（在 x 天后删除），这确实是一个不错的方案，但这也就意味着你更需要一个代码仓库，否则很多解决方案可能会丢失。

将代码存储在代码仓库中可以保持开发环境整洁，并且从长远来看很可能会为你省钱。

备份：
虽然 Power Platform 环境本身就具备恢复备份功能，但分散存储仍然是一个良好的实践。将数据存储在不同的平台上，可以确保在发生任何意外/灾难时不会丢失数据。这也有助于避免人为错误（例如，开发人员误删了某个解决方案，导致环境回滚，从而清除自备份以来其他开发人员的所有工作）。
 

2. 如何设置

存储解决方案主要有两种方式：代码或工件。

如果你想走代码路线，那么对于 Power Apps，你需要使用 Git 版本控制（它已经处于实验阶段 2 年多了），它直接与 GitHub 集成，我不会详细介绍，因为这里有很好的文档。

对于 Power Automate，您有更多选择，因为它本质上是 Dataverse 表中的一行数据（工作流），所以您可以将其存储在任何数据库中。您还需要对连接引用、环境变量和其他组件执行相同的操作。所有这些都可以实现（我已在此处详细介绍了解决方案），但我强烈建议您采用更简单的工件方法。

在这种方法中，我们让 Power Platform 完成所有打包工作，我们只需下载包含所有必要内容的完整 zip 文件即可。

由于我们只是存储一个 zip 文件，它可以存储在任何地方，所以最简单的显然是 SharePoint，但如果你想正确地存储它，我仍然建议使用像 Artifactory 这样的地方。

Dataverse API 提供了一个ExportSolution 操作，用于创建解决方案导出。您只需传入一些关键信息，它就会返回 zip 文件。因此，它很容易与专业代码解决方案集成，但更简便的方法是利用 Power Automate 和 Dataverse Unbound 操作（它调用的是同一个 API）。

以下示例导出解决方案并在 SharePoint 列表中创建一个项目。它会存储一些关键信息和一个唯一引用（运行 GUID）。然后，它会将导出内容附加到该项目。

可以根据需要调用（例如，当开发人员一天的工作结束时）、按计划调用，或者在部署过程中调用。

代码仓库可能会被视为维护的又一个“负担”，有人会认为“代码量少，所以不需要专业的代码流程”或者“微软已经帮我搞定了”，但我们真正应该关注的是它的价值。如果解决方案具有很高的价值，那么我们就需要规避风险，这时就需要采用成熟的专业代码流程，例如应用生命周期管理 (ALM) 和代码仓库（何必重复造轮子呢）。