使用分支时如何确定特定 TFS 构建中修复的工作项？
我们已开始在 TFS 2010 中使用以下分支结构：
到目前为止，所有更改均已在开发分支，所有签入均已与任务工作项关联。这些任务都是 Bug 或产品待办事项列表项工作项的子项。每个 CI 构建都会针对特定的变更集触发，并且变更集与一个任务相关联，因此我们可以手动找出刚刚构建了哪个 Bug 或 PBI。
在代码构建、部署到我们的集成环境并由开发人员测试一段时间后，它被合并到主分支。显然，可以同时将多个变更集合并到 Main 中。如果我们在此之前不手动触发每晚构建，则每晚构建将构建此代码。 QA 稍后会将这些“主要”版本之一部署到 QA 环境。
自上次 QA 部署以来，主分支可能已经有多个版本。这些构建与“合并”变更集相关联，而不是与与任务关联的原始变更集相关联。
如何确定给定“主”构建已解决的一组任务，该构建是与任务工作项关联的分支不同的分支的构建？
一旦我们开始准备发布，我们很可能需要在发布分支中进行更改，这将使事情变得更加复杂，因为我们将从发布合并回主分支，并且发布变更集将与任务关联。然后这些将合并到开发中，让生活变得更加有趣！
PS问题“如何确定与 TFS 2010 中的源分支关联的工作项？”几乎是在问同样的问题，但又不完全是。
We have begun using the following branching structure in TFS 2010:
All changes so far have been performed in the Development branch, and all check-ins have been associated with a Task work item. The Tasks are all children either of a Bug or a Product Backlog Item work item. Each CI build is triggered for a particular changeset, and the changeset is associated with a Task, so we can manually figure out which Bug or PBI was just built.
Some time after the code has been built, deployed to our Integration environment and tested by the developer, it is merged to the Main branch. Obviously, more than one changeset may be merged to Main at the same time. The nightly build will build this code if we don't manually trigger the nightly before that. QA will later deploy one of these "Main" builds to the QA environment.
There may have been several builds of the Main branch since the last time QA have deployed. These builds are associated with the "Merge" changesets, not with the original changesets which were associated with the Tasks.
How do I determine the set of tasks which have been addressed by a given "Main" build, which is a build of a different branch than the one associated with the Task work items?
Once we've begun preparing for a release, we may very well need to make changes in the Release branch, which will complicate things further since we will be merging back from Release to Main, and the Release changesets will be associated with Tasks. Those will then be merged to Development, making life even more interesting!
P.S. The question "How to determine the work items associated with a source branch in TFS 2010?" comes close to asking the same question, but not quite.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看 Jacob Ehn 的博客文章 自动合并 TFS 2010 中的工作项。他编写了一个插件，可以从 codeplex 下载。它将自动关联与合并的变更集关联的工作项。因此，当您合并到 Main 或 Release 时，工作项将与这些分支中的变更集相关联，并且工作项将包含在这些分支的构建报告中。该插件非常容易部署。
Take a look at Jacob Ehn's blog post Automatically Merging Work Items in TFS 2010. He wrote a plug in that can be downloaded from codeplex. It will automatically associate the work items that were associated with the merged changesets. So when you merge to Main or Release the work items will be associated with the changesets in those branches, and the work items will be included in the build reports for builds off of those branches. The plug-in is super easy to deploy.
另一个选项是您可以构建一个自定义工作流活动，您可以在构建期间运行该活动，该活动可以遍历通常关联的每个变更集的合并历史记录。它本质上是从一组已知的相关变更集开始遍历树。我更喜欢这种方法，因为您可以让您的开发人员担心只需要将工作项与原始变更集关联起来，而不必同时使用合并变更集来执行此操作。这还允许您不必像 Bryan 在他的建议中所述那样部署自定义工作项策略。
如果您想通过 http://www 与我联系，我可能有一些示例代码可以帮助您开始遍历合并历史记录树。 edsquared.com
The other option is that you can build a custom workflow activity that you can run during your build that can traverse the merge history for each of the changesets that would normally be associated. It's essentially walking the tree starting with a known set of associated changesets. I would prefer this approach since you can let your developers worry about only needing to associate work items with the original changesets instead of having to also do it with merge changesets as well. This also allows you to get around having to deploy a custom work item policy as Bryan described in his suggestion.
I might have some sample code to get you started with traversing the merge history tree if you want to contact me at http://www.edsquared.com