我们最近在一个较大的项目中采用了功能分支的概念，将产品的不同方面的工作分开，可以彼此独立完成。
对于每个所谓的功能，我们创建以下内容：
我想在这里讨论的要点是关于构建定义。目前，他们每个都设置为门禁签到。
接下来的问题是：将工作项与构建关联起来的最佳做法是什么？
在我们的案例中，这些功能分支应该是一次性的：我们希望以后能够在功能完成时删除这些构建/分支/团队，但仍然能够在整个产品生命周期中跟踪它们。
如果我将工作项与这些临时版本相关联，我将在以后功能实现结束时丢失跟踪功能。与此同时，我发现了gated checkins always associate work items, regardless of what is configured in the build definition。
是否可以禁用与功能分支的工作项集成（在这种情况下还将它们从门控转换为持续集成）并在主构建中启用它，以便可以在主产品线中跟踪这些功能？或者这可能只对Release版本定义启用，以便我们可以找出某个版本上集成的内容？对于那些遵循冲刺/功能概念的人，您如何处理这种情况？你是否也有每个分支的构建？
更新
我在this question找到了类似的东西（但不完全像我想要的东西）。那里的答案让我a plugin that automatically associates work items on merge checkins。这应该提供很好的可追溯性，所以我想我会试一试。
仍然希望听到您对此方案中的构建的看法。
答案 0 :(得分：2)
你正在接近这个错误的IMO。您不应该担心将Builds和WI关联起来，而应该关联Changesets和WI。当您的开发人员在功能分支中签入更改时，您应该确保他们将它们链接到相关的WI。您甚至可以通过签到政策强制执行此操作。
现在，如果您希望将来检查该功能以查看与其相关的所有更改，您可以检查功能WI，并查看所有链接的变更集。即使您删除了分支，所有变更集仍然可用。