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

Question

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

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

在构建代码，部署到我们的Integration环境并由开发人员测试之后的某个时间，它将合并到Main分支。显然，可以同时将多个变更集合并到Main。如果我们在此之前没有手动触发每晚，那么每晚构建将构建此代码。 QA稍后会将这些“主要”构建中的一个部署到QA环境中。

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

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

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

---

P.S。问题“How to determine the work items associated with a source branch in TFS 2010?”接近提出同样的问题，但并不完全。

Answer 1

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

Answer 2

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

如果您想通过http://www.edsquared.com

与我联系，我可能会有一些示例代码让您开始遍历合并历史记录树