Azure devops 多个devops构建相互触发

我们使用Azure DevOps构建和发布Dynamics 365 Business Central的内部安装

我们维护3-4个不同的存储库，每个存储库构成安装的一部分。我们有一个主存储库（基本应用程序），大约有8000个源文件。这些并不是经常改变的，而是其他应用程序构建的基础。 当我们构建基础应用程序时，我们的主要工件是sql应用程序数据库备份。此备份包含创建新部署所需的内容。备份包含我们的基本应用程序代码和已发布的子应用程序，我们已下载为构建工件

从技术上讲，这很好用。除了一个主要的例外，我们无法跟踪触发构建的工作项的部署状态。由于大多数工作项都与我们的子应用程序相关，因此这是一个问题

为了解决这个问题，我研究了不同的选择

一个存储库中的所有内容 第一个也是显而易见的是将所有内容放在一个大型存储库中（示例2）。从技术上说，我相信这也行。但这将增加文件的数量（基本应用程序大约有8000个对象）以及每个应用程序的构建时间。每个子应用程序的构建时间从5-10分钟到25-30分钟或更长，这并不太好

子版本和主版本 理想情况下，我们希望使用示例3中的设置。在这里，我们有一个进一步的建设。通过将基本应用程序构建一分为二，第一个构建创建了没有应用程序的sql备份工件，而主构建将应用程序发布到数据库中。这将缩短我们的子应用程序构建/发布时间约15分钟

但同样的问题是，我们无法跟踪所有工作项引用，因为它们没有从触发构建转移到主构建

我能想到的最后一个选择是将存储库构建的结果直接发布到开发阶段（示例4）。这意味着我们将首先为每个部署阶段将所有不同的应用程序发布到数据库中（除了开发，我们还有测试、uat、阶段和生产阶段）。我通过一个“预开发”阶段来测试这一点，该阶段将发布应用程序并创建一个用于以下阶段的备份。这也可以，但我不能使用Azure管道或构建工件，因为这些只能由构建管道使用，而不能由发布管道使用。因此，如果我们这样做，我将需要发布到网络文件共享

我们的构建基于Yaml，而我们使用“经典”发布管道进行部署。 我还没有考虑使用多级管道，因为我发现它还没有完全准备好投入生产，特别是因为它们的批准/控制选项仍然非常有限

我知道这是一个很长的问题，有很多细节（但可能还不够？） 我希望在座的人在他们想分享的领域有经验或见解。你认为不同选择的利弊是什么

---

或者，有没有办法使工作项引用通过其他版本传递到发行版，即使它们仅来自触发版本？

根据您的描述，邮件问题是“

我们无法跟踪触发版本的工作项的部署状态”

”

如果要将相关工作项与发布关联，则必须为构建/发布管道设置CI/CD。因此，CI构建中链接的工作项将传输到CD版本。并且它只能从与发布相关联的最新版本中获取工作项

例如，如果您有一个提交/变更集，其中有一行工作项，那么您第一次从该提交/变更集触发了一个CI构建a。工作项将链接到此CI生成，并且CI生成将在生成完成后触发CD版本，然后来自生成的关联工作项将传输到CD版本。但是，如果使用相同的提交/变更集第二次手动触发生成（B），则工作项将不会链接到生成B

有关将工作项链接到发布的更多信息，请参考以下线程：

---

如果其他生成触发CI/CD生成/发布（例如生成C触发CI生成D，然后CI生成D触发CD发布），则链接到生成C的工作项将不会转移到生成D和进一步的CD发布

谢谢，这确认了设置。在发布阶段维护相关工作项/提交的最佳（唯一）解决方案是将所有内容都放在一个存储库中吗？据我所知，如果使用一个repo和多个管道，主构建将能够有管道触发器，但仍然保持工作项链接。除了CI/CD之外，还有另一个触发器称为

构建完成触发器

（纯触发器没有源关联），如果没有源工件传输到进一步的构建/发布管道，那么工作项链接将不会保留。对于相关的工作itmes/提交，不需要在一个存储库中进行。它们可以在多个repo中执行，只需确保从特定repo生成的工件在发布中设置为工件源。（将WI关联到提交/变更集->从特定提交/变更集生成并生成工件->设置为发布工件源）