2

我们最近从 Gemini 过渡到 TFS 以进行应用程序更改控制。TFS 有一个方面我无法理解 - 缺少每个工作项将在.

在 Gemini 中，每个功能请求、增强、错误等都可以用版本号标记。如果该字段留空，则该项目是“未计划的”，即在积压中。每个版本都可以标记为已发布或未发布。然后可以创建报告，列出每个发布版本中解决的问题，即发行说明，以及未来版本中要解决的问题，即路线图。我对此非常满意！

现在在 TFS 中我找不到任何内置的版本概念。似乎有两种表示版本的方法：

作为迭代树中的父项，例如

版本 1.0.0

  • 冲刺 1
  • 冲刺 2
  • ETC

版本 1.1.0

  • 冲刺 3
  • 冲刺 4
  • ETC

作为工作项树中的父项，例如

版本 1.0.0

  • 要求 1
  • 要求 2
  • ETC

版本 1.1.0

  • 要求 3
  • 错误 4
  • ETC

后一种方法看起来更好，因为它允许同时处理版本（例如，主要版本将与错误修复版本同时处理）。

那么按版本管理工作的推荐方法是什么？

最后，由于版本属性实际上并不存在于工作项本身中，是否可以就每个版本中解决的问题进行报告？

4

3 回答 3

1

现在我将使用迭代路径来捕获版本号。这不适合同时管理不同版本的开发，但我们正试图摆脱这种做法（即在处理下一个版本的同时对过去版本进行多个错误修复）并采用较短的发布周期，即更线性的路径，所以也许这是一件好事。

早些时候我认为区域路径可能是放置版本的好地方，但它太有价值了，因为它可以将一个巨大的应用程序分割成多个部分以牺牲版本控制。

于 2013-08-01T08:39:31.810 回答
1

1. 标签(TFS 2013+) 是附加元数据（例如 build#）的最简单方法。（与上述相同。）

2. CMMI Process Template > Requirement and Bug Work Item Types 有一个“Integrated In”字段，该字段链接到 TFS 构建，以便从需求直接关联到构建# [到相关代码更改] [到相关测试用例 [到相关测试结果] ]。请注意，您必须从保留的 TFS 构建系统构建（尚未删除）中进行选择。随着时间的推移或如果您使用不同的构建系统，此硬参考下拉列表会显着限制此字段。（这和构建版本控制是完全不同的讨论 :-)。）构建 CMMI 模板字段自 TFS2010 以来一直存在。

3.在您的用户故事和错误工作项中创建一个自定义字段。BuildImplementedIn 或类似名称的字段可以。在 TFS 中创建自定义字段并不难。如果您还不是管理员，您将需要团队项目管理员或可能的 TPC 管理员来进行自定义。

ps：抱歉回复晚了。我发布了这个答案，以防其他人仍然有相同或相似的问题。

于 2016-12-06T06:56:24.433 回答
0

您可以使用区域字段。

我们使用该名称作为产品名称（我们维护多个产品），然后版本进入故事的描述，但您可以使用区域字段作为版本。

另一种可能性是在产品待办列表项的顶部使用标签。

顺便说一句，我同意 TFS 缺少一些重要字段（自定义字段）

于 2013-07-23T18:03:07.210 回答