具有两个不同发布周期的Hg工作流程

Question

我们即将更改我们的发布管理工作流程，作为从CVCS（TFS）升级到DVCS（Hg）的一部分。在办公室讨论了一些相当激烈的事情，我很乐意得到一些意见。

一些背景

我们是一家小型/中型软件公司（约25名开发人员），拥有长寿命产品。我们试图将发布周期保持在较低水平 - 每次冲刺后发布一次（每月一次）。在TFS中，我们为每个新版本创建一个分支。最后两个版本支持错误修复。

我们当前的分支模型（TFS）

--trunk
  --release200 //and older, not supported anymore
  --release201
  --release202

在这些分支之上，我们有不同的开发者分支（如果需要）。一些团队分支和一些功能分支。

“小”错误在版本202上得到纠正并合并到主干。在版本201上更正了严重错误，并合并到版本202和主干。

我们不支持的是旧版本的错误修复。

新工作流程

有些客户并不关心新功能，而是需要更稳定的版本。因此，我们正在考虑提供两个轨道 - 一个带有补丁的长期版本，另一个带有更频繁的功能更新。 我们一直在考虑拥有这样的分支......

（Hg）的

--default
  --RC
  --Release
  --StableRelease200
  --StableRelease210

这些都是中央Hg存储库中的命名分支。这些分支中的每一个都连接到CI机器。从开发人员的角度来看，将会在这个问题的范围之外开发分支（hg克隆）。

有些客户会使用Release发布的版本，其中一些来自StableReleaseX。

默认：所有新功能开发都合并到此分支中。

RC：当PBI完成/结束sprint时，默认会合并到此分支进行内部测试。此分支中发现的错误也在此处更正。当QA认为它足够稳定时，该分支将合并到Release中。如果某些开发人员需要继续处理新功能，他们可以在默认情况下执行此操作。

发布：此处的发布顺序发生，只有最后一个发布会支持错误修复。从技术角度来看，版本标有Hg标签。在sprint期间在客户站点发现的严重错误将在此处修复并合并回默认值。

StableReleases：每半年左右（由管理层决定），Release将合并到一个新的StableRelease分支。在其生命周期中，此处不会添加任何新功能。此处找到的错误将在此处修复，并一直合并为默认值。可能会同时支持两个StableReleases - 当前的一个和后一个。旧的分支机构将关闭。

一些问题

• 关于工作流程的一般意见？您是否有任何支持两个不同的并发“发布曲目”的经验？一个频繁发布，另一个发布长版，只修复错误？
• 我们一直在考虑将分支作为命名分支，以使开发人员更容易（一个VS，一个拉等）。或者......你觉得它会更难吗？更容易使用单独的克隆（大多数开发人员使用DVCS的经验有限）？

Answer 1

请参阅Mercurial wiki中的wiki page on "standard" branching。您会很高兴地了解到它描述的工作流程与您建议的工作流程非常相似！ :-)所以是的，有两个像这样的发行曲目非常有用。

至于使用命名分支而不是克隆，那么我们对Mercurial项目本身使用的两个名称分支非常满意。我们曾经有两个存储库，但现在有一个default和一个stable分支。

有些人更喜欢服务器上的单独克隆的原因是它可能会提供更好的概述：“分支”然后显示为单独的存储库。