在使用分支时，如何确定特定TFS构建中固定的工作项？
我们已经开始在TFS 2010中使用以下分支结构：
到目前为止，所有更改都已在“开发”分支中执行，并且所有签入都已与任务工作项关联。这些任务都是Bug或Product Backlog项工作项的子项。每个CI构建都是针对特定的变更集触发的，并且变更集与任务相关联，因此我们可以手动确定哪个Bug或PBI是刚刚构建的。
在构建代码、部署到我们的集成环境并由开发人员进行测试后，一段时间后，它将合并到主分支。显然，可以同时将多个变更集合并到Main。如果我们不在此之前手动触发夜间构建，则夜间构建将构建此代码。QA稍后会将其中一个“主”构建部署到QA环境中。
自从上一次QA部署以来，可能已经有几个主分支的构建。这些生成与“合并”变更集关联，而不是与任务关联的原始变更集关联。
如何确定已由给定的“主”构建处理的任务集，该“主”构建是与任务工作项相关联的分支的构建？
一旦我们开始准备发布，我们很可能需要在release分支中进行更改，这将使事情变得更加复杂，因为我们将从Release合并回Main，并且Release变更集将与任务相关联。然后，这些将被合并到开发中，使生活更加有趣！
附注:问题"How to determine the work items associated with a source branch in TFS 2010?“接近于问同样的问题，但并不完全是这样。
回答 2
Stack Overflow用户
发布于 2011-09-27 04:50:43
看看雅各布·伊恩的博客帖子Automatically Merging Work Items in TFS 2010。他写了一个插件，可以从codeplex下载。它将自动关联与合并的变更集关联的工作项。因此，当您合并到Main或Release时，工作项将与这些分支中的变更集相关联，并且工作项将包含在这些分支的构建的构建报告中。该插件非常容易部署。
Stack Overflow用户
发布于 2011-09-28 08:27:14
另一种选择是，您可以构建自定义工作流活动，该活动可以在构建期间运行，该活动可以遍历通常关联的每个变更集的合并历史记录。它本质上是从一组已知的关联变更集开始遍历整个树。我更喜欢这种方法，因为您可以让您的开发人员担心只需要将工作项与原始变更集相关联，而不必同时使用合并变更集进行关联。这还允许您避免部署自定义工作项策略，就像Bryan在他的建议中所描述的那样。
如果您想通过http://www.edsquared.com与我联系，我可能有一些示例代码可以帮助您开始遍历合并历史记录树
https://stackoverflow.com/questions/7536323
复制相似问题
腾讯云开发者
