mercurial - 如何使用 mercurial 进行发布管理？

Question

这是我的 earlier question 的堂兄问题“如何使用 mercurial 管理并发开发”，其中涵盖了单个开发人员的工作流程。这个问题的答案实际上会影响开发人员工作流程的选择。

这不是一般的“发布管理最佳实践”或 CI 问题，因为它一直是 asked many times有很好的答案，并且有大量的文献可以消磨时间。

我只要求 在发布管理的上下文中使用 mercurial 的具体方法 .

最明显和最主要的答案应该是 稳定/默认 ，这被 beautiful blog 彻底覆盖@Steve Losh，更简洁地在 an answer从他那里。它简单而有效。

这种设置的一个突出例子是 hg 本身。 Mercurial 用途 a few more repositories用于积极开发，但出于发布管理目的，一切似乎都包含在 main repo 的稳定/默认分支中.

hg 设置实际上体现了稳定/默认的变体，或者更确切地说是扩展版本:分支克隆 .我在 an answer 中描述了这个过程关于命名分支与多个存储库的问题(来自@Martin Geisler 的另一个 great answer)。我在回答中忘记提及分支克隆如何为开发人员工作流程工作:如果您需要修复分支的错误，您可以 hg clone <main repo>#<branch>但不是分支克隆，因为您的变更集仍将返回主存储库并自动推送到分支克隆。当然你可以选择不克隆而只是hg update <branch>在您的主克隆中，但大多数使用单独克隆(尤其是独立构建)的论点都适用于此。

现在回到问题:还有其他适合不同现实世界场景的方法吗？ 例如，传统的主要/次要/补丁发布周期在发布之间间隔很长，可能需要与快节奏、随用随发布的 Web 应用程序完全不同的工作流程。如果您愿意，还请评论稳定/默认和分支克隆方法。

由于这几乎是一个调查问题，我只能尝试主观地接受“最佳”答案。如果我能得到比我的开发人员工作流程问题更多的答案，那就是。

感谢您的所有投入!

Answer 1

我正在重新设计我们的发布工作流程。所以我找到了这个问题。我决定写下我的经历。物有所值 ...

对于开发，我们使用的东西似乎是您所说的稳定/默认工作流程的变体(当然，一切都通过强制执行工作流程的命令，此后我将它们称为 myw):

我们有一个中央服务器来保存我们所有的存储库

我们在此服务器上的每个项目都有一个中央稳定克隆

我们每个项目都有一个中央开发克隆，它是该服务器上稳定版的克隆

最初，可以 myw create theproject为服务器上的项目和本地(在开发人员计算机上)创建稳定/开发克隆

当有人必须开发新功能时，他可以 myw clone theproject dev mygreatfeature那 :

将服务器上的项目 dev repo 克隆为 mygreatfeature

在本地克隆克隆的 repo mygreatfeature

做了很多有用的事情，比如更新 hgserver/hudson ci ...

他可以 myw fetch dev和 myw fetch stable随时

当功能完成后，他将其合并回他的本地开发克隆，将合并的结果推送到中央开发克隆并关闭存档一段时间的中央克隆:myw close theproject mygreatfeature

所有这些都很好用，而且非常流畅。我们更喜欢克隆而不是命名分支，因为真正关闭功能分支很简单，而且当时的“命名分支”部分看起来像是“正在进行中”。

工作流的发布部分目前基本上是这样完成的:

“发布大师”从中央开发克隆获取到他的本地开发克隆。

他从中央稳定克隆获取到他的本地稳定克隆。

他从本地稳定克隆中获取本地开发克隆中的更改。

他检查一切，如果没问题，做 myw release 1.2.3_RC2那 :

带有 1.2.3_RC2 的标签

推送到中心化项目稳定克隆。

这实际上是一个候选版本，将由我们的 CI 服务器和我们的核心测试人员进行一段时间的测试。

这些测试发现的错误修复在本地稳定克隆上修复并推送到集中式稳定克隆上。

如果没问题，“发布大师”会正式发布:myw release 1.2.3

这很有效，即使我们需要改进一些命令来平滑这个过程。主要缺点之一是有很多克隆:)

对于旧版本的管理，我们目前为每个主要版本都做了一个稳定的克隆。由于不需要向后移植许多功能，我们只需要使用 hg transplant 挑选一些非常糟糕的错误即可。 (顺便说一句，很棒的扩展)。

我们已经使用它大约一年了，我们当然需要改进我们的自制命令，尤其是发布部分:)

主要缺点是您必须为您/您的团队提供一些工具来处理它，因为没有它们可能无法管理，因此我们的 myw自制的一组命令。像往常一样，功能分支不应该持续太久，否则合并会很困难。诸如重构/重命名之类的事情必须在选定的点上完成，否则会给您的团队带来大量合并工作。

由于我们将有越来越多的版本需要维护，我正在尝试改进“旧版本但必须支持”管理部分。阅读 Bert F 评论，我读过这篇很棒的 article .有很好的想法，并且很好地解释了一个非常好的方案!似乎有人将他的工具 git-flow 的 hg 版本实现为 hg-flow .需要考虑的事情。我喜欢 release 和 hotfixes 分支。而且我认为使用工具强制执行此类工作流程是非常必要的!

我的2c