7

我需要帮助设置 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”而不在此期间完成任何“开发”项目？

4

2 回答 2

4

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

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

于 2011-08-16T03:25:25.300 回答
2

问题：如果在“开发”项目完成之前创建了“版本 B”，则需要“版本 A”的“修补程序”，我如何将“修补程序”从“版本 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 类似的挑战。一个月的质量保证周期是一个棘手的问题。

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

  1. 指导：Scrum 团队的分支策略- Martin Hinshelwood 2010.04.14 - Scrum 团队通过 2 个 sprint 工作时基本“发布分支”策略的出色演练（带有很棒的图表）。
  2. Scrum 分支- Bill Heyes (ALM Ranger) 2011.01.18 - 优秀的 Scrum 团队图和扩展分支。
  3. 并行功能团队在开发中处理多个版本。每月发布到生产。- Bill Heyes 2011.01.14 - 非常类似于我们的分支场景（3 个 Web 开发团队 + 1 个 Prod 环境）。指导是团队分支 + 发布分支。

享受！-泽潘

于 2011-08-18T23:52:18.703 回答