TFS工作项目<->构建协会的最佳实践

Question

我们最近通过的特性分支的概念，我们的大项目之一，以分隔上可以相互独立地完成了产品的不同方面的工作。

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

• 从“主”，什么功能应该是
• 一个新的团队在项目门户后适当命名的一个分支，包含将在功能
• 构建定义来验证签入对源的分支工作的人

主要的一点，我想看到这里讨论的是AB出构建定义。目前，它们中的每一个都被设置为门控签入。

接下来的问题是：什么是对工作项目，以构建关联的最佳做法？

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

如果我用这些临时建立工作项目联系起来，我会失去后，当该功能执行结束的跟踪能力。与此同时，我刚刚发现那gated checkins always associate work items, regardless of what is configured in the build definition。

禁用工作项目与功能分支的集成（在这种情况下，也可以将它们从门控转换为持续集成），并在主版本中启用它，以便可以在主要产品线中跟踪这些功能？或者，也许这应该只对发布版本定义有效，以便我们可以找出在某个版本上集成了什么？对于那些追随冲刺/特征概念的人，你如何处理这种情况？你也有每个分支的构建？

更新：

我刚刚发现在this question类似（但不完全一样我想要的）东西。那里的答案导致我到a plugin that automatically associates work items on merge checkins。这应该提供很好的可追溯性，所以我想我会给它一个镜头。

还是想听听你的想法是什么在关于此方案中的构建。

Answer 1

你IMO接近这一错误。您不应该担心关联Build和WI，而应该将Changesets和WI关联起来。当您的开发人员检查功能部门的更改时，应确保他们将其链接到相关的WI（s）。您甚至可以通过签入政策强制执行此操作。

现在，如果你想检查，在未来的功能查看与之相关联的所有更改，你可以通过检查提供无线网络，并看着所有链接的变更。即使您删除分支，所有更改集仍然可用。