提问人：John Saunders 提问时间：9/24/2011 最后编辑：CommunityJohn Saunders 更新时间：2/1/2013 访问量：7476
使用分支时，如何确定特定 TFS 生成中修复的工作项？
How to Determine the Work Items Fixed in a particular TFS Build when using Branches?
问：
我们已开始在 TFS 2010 中使用以下分支结构：
到目前为止，所有更改均已在“开发”分支中执行，并且所有签入都已与任务工作项相关联。任务都是 Bug 或产品积压工作项工作项的子项。每个 CI 构建都是针对特定变更集触发的，并且该变更集与一个 Task 相关联，因此我们可以手动确定刚刚构建了哪个 Bug 或 PBI。
在代码构建、部署到我们的集成环境并由开发人员测试后的一段时间内，它将合并到 Main 分支。显然，多个变更集可以同时合并到 Main。如果我们在此之前不手动触发 nightly 构建，则 nightly 构建将构建此代码。QA 稍后会将其中一个“主要”版本部署到 QA 环境。
自上次部署 QA 以来，可能已经有多个 Main 分支版本。这些生成与“合并”变更集相关联，而不是与与任务关联的原始变更集相关联。
如何确定给定的“主”生成已解决的任务集，该生成是与与任务工作项关联的分支不同的分支的生成？
一旦我们开始准备发布，我们很可能需要在 Release 分支中进行更改，这将使事情变得更加复杂，因为我们将从 Release 合并回 Main，并且 Release 变更集将与 Tasks 相关联。然后，这些将被合并到开发中，使生活更加有趣！
P.S. 问题“如何确定与 TFS 2010 中的源分支关联的工作项？”接近于提出相同的问题，但并不完全是。
答：
9赞
Bryan Knox
9/27/2011
#1
请查看 Jacob Ehn 的博客文章在 TFS 2010 中自动合并工作项。他编写了一个插件，可以从codeplex下载。它将自动关联与合并的变更集关联的工作项。因此，当您合并到 Main 或 Release 时，工作项将与这些分支中的变更集相关联，并且这些工作项将包含在基于这些分支的生成的生成报告中。该插件非常易于部署。
评论
2赞
andreadi
1/11/2012
有人用过这个插件吗？你能提供一些反馈吗？它是否像它所说的那样工作？有什么问题吗？
2赞
Ed Blankenship
9/28/2011
#2
另一个选项是，您可以构建一个自定义工作流活动，该活动可以在生成期间运行，该活动可以遍历通常关联的每个变更集的合并历史记录。它本质上是从一组已知的关联变更集开始遍历树。我更喜欢这种方法，因为您可以让您的开发人员担心只需要将工作项与原始变更集相关联，而不必也使用合并变更集来执行此操作。这还允许你避免部署自定义工作项策略，如 Bryan 在其建议中所述。
如果您想在以下位置与我联系，我可能会提供一些示例代码来帮助您开始遍历合并历史记录树 http://www.edsquared.com
评论
0赞
pantelif
9/28/2011
你好艾德，这听起来很有趣。在门控值机模式下是否可以使用它？在此方案中，始终只有一个签入。此签入超出了代理范围，它基本上是最后发生的事情（在它发生之前，您不知道关联变更集的 ID）
0赞
harman_kardon
9/28/2011
最重要的是 - 我们的问题是相互关联的，我在这 stackoverflow.com/questions/7555028/ 上取得了一些进展...... - 希望它会有所帮助？！
0赞
Ed Blankenship
9/28/2011
嗨，Pantelif - 门控签入版本将是我不相信这会起作用的地方。通常会有另一个生成定义与封闭签入生成定义一起创建，这些定义将创建使用的“官方”生成。我通常使用与相应的 Nightly 构建类似的东西。
评论