Bre*_*ett
5
azure-devops
azure-pipelines
我们遇到的情况是，我们的工作项被包含在许多构建中，并且没有足够的文档，我似乎无法弄清楚原因。想知道这里是否有人能对此有所启发。
示例场景是
- 我们运行“发布流”分支策略（就像微软描述的 Azure DevOps 所做的那样）
- Bug 30368 链接到一个功能分支，并通过 PR 2991 回到 master 并提交 cb9120d0。
- 为此，PR 和分支的所有适当链接都已到位，因此 PR 和主提交都正确显示了工作项的链接
- 我们创建了 master 的发布分支，30368 包含在 v2.97.0 构建管道中，并通过“集成到构建”（正确）链接到该构建
- 构建 1 已创建
- 然后，我们在发布测试期间在 v2.97.0 中遇到了一个错误（与错误 20368 无关），因此我们将修复后的主提交挑选到了发布分支中（根据发布流程指南）。
- 我想知道这个 Cherry Pick 是我稍后描述的问题的原因
- 当然，该工作项并未包含在 v2.97.0 的第二个版本中，仅包含具有相关修复的工作项
- 构建 2 已创建
- 所以到目前为止一切都很好。v2.97.0 版本是从 Build 2 部署的，所有链接都是正确的
- 现在我们从 master 分支发布 v2.98 版本，并且发布管道进行另一个构建。
- 由于某种原因，它确定 30368 也应该链接到此版本，并向 v2.98 版本添加“集成版本”？
我发现的唯一其他线索是与构建链接的提交有关。在这里我可以看到我得到以下内容
构建1
- 来自 e0faff8f （master 2019-12-02 提交版本 2.97 是从 分支出来的）
- 到 db225f14（来自 PR 于 2019 年 11 月 21 日完成之前的功能分支）
构建 2
- 来自 aeaf3dc5（发布分支 2019-12-03 精选）
- 至 e0faff8f（拉取请求分支 2019-12-03）
构建 3
- 来自f2ce6d3d（发布分支2019-12-06）
- 至 f3db8c7b (2019-12-02)
我什至不清楚构建管道如何知道其中包含 git 提交的范围，也许这是理解链接的关键。当然，它从构建运行的提交中获取 From 部分，但它如何知道应该转到哪个提交？
同样在上面的示例中，为构建 1 或构建 3 给出的范围似乎都没有与其中的项目 (cb9120d0) 相关的提交 - 即使此工作项目已链接到这些构建？
这一切都非常令人困惑和模糊。
有人让这个功能正确/可靠地工作吗？
我还想知道我们是否需要为每个分支创建特定的管道，以便每个分支都是独立的，但我不确定，即使您创建一个全新的管道并将其指向主分支，它也不包含每一个提交（和工作项）在该构建中。再说一遍，它怎么知道从哪里开始呢？