TFS 工作项<->建立关联最佳实践

Question

我们最近在我们的一个更大的项目中采用了功能分支的概念，以分离产品不同方面的工作，这些工作可以彼此独立完成。

对于每个所谓的功能，我们正在创建以下内容：

• 'main' 的一个分支，恰当地以功能应该是什么命名
• 项目门户中的新团队，包含将从事该功能的人员
• 根据分支上的源验证签入的构建定义

我希望在这里讨论的要点是关于构建定义。目前，它们中的每一个都设置为门控签到。

那么问题是：将工作项与构建相关联的最佳实践是什么？

在我们的例子中，这些功能分支应该是一次性的：我们希望能够在功能完成后删除这些构建/分支/团队，但仍然能够在整个产品生命周期中跟踪它们。

如果我将工作项与这些临时构建相关联，我将在功能实施结束后失去跟踪功能。同时，我刚刚发现gated checkins always associate work items, regardless of what is configured in the build definition。

是否可以禁用与功能分支的工作项集成（在这种情况下也将它们从门控集成转换为持续集成）并在主构建中启用它，以便可以在主产品线中跟踪这些功能？或者也许这应该只为发布版本定义启用，以便我们可以找出某个版本中集成的内容？对于那些遵循 sprint/feature 概念的人，你如何处理这种情况？您是否也为每个分支构建了一个版本？

更新：

我刚刚在this question 中发现了类似的东西（但与我想要的不完全一样）。那里的答案将我引向a plugin that automatically associates work items on merge checkins。这本身应该提供很好的可追溯性，所以我想我会试一试。

仍然想听听您对这个场景中的构建有什么想法。

Answer 1

您正在接近这个错误的 IMO。您不应该担心关联构建和 WI，而是关联变更集和 WI。当您的开发人员签入功能分支中的更改时，您应该确保他们将这些更改链接到相关的 WI。您甚至可以通过签到政策强制执行此操作。

现在，如果您想在将来检查该功能以查看与其相关的所有更改，您可以通过检查功能 WI 并查看所有链接的变更集。即使您删除了分支，所有变更集仍然可用。