Team Foundation：多发布结构答案

【问题标题】：Team Foundation: Multiple release structureTeam Foundation：多发布结构
【发布时间】：2011-08-16 02:48:17
【问题描述】：

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

目前的场景如下，我们的应用是一个SaaS，我相信我们需要同时有多个“Release”分支。

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

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

到目前为止，一切都很好。

问题出现了，QA 周期大约需要一个月，因此在此期间，我们希望我们的开发人员为“Release B”开发新的“Service Pack”和“Development”项目，这也将有它的拥有“Service Pack”、“Hotfix”和“Release B”分支。

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

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

【问题讨论】：

标签： tfs branching-and-merging hotfix

【解决方案1】：

查看来自http://blog.hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/ 的图形并阅读整个博客条目：

您的“开发”项目在图中称为“Sprint 1”和“Sprint 2”...请注意 Sprint 是如何与 Release 隔离的——除非通过合并，否则您无法访问它们。

【讨论】：

我不会将我们的开发环境描述为 SCRUM，主要区别在于我们不会在循环结束时合并来自开发分支（或 SCRUM 中的“Sprint”）的更改。另外，在创建第二个版本之后，如何将热补丁从一个版本应用到另一个版本。
使用上图，将热补丁应用到 RTM 分支。然后将其合并到发布分支。再次合并到主分支。一旦它在主分支中，你可以通过两种方式合并它——到你的开发分支（上面的“sprint n”分支），或者到你的下一个发布分支。
RE：评论#1：将单词“Sprint”替换为“Version”或“Dev”或其他术语。 “Sprint”这个名称意味着一个较短的发布节奏，但该图也适用于较长的发布周期。在 Martin 的图表（上图）中，我希望 RTM 分支保持纯只读（基本上是“发布给制造（Web for SaaS）”的不可变标签）。在发布分支（这是您在 TFSBranchingGuideIII 标准计划中的服务分支）中制作修补程序。
德拉特。发评论太快了。在 Martin 的图表（上图）中，我希望 RTM 分支保持纯只读（基本上是“发布给制造（Web for SaaS）”的不可变标签）。在发布分支（这是您在 TFSBranchingGuideIII 标准计划中的服务分支）中制作修补程序。在 Release1 分支中完成修补程序后，它将通过 Main 合并到“Dev2”。如果您需要在不经过 Main 的情况下从 Release1 安全地到达“Release2”分支（因为 Main 还有其他版本），那么请考虑无根据的合并（并非常仔细地计划以降低合并冲突的风险！！！）。

【解决方案2】：

问题：如果在“开发”项目之前创建“版本 B” 完成，然后需要“Release A”的“Hotfix”，我该怎么做将该“修补程序”从“版本 A”传播到“版本 B”，而无需拿起任何在同时？

简短回答：对于所描述的特定场景，我相信您可以安全地从 Release A 合并到 Main，然后备份到 Release B。（是的，这与 Geoffrey McGrath 在在 8 月 16 日发表评论。）通常，在创建分支后，您不会从 Main 到发布分支进行任何 FI 合并，但如果您可以确认 Main 中存在的唯一更改是您的修补程序，那么合并应该可以安全地实现您的目标。然而这是基于一个非常可疑的假设，即自从“发布 B 服务”分支以来，您有一个干净的 Main 分支，没有其他任何东西并入 Main。在继续之前非常仔细地验证这个假设！

Dirty Main 解决方法 - 挑选或毫无根据的合并： 如果 Main 中有其他更改，您可以挑选将特定修补程序从 Main 合并到“Release B Service Pack”。另一种选择是从“Release A Servicing”直接合并到“Release B Servicing”，从而绕过 Main 中的任何其他更改。（您仍然需要通过 main 合并此修复程序，以便开发分支获得修复程序。）请注意，cherry-pick 合并和无基础合并比常规合并具有更高的风险（这可能足够棘手）。对于没有更好解决方案的特定场景，它们仍然是有效的选择。

Meta-answer#1： 我发现绘制图表可以帮助我跟踪从原始分支到最终目的地的变化。 Cherry-pick 没有任何特殊符号，但无根据的合并可以是带虚线的箭头。如果它在纸上有效（并且您考虑了与 Main 的所有其他分支交互），那么它应该有效。

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

仅供参考：

我的团队从事一些 SOA（面向服务的架构）项目，这些项目遇到了与 SaaS 类似的挑战。一个月的 QA 周期是一项艰巨的任务。

我非常喜欢 Martin 的文章（足以在下面再次引用它）。还有两篇值得回顾的文章（两篇都有漂亮的图片来补充漂亮的 TFS 分支指南图表）。然而，所有三篇文章都专注于开发分支管理而不是修补程序发布分支管理（与前面答案中的图表相同）。

Guidance: A Branching Strategy for Scrum Teams - Martin Hinshelwood 2010.04.14 - Scrum 团队通过 2 个 sprint 完成基本“发布分支”策略的出色演练（附有精美的图表）。
Branching for Scrum - Bill Heyes (ALM Ranger) 2011.01.18 - 优秀的 scrum 团队图和扩展分支。
Parallel Feature Teams working on multiple releases in development。每月发布到生产。 - Bill Heyes 2011.01.14 - 非常类似于我们的分支场景（3 个 Web 开发团队 + 1 个 Prod 环境）。指导是按团队的分支 + 按版本的分支。

享受吧！ -泽潘

【讨论】：