多个 devops 构建相互触发
Multiple devops builds triggering each other
我们使用 Azure DevOps 来构建和发布 Dynamics 365 Business Central 的本地安装。
我们维护着 3-4 个不同的存储库，每个存储库构成安装的一部分。我们有一个主存储库（基本应用程序），大约有。 8000 个源文件。这些不会经常更改，但它们是构建其他应用程序的基础。
当我们构建基础应用程序时，我们的主要工件是 sql 应用程序数据库备份。此备份包含我们创建新部署所需的内容。备份包含我们的基本应用程序代码和已发布的子应用程序，我们已将其下载为构建工件。
从技术上讲，这工作得很好。除了一个主要例外，我们无法跟踪触发构建的工作项的部署状态。由于大部分工作项目都与我们的子应用程序相关，因此这是一个问题。
为了解决这个问题，我研究了不同的选择。
一个存储库中的一切
第一个也是显而易见的是将所有内容放入一个大型存储库（示例 2）。从技术上讲，我确信这也能正常工作。但这会增加文件数量（基本应用程序有大约 8000 个对象）和每个应用程序的构建时间与基本应用程序的时间。每个子应用程序构建时间将从 5-10 分钟增加到 25-30 分钟或更长时间，这并不是很好。
子版本和主版本
理想情况下，我们希望有示例 3 中的设置。这里我们有一个进一步的构建。通过将基本应用程序构建分成两部分，第一个构建没有应用程序的 sql 备份工件，主构建将应用程序发布到数据库中。这将减少我们的子应用 build/release 时间大约。 15分钟。
但同样的问题是我们失去了对所有工作项引用的跟踪，因为它们没有从触发构建转移到主构建。
我能想到的最后一个方案是将仓库构建的结果直接发布到开发阶段（示例4）。这意味着我们将首先为每个部署阶段将所有不同的应用程序发布到数据库（除了开发，我们还有测试、uat、暂存和生产阶段）。我通过一个 "pre-development" 阶段来测试这样做，该阶段将发布应用程序并创建由以下阶段使用的备份。这也可行，但我无法使用 Azure Pipeline 或 Build Artifacts，因为它们只能由构建管道使用，而不能由发布管道使用。因此，如果我们这样做，我将需要改为发布到网络文件共享。
我们的构建基于 Yaml，而我们使用 "classic" 发布管道进行部署。
我还没有考虑使用多阶段管道，因为我发现它还没有完全准备好用于生产，特别是因为它们的 approval/gating 选项仍然非常有限。
我知道这是一个很长的问题，有很多细节（但可能还不够？）和个别问题，但是
我希望这里有人在他们想分享的领域有经验或见解。您认为不同选择的优缺点是什么。
或者有没有办法使工作项引用通过其他构建到发布，即使它们仅来自触发构建？
根据您的描述，邮件问题是“we lose track of the deployment states of the work items of the triggering builds”
如果要将相关工作项关联到发布，则必须为 build/release 管道设置 CI/CD。因此，来自 CI 构建的链接工作项将转移到 CD 版本中。而且它只能从与发布关联的 latest 构建中获取工作项。
例如，如果您有一个 commit/changeset，其中排列了工作项，那么您触发了一个 CI 构建 A 从这个 commit/changset 第一次。工作项将链接到此 CI 构建，一旦构建完成，CI 构建将触发 CD 发布，然后构建中的相关工作项将转移到 CD 发布。但是，如果您使用相同的 commit/changeset 在 第二次 手动触发构建 (B)，则工作项将不会链接到构建 B。
有关将工作项链接到发布的更多信息，请参考此线程：
如果其他构建触发 CI/CD build/release（例如构建 C 触发 CI 构建 D，然后 CI 构建 D 触发 CD 发布 )，然后链接到构建 C 的工作项将不会转移到构建 D 和进一步的 CD 发布。
我们使用 Azure DevOps 来构建和发布 Dynamics 365 Business Central 的本地安装。
我们维护着 3-4 个不同的存储库，每个存储库构成安装的一部分。我们有一个主存储库（基本应用程序），大约有。 8000 个源文件。这些不会经常更改，但它们是构建其他应用程序的基础。
当我们构建基础应用程序时，我们的主要工件是 sql 应用程序数据库备份。此备份包含我们创建新部署所需的内容。备份包含我们的基本应用程序代码和已发布的子应用程序，我们已将其下载为构建工件。
从技术上讲，这工作得很好。除了一个主要例外，我们无法跟踪触发构建的工作项的部署状态。由于大部分工作项目都与我们的子应用程序相关，因此这是一个问题。
为了解决这个问题，我研究了不同的选择。
一个存储库中的一切 第一个也是显而易见的是将所有内容放入一个大型存储库（示例 2）。从技术上讲，我确信这也能正常工作。但这会增加文件数量（基本应用程序有大约 8000 个对象）和每个应用程序的构建时间与基本应用程序的时间。每个子应用程序构建时间将从 5-10 分钟增加到 25-30 分钟或更长时间，这并不是很好。
子版本和主版本 理想情况下，我们希望有示例 3 中的设置。这里我们有一个进一步的构建。通过将基本应用程序构建分成两部分，第一个构建没有应用程序的 sql 备份工件，主构建将应用程序发布到数据库中。这将减少我们的子应用 build/release 时间大约。 15分钟。
但同样的问题是我们失去了对所有工作项引用的跟踪，因为它们没有从触发构建转移到主构建。
我能想到的最后一个方案是将仓库构建的结果直接发布到开发阶段（示例4）。这意味着我们将首先为每个部署阶段将所有不同的应用程序发布到数据库（除了开发，我们还有测试、uat、暂存和生产阶段）。我通过一个 "pre-development" 阶段来测试这样做，该阶段将发布应用程序并创建由以下阶段使用的备份。这也可行，但我无法使用 Azure Pipeline 或 Build Artifacts，因为它们只能由构建管道使用，而不能由发布管道使用。因此，如果我们这样做，我将需要改为发布到网络文件共享。
我们的构建基于 Yaml，而我们使用 "classic" 发布管道进行部署。 我还没有考虑使用多阶段管道，因为我发现它还没有完全准备好用于生产，特别是因为它们的 approval/gating 选项仍然非常有限。
我知道这是一个很长的问题，有很多细节（但可能还不够？）和个别问题，但是
我希望这里有人在他们想分享的领域有经验或见解。您认为不同选择的优缺点是什么。
或者有没有办法使工作项引用通过其他构建到发布，即使它们仅来自触发构建？
根据您的描述，邮件问题是“we lose track of the deployment states of the work items of the triggering builds”
如果要将相关工作项关联到发布，则必须为 build/release 管道设置 CI/CD。因此，来自 CI 构建的链接工作项将转移到 CD 版本中。而且它只能从与发布关联的 latest 构建中获取工作项。
例如，如果您有一个 commit/changeset，其中排列了工作项，那么您触发了一个 CI 构建 A 从这个 commit/changset 第一次。工作项将链接到此 CI 构建，一旦构建完成，CI 构建将触发 CD 发布，然后构建中的相关工作项将转移到 CD 发布。但是，如果您使用相同的 commit/changeset 在 第二次 手动触发构建 (B)，则工作项将不会链接到构建 B。
有关将工作项链接到发布的更多信息，请参考此线程：
如果其他构建触发 CI/CD build/release（例如构建 C 触发 CI 构建 D，然后 CI 构建 D 触发 CD 发布 )，然后链接到构建 C 的工作项将不会转移到构建 D 和进一步的 CD 发布。