我们最近已从Gemini过渡到TFS以进行应用程序更改控制。 TFS有一个方面我无法理解 - 缺少应用程序版本的内置概念，每个工作项将在中解决。
在Gemini中，每个功能请求，增强功能，错误等都可以使用版本号进行标记。如果该字段留空，则该项目是“未安排的”，即在待办事项上。每个版本都可以标记为已发布或未发布。然后可以创建报告，列出每个发布版本中解决的问题，即发布说明，以及将来版本中要解决的问题，即路线图。我对此非常满意！
现在在TFS中我找不到任何内置的版本概念。似乎有两种方式来表示版本：
作为迭代树中的父项，例如
版本1.0.0
版本1.1.0
作为工作项树中的父项，例如
版本1.0.0
版本1.1.0
后一种方法看起来更好，因为它允许同时处理版本（例如，主要版本将与错误修复版本同时进行）。
那么按版本管理工作的推荐方法是什么？
最后，由于版本属性实际上并未存在于工作项本身中，是否可以针对每个版本中解决的问题进行报告？
答案 0 :(得分：1)
现在我将使用迭代路径来捕获版本号。这并不适合同时管理不同版本的开发，但我们正试图摆脱这种做法（即在下一个版本中工作，同时处理过去版本的多个错误修复）并采用简短的方法释放周期，即更线性的路径，所以这可能是件好事。
早些时候我认为Area Path可能是放置Version的好地方，但它太有价值了，可以将一个巨大的应用程序分成几部分来牺牲版本。
答案 1 :(得分：1)
<强> 1。标签（TFS 2013+）是附加元数据（如build＃）的最简单方法。 （与上面提到的相同。）
<强> 2。 CMMI过程模板＆gt; 要求和错误工作项类型具有＆＃34;集成In＆＃34;链接到TFS构建的字段，用于直接关联从需求到构建＃[到相关代码更改] [到相关测试用例[到相关测试结果]]。请注意，您必须从保留的TFS Build系统版本（尚未删除）中进行选择。此硬引用下拉列表会在一段时间内显着限制此字段，或者如果您使用其他构建系统。 （那和构建版本控制是完全不同的讨论:-)。）自TFS2010以来，构建CMMI模板字段已经存在。
第3。在您的用户素材和错误工作项中创建自定义字段。 BuildImplementedIn或类似命名的字段都可以。在TFS中创建自定义字段并不难。如果您还不是管理员，则需要团队项目管理员或可能需要TPC管理员进行自定义。
p.s。：对于迟到的回复感到抱歉。我发布了这个答案，以防其他人仍然有相同或类似的问题。
答案 2 :(得分：0)
您可以使用区域字段。
我们将这一个用于产品名称（我们维护多个产品），然后版本会进入故事描述，但您可以使用区域字段进行版本。
另一种可能性是在Product Backlog Item的顶部使用标签。
不过，我同意TFS缺少一些重要的字段（自定义字段）