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

Question

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

1. 只有一个版本的应用程序将永远存在于生产中。
2. 一旦部署到生产，如果需要可能需要开发热修补程序。热修复仅针对修复特定的高严重性缺陷，而不引入新功能。热修订代码更改应该反向集成到其他分支。
3. 在开始新产品发布之前，它必须经历QA周期。
4. 发布到QA后，测试应用程序需要花费大量时间。在第一个QA周期中，如果QA打开20个缺陷，则需要在下一个QA版本中修复，而无需再测试任何其他功能。如果QA团队在QA的下一个版本中重新开放10个缺陷，他们只希望修复这10个缺陷。没有其他缺陷或任何新功能。下一个功能发布只能在缺陷计数为0（或者某些缺陷被确定为不固定或增强等）后才会发生。
5. 由于质量保证周期需要时间，在此期间发展无法停止。应该继续为下一个功能发布开发新功能。

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

Answer 1

听起来像是你是从TFS分支/合并的指导意见“标准”战略的一个完美的候选人：http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

在本质上，这需要你的基本开发< - >主< - >发行模型，然后添加一个更多的间接层。修补程序在层次结构的发布侧获得他们自己的分支，以便他们的开发+测试不会中断Main中发生的普通QA循环，也不会污染发布的神圣性。您可以在PDF页面上看到一个可视化的插图。

对于发布分支代表生产的确切快照（即发布和部署的签入与/或每个部署创建单独的发行分支之间存在1：1关系），您是否有一个铁腕般的要求？如果不是那么你甚至可能不需要修补程序分支 - 直接在发布中修复修补程序。这在本文前面的“基本”战略中已有介绍。

无论如何，一定要阅读整套文档。时间不长，但是从真实世界的实现中提炼出很多发现。 （以下简称“VSTS流浪者”主要是由MVP和其他现场咨询的）

对于在团队发展战略&他们在TFS实现更长，更理论上看，自该模式&实践组检查出试卷： http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html