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

Question

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

如果需要开发热修复程序，production.

• Once中只有一个版本的

1. 将部署到生产中。热修复是针对特定的高严重缺陷，而不是引入新的功能。热修复的代码更改应该反向集成到其他branches.
2. Before，为了新的特性发布，它必须经过QA周期。
3. 在发布给QA之后，需要大量的时间来测试应用程序。在第一个QA周期中，如果QA打开了20个缺陷，那么需要在下一个版本中修复它们，因为QA没有任何需要测试的特性。如果QA团队然后重新打开，比如说10个缺陷，那么在QA的下一个版本中，他们只希望修复这10个缺陷。没有其他缺陷或任何新特性。下一个特性发布只能在缺陷计数为0(或者某些缺陷被确定为不固定或增强等)之后才能发布。
4. 由于QA周期需要时间，在此期间开发无法停止。应该继续为下一个特性发布开发新的功能。

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

Answer 1

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

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

您是否严格要求发布分支(Es)代表生产的准确快照(即在要发布的签入与部署之间存在1:1的关系，以及/或每个部署创建的单独的发布分支)？如果没有，那么您甚至可能不需要hotfix分支--直接在发行版中做修补程序。这一点在本文件前面的“基本”战略中有涉及。

无论如何，一定要阅读整个文档集。时间不长，但从现实世界的实现中提取了很多发现。( "VSTS游骑兵“主要由MVP和其他现场顾问组成)

要对团队开发策略及其在TFS中的实现进行更长时间的理论研究，请参阅模式与实践组：http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html的论文。