version-control - 支持长QA(系统测试)周期的TFS分支模型

Question

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

该应用程序的一个版本将永远存在于生产环境中。

一旦部署到生产环境，如果需要，可能需要开发修补程序。热修复仅针对修复特定的高严重性缺陷而不是引入新功能。修补程序代码更改应反向集成到其他分支。

在为新功能发布投入生产之前，它必须经过 QA 周期。

发布到 QA 后，测试应用程序需要大量时间。在第一个 QA 周期中，如果 QA 发现 20 个缺陷，则需要在下一个版本中修复这些缺陷以进行 QA，而无需再测试任何功能。如果 QA 团队然后重新打开说 10 个缺陷，那么在下一个 QA 发布时，他们只希望修复这 10 个缺陷。没有其他缺陷或任何新功能。下一个功能发布只能在缺陷计数为 0 后发生(或某些缺陷被决定不修复或增强等)。

由于 QA 周期需要时间，在此期间开发不能停止。应继续为下一个功能版本开发新功能。

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

Answer 1

听起来您是 TFS 分支/合并指南中“标准”策略的完美候选人:http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

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

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

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

要对团队开发策略及其在 TFS 中的实现进行更长时间、更理论化的研究，请查看 Patterns & Practices 组的论文:
http://msdn.microsoft.com/en-us/library/bb668991.aspx
http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html