Team Foundation：多个发布结构

Question

我需要帮助设置TFS分支结构。

目前的情况如下，我们的应用程序是一个SaaS，我相信我们需要同时拥有多个“发布”分支。

通过TFS分支指南III，我相当确定我们需要“高级”分支模型。

我们首先建立一个“主”分支，它将立即存放应用程序（我们来自Visual Source Safe）。由此我们将创建一个“开发”分支，暂时不管它。我们还将创建一个新的“Service Pack”，“Hotfix”和“Release A”分支树，它将包含我们当前的一组更改。然后我们将让我们的QA团队分析“Release A”分支，如果它通过，我们将关闭它（只读），并将其合并回“main”。

到目前为止，这一切都很精致。

问题出现了，质量保证周期大约需要一个月，所以在此期间，我们希望我们的开发人员为“​​版本B”开发新的“Service Pack”和“开发”项目，这也是拥有“Service Pack”，“Hotfix”和“Release B”分支。

这意味着我们一次有2个发布分支（当然除非有更聪明的方法）。

问题： 如果在“开发”项目完成之前创建了“版本B”，则需要“版本A”的“修补程序”，如何在不启动的情况下将“修补程序”从“版本A”传播到“版本B”任何在此期间完成的“开发”项目？

Answer 1

查看http://blog.hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/中的图片并阅读整篇博文：

您的“开发”项目在图形中被称为“Sprint 1”和“Sprint 2”...注意Sprint如何与Release分离 - 除了通过合并之外，您无法访问它们。

Answer 2

  

问题：如果在“开发”项目之前创建了“版本B”   完成后，需要“Release A”的“Hotfix”，我该怎么做   将“Hotfix”从“Release A”传播到“Release B”而没有   拿起任何已完成的“开发”项目   其间？

简答：对于所描述的特定情况，我相信您可以安全地从版本A合并到主页，然后再返回到版本B.（是的，这与Geoffrey McGrath在评论8/16。）通常，在创建分支后，您不会从Main到发布分支进行任何FI合并，但如果您可以确认Main中存在的唯一更改是您的修补程序，则合并应该可以安全地实现您的目标。 HOWEVER 这是基于一个非常值得怀疑的假设，即你有一个干净的主分支，没有其他东西已合并到Main，因为“Release B Servicing”已经分支。在继续之前要非常仔细地验证这个假设！

脏主要解决方法 - 采摘樱桃或无基础合并：如果Main中有其他更改，您可以选择将Main中的特定修补程序合并到“Release B Service Pack”。另一个选择是从“Release A Servicing”直接进行“Release B Servicing”的无基础合并，绕过Main中的任何其他更改。 （你仍然需要通过main合并这个修复程序，所以Dev分支得到了修补程序。）请注意，cherry-pick合并和baseless合并比常规合并具有更高的风险（这可能是非常棘手的）。对于没有更好解决方案的特定场景，它们仍然是有效的选项。

元答案＃1：我发现绘制图表有助于我跟踪从原始分支到最终目的地的更改。 Cherry-pick没有任何特殊符号，但是baseless merge可以是带虚线的箭头。如果它在纸上工作（并且您考虑了与Main的所有其他分支交互）那么它应该可以工作。

元答案＃2：如果上述内容尚未完全回答您的问题，那么我建议您阅读http://tfsbranchingguideiii.codeplex.com/discussions论坛并交叉发布此特定请求。 Bill Hays在该论坛中通常非常敏感，您的问题肯定指向TFS分支中的修补程序管理。

---

供参考：

我的团队致力于一些SOA（面向服务的架构）项目，这些项目遇到了与SaaS类似的挑战。一个月的QA周期是一个棘手的并发症。

我非常喜欢马丁的文章（足以在下面再次引用它）。还有两篇值得回顾的文章（两者都有漂亮的图片来增加不错的TFS分支指南图）。但是，所有这三篇文章都关注dev分支管理而不是修补程序发布分支管理（与前面的答案中的图相同）。

1. Guidance: A Branching Strategy for Scrum Teams - Martin Hinshelwood 2010.04.14 - 作为Scrum团队的基本“分支发布”策略的优秀演练，通过2个冲刺（带有很好的图表）。
2. Branching for Scrum - Bill Heyes（ALM Ranger）2011.01.18 - 优秀的scrum团队图和扩展分支。
3. Parallel Feature Teams working on multiple releases in development。每月发布到生产。 - Bill Heyes 2011.01.14 - 与我们的分支场景非常相似（3个Web开发团队+ 1个Prod环境）。指导由Team + Branch by Release发布。

享受！ - Zephan