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

Question

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

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

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

Answer 1

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

从本质上讲，这需要你的基本Dev＆lt; - ＆gt;主要＆lt; - ＆gt;发布模型，然后再添加一层间接。 Hot Fixes在层次结构的Release端获得自己的分支，因此他们的开发+测试不会破坏Main中发生的普通QA循环，也不会污染Release的神圣性。您可以在PDF的第7页上看到可视化插图。

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

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

对于团队发展战略的更长，更理论的观察＆amp;他们在TFS中的实施，查看模式和文件中的论文。实践组： http://msdn.microsoft.com/en-us/library/bb668991。 ASPX http://branchingguidance.codeplex.com/Wiki/View.aspx?title= HTML