Question

我们的开发小组为我们正在开展的每个项目都有一组mercurial存储库。每个存储库都有几个命名分支：开发分支和最后两个稳定版本分支。换句话说，历史树看起来像：

dev --- dev --- dev --- dev --- dev
          \               \
           \               V2 --- V2
            \
             V1 --- V1 --- V1 --- V1

我们将此设置绑定到Jenkins CI服务器，以便每次提交到存储库时，挂钩都会告诉Jenkins轮询存储库，然后启动关联的Jenkins项目并通过XMPP通知用户结果。这部分工作正常。

我们希望使用Jenkins进行发布构建，并将代码审查和QA流程的步骤添加到发布管道中。我的一个想法是设置每个存储库的镜像，作为一种“促销”的回购。当提交到其中一个开发存储库的变更集成功构建并通过代码审查和QA时，它将被导出到补丁并导入到该存储库的升级版本中。除非我弄错了，否则这样做的好处几乎可以保证，当我们的发布经理进行发布版本时，他正在构建的源代码树可以保证构建并通过质量控制。

我的问题有三方面：1）我是否完全误入歧途？ 2）有更好的方法吗？ 3）是否有任何Hg插件可以帮助促进不需要重做基线存储库或开发人员必须更改其日常使用的进程（我相信Mercurial队列需要这样，但我可能是错的）。

非常感谢和节日快乐！

Answer 1

如果您更喜欢独立回购拉式，可能更有用：

当变更集提交到其中一个开发存储库时成功构建并通过代码审查和QA

你只是从“升级”回购（创建为DEV的克隆）拉出来并且在FAILed测试之后不要拉动：在这种情况下，促销回购的提示将始终处于良好状态

你可以使用相同的repo，但是有一个特殊的“Good”分支，你将在测试后合并“Dev”分支 - 在这种情况下良好的状态意味着好的HEAD
您可以在单个存储库中使用单一开发分支，并使用书签标记最新传递的测试变更集

测试回购的简短脏样本（具有3个变更集和一些开发者回购的中央回购），r3（此刻提示）被宣布为最新商品

>hg bookmark -i Good

没有-r说明符，因为它是“工作目录的父版本上的书签”（是的，我有基础仓库的工作目录，可能不需要）和-i（不活动）以防止推送书签的自动移动。

从开发者那边推送到Base之后

>hg log
changeset:   4:95c6cb29d14f
tag:         tip
summary:     Small fix of new feature

changeset:   3:3b0236acae9f
bookmark:    Good
summary:     New changes

提示是r4，但书签“好”仍然是r3（并且hg clone URL#Good将克隆包含r3的回购）

经过（通过）测试

>hg bookmark Good -r 4
moving bookmark 'Good' forward from 3b0236acae9f

并记录确认

>hg log
changeset:   4:95c6cb29d14f
bookmark:    Good
tag:         tip
summary:     Small fix of new feature

changeset:   3:3b0236acae9f
summary:     New changes

Answer 2

这对我来说似乎完全合情合理。您可以使用以下方法简化促销流程：

cd Release-Repo
hg pull -r V2 Development-Repo

将所有更改提升到修订版V2（例如）到提升的存储库中。然后，您可以在Jenkins中创建一个项目，以检测该repo的更改并执行发布。

Mercurial命名分支+ CI版本的多个存储库

2 个答案: