我们有两个从同一存储库中的两个不同路径构建的构建管道。
BuildPipelineA 从 AppRepo 构建 / PathA 并发布工件 ArtifactA
BuildPipelineB 从 AppRepo 构建 / PathB 并发布工件 ArtifactB
然后我们有一个发布管道，使用这两个构件将应用程序部署到某些WebApp。
作为分支策略，我们使用自定义Gitflow工作流。唯一的区别是我们有两个开发团队，每个开发团队都有自己的集成部门。因此，基本上，我们有了develop，develop和develop-teamAlpha，而不是经典的develop-teamBeta分支。除了master，release/和hotfix/之外，触发器还设置给所有三个分支。因此，总共有六个要作为目标的分支。
我要实现的目标是拥有一个CI / CD流程，该流程将始终从匹配（相同）分支中获取工件以进行自动触发的发行版创建。
例如，假设存在先前的master ArtifactB ：
开发者在master上更改 / PathA
BuildPipelineA 从master
ReleasePipeline 现在应该使用master ArtifactA 和master ArtifactB < / p>
即使触发工件来自不同的分支，我也希望发生相同的事情：
开发者在develop上更改 / PathB
BuildPipelineB 从develop
ReleasePipeline 现在应使用develop ArtifactB 和（现有）develop ArtifactA 创建新版本strong>
尝试1： 因此，我尝试的第一件事是使用$（Release.Artifacts.ArtifactA.SourceBranch）作为 ArtifactB 的源分支： Release.Artifacts.webapp.SourceBranch example
这不起作用，因为此变量取决于发行版，因此已经选择了其工件。
尝试2： 我的第二次尝试是创建一个将两个工件组合在一起的新管道，同时确保它们是来自特定匹配分支的最新工件。
此构建将通过完成 BuildPipelineA 或 BuildPipelineB 来触发。我使用了一些API调用来获取触发构建的源分支，并使用它从匹配的分支中下载 ArtifactA 和 ArtifactB ，然后发布新的，合并的， ArtifactC 。
由于此“组合管道”的源存储库无关紧要，因此我选择使用第二个存储库，该存储库存储了我用于API调用的脚本。
现在，通过此操作，我无法控制用于从 ArtifactC （组合工件）创建新版本的分支，因为该工件的来源始终来自第二个存储库的{ {1}}分支。这也使我失去了Azure DevOps提供的所有可追溯性。以下示例可能使事情更清楚：ArtifactC
此外，它根本不会与我们用于每个不同环境的工件过滤设置集成。
我很乐意接受任何建议。
