我们使用 Azure DevOps 构建和发布 Dynamics 365 Business Central 的本地安装。
我们维护 3-4 个不同的存储库，每个存储库构成安装的一部分。我们有一个主存储库（基本应用程序），大约有。8000 个源文件。这些不会经常更改，但它们是构建其他应用程序的基础。
当我们构建我们的基础应用程序时，我们的主要工件是一个 sql 应用程序数据库备份。此备份包含我们创建新部署所需的内容。备份包含我们的基本应用程序代码和已发布的子应用程序，我们已下载为构建工件。
从技术上讲，这工作得很好。除了一个主要的例外，我们忘记了触发构建的工作项的部署状态。而且由于大部分工作项都与我们的子应用程序相关，所以这是一个问题。
为了解决这个问题，我研究了不同的选择。
一个存储库中 的所有内容 第一个也是显而易见的是将所有内容放入一个大型存储库中（示例 2）。从技术上讲，我确信这也可以正常工作。但这会增加文件的数量（基本应用程序有大约 8000 个对象）和每个应用程序的构建时间与基本应用程序的时间有关。每个子应用程序构建将从 5-10 分钟到 25-30 分钟或更长时间，这并不是很好。
子和主构建 理想情况下，我们希望拥有示例 3 中的设置。这里我们有一个进一步的构建。通过将基础应用程序构建分成两部分，其中第一个在没有应用程序的情况下创建我们的 sql 备份工件，而主版本将应用程序发布到数据库中。这将减少我们的子应用程序构建/发布时间。15分钟。
但同样的问题是我们丢失了所有工作项引用，因为它们没有从触发构建转移到主构建。
我能想到的最后一个选项是将存储库构建的结果直接发布到开发阶段（示例 4）。这意味着我们将首先在每个部署阶段将所有不同的应用程序发布到数据库中（除了开发，我们还有测试、uat、暂存和生产阶段）。我通过“预开发”阶段对此进行了测试，该阶段将发布应用程序并创建供后续阶段使用的备份。这也可以，但我无法使用 Azure Pipeline 或 Build Artifacts，因为它们只能由构建管道使用，而不是由发布管道使用。因此，如果我们要这样做，我将需要发布到网络文件共享。
我们的构建基于 Yaml，而我们使用“经典”发布管道进行部署。我还没有考虑使用多阶段管道，因为我发现它还没有完全准备好投入生产，特别是因为它们的批准/门控选项仍然非常有限。
我知道这是一个很长的问题，有很多细节（但可能还不够？）和个别问题，但
我希望这里有人在他们想分享的领域有经验或见解。您认为不同选项的优缺点是什么。
或者有没有办法让工作项引用通过其他构建到发布，即使它们只是来自触发构建？