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

Geo*_*eng 27 mercurial dvcs release-management

这是我早期的问题 "如何使用mercurial管理并发开发" 的表亲问题,该问题涵盖了各个开发人员的工作流程.这个问题的答案实际上会影响开发人员工作流程的选择.

这不是一般的"版本管理最佳实践"或CI问题,因为它已经被问很多次有很好的答案,而且也可用来消磨时间的文学庞大的身躯.

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

最明显和最主要的答案应该是稳定的/默认的,这完全由@Steve Losh 的漂亮博客覆盖,并且在他的回答中更简洁.它简单而有效.

这种设置的一个突出例子是hg本身.hg使用更多的存储库进行主动开发,但是出于管理目的,一切似乎都包含在主repo的stable/default分支中.

hg设置实际上表示稳定/默认的变体,或者更确切地说是扩展版本:分支克隆.我在回答关于命名分支与多重回购的问题时描述了这个过程(来自@Martin Geisler的另一个很好的答案).在我的回答中我忘记提到的是分支克隆如何为开发人员工作流程工作:如果你需要修复分支的bug,你可以hg clone <main repo>#<branch>但不是分支克隆,因为你的变更集仍然会回到主仓库并推出自动分支克隆.当然,您可以选择不克隆并仅hg update <branch>在主克隆中,但是大多数使用单独克隆的参数(尤其是独立构建)都适用于此处.

现在回到问题:是否有其他方法适合不同的现实场景？例如,传统的主要/次要/补丁发布周期与版本之间的长时间推移可能需要完全不同于快节奏,即用即发的Web应用程序.如果您愿意,还请评论稳定/默认和分支克隆方法.

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

感谢您的所有投入!

neu*_*uro 8

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

对于开发,我们使用的东西似乎是你所谓的稳定/默认工作流程的变体(当然,所有内容都通过执行工作流的命令,我之后称之为myw):

我们有一个中央服务器,它拥有我们所有的存储库
我们在这台服务器上有每个项目的中央稳定克隆
我们有一个每个项目的中央开发克隆,它是此服务器上的stable的克隆
最初,可以在服务器和本地(在开发人员计算机上)为项目myw create theproject创建稳定/ dev克隆
当有人必须开发新功能时,他可以myw clone theproject dev mygreatfeature:
- 将服务器上的项目dev repo 克隆为mygreatfeature
- 克隆本地克隆回购mygreatfeature
- 做了很多有用的事情,比如更新hgserver/hudson ci ......
他可以myw fetch dev和myw fetch stable任何时间
完成该功能后,将其合并回本地开发克隆,将合并后的结果推送到中央开发克隆并关闭存档一段时间的中央克隆:myw close theproject mygreatfeature

所有这一切都很好,非常顺利.我们首选克隆到命名分支,因为它很容易真正关闭一个特征分支,并且当时mercurial"命名分支"部分看起来像"正在进行中".

工作流程的发布部分目前基本完成:

"release master"从中央dev clone 获取到他的本地dev clone.
他从中央稳定克隆中取出到他当地的稳定克隆.
他从当地获取稳定的克隆是在他在当地的变化开发克隆.
他检查一切,如果没问题,那就这样做myw release 1.2.3_RC2:
- 用1.2.3_RC2标记
- 推动集中式项目稳定克隆.
- 这实际上是一个候选版本,我们的CI服务器和我们的核心测试人员将对其进行一段时间的测试.
这些测试发现的错误修复在本地稳定克隆上修复,并推送到集中稳定克隆.
当它好的时候,"发布大师"正式发布: myw release 1.2.3

这很有效,即使我们需要改进一些命令来平滑过程.其中一个主要缺点就是很多克隆:)

对于旧版本的管理,我们目前已为每个主要版本提供了稳定完成的克隆.由于没有很大的需要向后移植许多功能,我们只需要挑选一些非常糟糕的错误hg transplant(顺便说一句,扩展性很强).

我们已经使用了大约一年,我们当然需要改进我们的自制命令,特别是对于发布部分:)

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

由于我们将要维护越来越多的版本,我正在努力改进"旧版本,但必须支持"管理部分.读Bert F评论,我读过这篇很棒的文章.有很好的想法,很好地解释了一个非常好的计划!似乎有人已经将他的工具git-flow的hg版本实现为hg-flow.需要考虑的事情.我喜欢发布和修补程序分支.而且我认为用工具强制执行这样的工作流程是非常强制性的!

MY2C