支持长 QA（系统测试）周期的 TFS 分支模型答案

【问题标题】：TFS branching model to support long QA (system testing) cycle支持长 QA（系统测试）周期的 TFS 分支模型
【发布时间】：2010-11-15 10:29:42
【问题描述】：

假设您有一个应用程序。此应用程序将进行 QA 测试并部署到生产中。应用程序生命周期存在一些限制。

只有一个版本的应用会在生产中存在。
一旦部署到生产环境，如果需要，可能必须开发热修复程序。 Hot-fix 的目标是修复特定的高严重性缺陷，而不是引入新功能。热修复代码更改应反向集成到其他分支。
在为新功能发布重新投入生产之前，它必须经过 QA 周期。
在发布给 QA 后，需要花费大量时间来测试应用程序。在第一个 QA 周期中，如果 QA 发现 20 个缺陷，则需要在下一个版本中为 QA 修复这些缺陷，而无需测试更多功能。如果 QA 团队随后重新打开说 10 个缺陷，那么在 QA 的下一个版本中，他们只希望修复这 10 个缺陷。没有其他缺陷或任何新功能。下一个功能发布只能在缺陷计数为 0 后发布（或某些缺陷被确定为未修复或增强等）。
由于 QA 周期需要时间，在此期间开发不能停止。应继续为下一个功能版本开发新功能。

您将如何设置您的 TFS 分支模型。

【问题讨论】：

【解决方案1】：

本质上，这需要您的基本 Dev Main Release 模型，然后再添加一层间接。热修复在层次结构的发布端有自己的分支，因此他们的开发+测试不会破坏 Main 中发生的普通 QA 周期，也不会污染发布的神圣性。您可以在 PDF 的第 7 页上看到直观的插图。

您是否有一个铁定要求，即发布分支代表生产的精确快照（即签入与发布和部署之间存在 1:1 的关系，和/或每个部署创建一个单独的发布分支）？如果没有，那么你甚至可能不需要 hotfix 分支——直接在 Release 中做 hotfix。这在文档前面的“基本”策略中有所介绍。

无论如何，请务必阅读整套文档。它不长，但从现实世界的实现中提炼出很多发现。（“VSTS Rangers”主要由 MVP 和其他现场顾问组成）

要对团队开发策略及其在 TFS 中的实施进行更深入、更理论的研究，请查看模式与实践小组的论文： http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html

【讨论】：

虽然我在问这个问题之前已经阅读了 TFS 分支指南，但我仍然将其标记为答案。我使用的是 Dev-MAIN-Release 模型，具有多个 Dev 功能分支、一个 MAIN 分支和多个发布分支。准备就绪后，每个发布版本都将从 MAIN 分支，之前的发布分支将被废弃。