Mercurial - 我可以做得更好吗？

Question

我们已经使用Mercurial几个月了,它已经改善了我们的部署过程.这是很好的部分.

我们现有的系统正在运行,但如果您不小心或急于求成,它仍然容易出错.这让我想知道是否有方法可以改进它或者...也许我们完全偏离轨道:)

我们的环境包括:

• 本地开发工作站(每个开发者)
• 开发服务器(托管数据库和中央存储库)
• 验收服务器(QA完成的地方)
• 登台服务器(我们在发布分支的阶段,然后我们将robocopy移植到实时系统)

关于我们切换原因的一点背景:

我们处在一个工作环境中,经常让我们从一个任务切换到另一个任务,留下许多待处理的任务.当我们回到CVS时,许多人会变得陈旧和混乱.部署是一场噩梦,因为你必须解决需要上线的线路以及其他没有使用Beyond Compare的线路.

Mercurial与命名分支和轻松合并为我们解决了这个问题.所以不知道我们期待什么,我们设置它.

首先,我们清理了清理生产源,修剪死文件等.

我们在暂存时将其设为FTP并将其作为"默认"的新存储库,这是我们的稳定分支,随时可以部署.

之后,我们hg clone对开发服务器进行了操作,并让每个开发人员都hg clone来自开发默认分支.

接受我们做QA的时候,我们做了一个hg clone开发服务器的默认分支.

此时我们到处都有稳定的代码副本,每个人都渴望入手!

本地机器正在推动开发,从开发中接受拉动并且分段完全隔离并且可以从提供路径的任何地方拉出.

现在这背后的想法是,我们系统上的默认分支将始终是实时服务器上代码的副本,前提是我们记得在启动新分支之前提取.在开始新功能时,我们会:

hg pull -b default #synch up
hg update default 
hg branch {newFeature} #newFeature completely isolated from other changes.

*work on {newFeature}

不好了!一个错误!这与我目前正在处理的内容无关,我们称之为{bugFix111}.这似乎需要一个独立于我的功能的新分支; 返回更新的默认值.这将使newFeature和bugFix111彼此隔离,并且每个都可以独立生存,因为它们基于默认值.

hg update default
hg pull -u
hg branch {bugFix111}

完成工作后说{bugFix111}

hg push -F {bugFix111} #send our fix to the main central repo on dev.  

去验收:

hg pull -b {bugFix111} #pull the fix from the central repo (dev).
hg merge {bugFix111} #merge the code in the default QA branch.
hg commit -m "Merging {bugFix111} into default"

*QA sign off on the fix

我们必须分支接受 - 默认是QA发生和释放我们合并的东西,因为它签署了.

hg update release 
hg merge {bugFix111} #fix is now ready to go live
hg commit -m "Merging {bugFix111} into release"

在分期:

hg pull -b release {PATH TO ACCEPTANCE REPO}
hg merge release
hg commit -m "Merging {bugFix111} into staging default"
hg tag release{date}
*robocopy to live
*run task that pull from staging to dev so that they synch up again.

这一直在为我们工作并节省一些部署时间,因为只需自动复制稳定版本分支即可.

问题

我们注意到的是:

• 在第二次合并发布时很容易合并,这似乎不符合流程.质量保证签字后我们可以打破它.

• 可以让QA测试我们的发布分支,但它似乎是复制资源,目标只是让功能隔离并能够一次发送一个.

• 我们可以通过合并释放错误来彻底炸毁它,例如当你接受默认值时,hg merge release会完全覆盖它.

• 如果我们在开始新的分支之前忘记拉动,我们就会在错误的基础上工作.

• 几乎没有其他奇怪的东西,但那些是最大的障碍.

我意识到这是一个很长的帖子,但希望答案能帮助像我这样的其他Mercurial新手试图在他们的公司建立一个像样的工作流程.

Answer 1

为什么不从 QA 部门拉动登台呢？然后合并作业已经完成并验证，即如果提交有一些手动合并，您也将在暂存时导入它。否则，您必须像现在一样在暂存时复制合并。