像Git这样的DVCS是否适合使用持续集成的团队？

我的团队的开发流程基于持续集成.我们创建的唯一分支是维护分支,当我们发布时,但是开发人员应该定期(每天,如果不经常)提交到主干,这样每个人的工作总是集成,持续测试,以及所有好东西.

我对DVCS的理解是它非常适合分支.几年前我在一个非常有用的团队中工作,因为每个开发都是在一个分支上完成的,只有在完成和测试时才合并.但这与持续整合不同.

但在我看来,对于使用连续集成的团队而言,像Git这样的DVCS工具的常规功能并不是特别相关,如果合并更改需要额外的步骤可能会被遗忘,甚至可能会阻碍持续集成过程.

我确信DVCS还有其他好处(例如,提交非常快,因为它是本地的,可能与主分支合并可能在后台发生,而开发人员继续工作).

但是对于这个问题,我对使用DVCS和连续集成的团队如何协调这两个看似相互矛盾的哲学感兴趣.我主要是想听听那些真正这样做的人.

实际上DVCS使持续集成变得更加容易.

使用中央VCS,每个开发人员都有权直接在trunk中提交,因此他可以提交错误的代码.CI将在事后检测到它.因此即使使用CI也可能会破坏后备箱.

另一方面,DVCS世界中的基本操作是分支和合并.因为合并是显式的并且是单独的进程而不是提交到主干,所以总是可以在合并到达主干之前检查合并的结果.我没有Git的经验,但是在PQM工具的帮助下,Bazaar VCS的开发人员已成功使用这项技术至少3.5年.

基本上PQM工作流程如下所示:开发人员发布他的分支以便可以合并,然后他通过合并指令向PQM机器人发送特殊电子邮件.当PQM收到合并请求时,它会创建一个单独的集成分支(trunk的副本),然后合并开发人员的分支并对生成的代码运行测试.如果所有测试都通过,那么集成分支将被推送到主干,否则开发人员将收到一封包含失败测试日志的电子邮件.

运行Bazaar项目的所有测试需要时间,但测试是在单独的服务器上按需执行的.开发人员不会被合并阻止,并且可以继续处理其他任务.

作为基于PQM的合并工作流程的结果,bzr主干永远不会被破坏(至少只要有足够的接受和回归测试).

由于所有DVCS都可以与使用集中式存储库的工作流一起使用,因此没有问题.策略规定开发人员必须将其更改推送到中央存储库,其方式与策略规定对非分布式VCS的提交完全相同.允许开发人员编辑补丁集的其他工具不以任何方式阻碍,实际上使生成可维护代码库变得更加容易.

使用像Git这样的DVCS并不会阻止您定期向中央存储库提交.但是,它确实意味着您可以在本地进行中间提交,并且只有在完成后才将更改推送到中央存储库.

这样,即使在实现功能的一半时,您也可以从源代码控制中获益,而不会破坏其他开发人员的构建.

Hudson等持续集成工具支持DVCS,因此我怀疑这可以协调持续集成与分布式版本控制.

首先,我认为使用DVCS使用主题分支工作流CI之类的工作流可能不那么必要.其次,您可以设置(单个,中央)持续集成存储库,在准备就绪时将其推送到其中,并挂钩执行CI.

新增07-08-2009:

例如,请参阅GitHub博客上的持续集成Spring Cleaning文章.