使用分支时如何确定特定 TFS 构建中修复的工作项？答案

【问题标题】：How to Determine the Work Items Fixed in a particular TFS Build when using Branches?使用分支时如何确定特定 TFS 构建中修复的工作项？
【发布时间】：2011-11-24 01:54:15
【问题描述】：

我们已开始在 TFS 2010 中使用以下分支结构：

到目前为止，所有更改都在 Development 分支中执行，并且所有签入都与 Task 工作项相关联。这些任务都是 Bug 或 Product Backlog Item 工作项的子项。每个 CI 构建都会针对特定的变更集触发，并且变更集与任务相关联，因此我们可以手动确定刚刚构建了哪个 Bug 或 PBI。

在代码构建、部署到我们的集成环境并由开发人员测试后的一段时间，它被合并到主分支。显然，可以同时将多个变更集合并到 Main。如果我们在此之前不手动触发 nightly，则 nightly build 将构建此代码。 QA 稍后会将这些“主要”构建之一部署到 QA 环境。

自上次部署 QA 以来，可能已经对 Main 分支进行了多次构建。这些构建与“合并”变更集相关联，而不是与与任务关联的原始变更集。

如何确定给定“主”构建已解决的任务集，该构建是与任务工作项关联的分支不同的分支的构建？

一旦我们开始准备发布，我们很可能需要在 Release 分支中进行更改，这会使事情变得更加复杂，因为我们将从 Release 合并回 Main，并且 Release 变更集将与任务。然后这些将被合并到开发中，让生活变得更加有趣！

附：问题“How to determine the work items associated with a source branch in TFS 2010?”接近于问同样的问题，但不完全是。

【问题讨论】：

标签： tfs branch tfsbuild tfs-workitem

【解决方案1】：

查看 Jacob Ehn 的博文 Automatically Merging Work Items in TFS 2010。他写了一个插件，可以从codeplex下载。它将自动关联与合并的变更集关联的工作项。因此，当您合并到 Main 或 Release 时，工作项将与这些分支中的变更集相关联，并且工作项将包含在构建报告中，以便从这些分支构建。该插件非常易于部署。

【讨论】：

有人用过这个插件吗？你能提供一些反馈吗？它像它说的那样工作吗？有什么问题吗？

【解决方案2】：

另一个选项是您可以构建自定义工作流活动，您可以在构建期间运行该活动，该活动可以遍历通常关联的每个变更集的合并历史记录。它本质上是从一组已知的关联变更集开始遍历树。我更喜欢这种方法，因为您可以让您的开发人员担心只需要将工作项与原始变更集相关联，而不必同时使用合并变更集。这也让您不必像 Bryan 在他的建议中描述的那样部署自定义工作项策略。

如果你想通过http://www.edsquared.com与我联系，我可能有一些示例代码可以帮助你开始遍历合并历史树

【讨论】：

你好 Ed，这听起来很有趣。在Gated check-in模式下是否可以使用它？在这种情况下，总是只有一次签到。此签入不在代理范围内，它基本上是最后发生的事情（在发生之前，您不知道相关变更集的 ID）
最重要的是 - 我们的问题是相互关联的，我在 stackoverflow.com/questions/7555028/… 上取得了一些进展 - 希望它会有所帮助？！
嗨 Pantelif - 门控签入构建将是我不相信这会起作用的一个。通常会在 Gated Check-In 构建定义旁边创建另一个构建定义，该定义将创建所使用的“官方”构建。我通常使用与相应的 Nightly 构建类似的东西。