19

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

ALM Rangers 基本分支结构

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

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

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

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

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

PS 问题“如何确定与 TFS 2010 中的源分支关联的工作项？ ”接近于问同样的问题，但不完全是。

4

2 回答 2

9

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

于 2011-09-26T20:50:43.143 回答
2

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

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

于 2011-09-28T00:27:13.990 回答