你的位置:首页 > 软件开发 > Java > 为什么要做持续集成

为什么要做持续集成

发布时间:2016-02-22 16:00:03
持续集成在目前大多数的公司里都会有这样或者那样的使用。有的会选择一些Open Source的工具,如CruiseControl,Hudson,LuntBuild等等等等,有的会购买有更好服务,更强功能的商业产品,如TeamCity,QuickBuild等等,而有的会选择自己实现, ...

持续集成在目前大多数的公司里都会有这样或者那样的使用。有的会选择一些Open Source的工具,如CruiseControl,Hudson,LuntBuild等等等等,有的会购买有更好服务,更强功能的商业产品,如TeamCity,QuickBuild等等,而有的会选择自己实现,如Cron+Ant/Maven/Make等等。那么使用下来效果如何呢?真得达到了预期的效果吗?我想来恐怕未必吧,否则也就不会有这么多的讨论了。[@more@]

持续集成与敏捷编程

在敏捷领域中,测试驱动和持续集成被称为敏捷编程的两大基石,于是乎,很多人的概念里就是持续集成是为了实现敏捷编程的。这是一个错误的认识。实际上,早于敏捷编程概念的提出,持续集成作为一个best practice就已经被很多公司采用了,只不过作为一个概念,则是由Martin大叔为了推进敏捷所倡导并由此风靡起来。持续集成本身只是一种practice,并不被什么开发模型所限制,在任何一种开发模型中都可以采用,也可以运行得非常理想。

持续集成还是阶段集成

有很多人说,我不做持续集成,照样工作的很好。因为我们一个(小)阶段出一个版本,照样控制得非常好。我得恭喜你,首先持续集成也好,阶段集成也罢,你做了,做了就好,比没有做要好很多,也使你的项目管理上了轨道了。这两者之间的区别仅是频率而已。那么究竟那种方式更加理想,更加符合项目的开发和管理呢?其实这个问题Steve McConnell在他那本获得Jolt大奖的书《Code Complete》(代码大全)里有过回答了。他说:对于一个微型程序来说,阶段式的集成或许是最佳方法。何谓微型程序,他说就是那种两三个类的程序,而你又很走运的话,那么阶段式集成就可以是你的最佳方法了。当然,这位老兄是个老美,我们也都知道老外嘛,都比较笨一点,所以呢,他说微型程序,对于我们拥有5000年文明的中国人说,可以再扩大点吧,对于一个小型项目,就是那种二三十个类的项目,也许使用阶段集成也不会出啥子问题吧。不过,你要真的是懒到连个阶段集成都不愿意做的话,那么你至少求求上帝保佑你的项目一切顺利。

为什么要做持续集成

很多人肯定非常不苟同我的看法,他们认为即使没有做持续集成,甚至没有做阶段集成,但是项目一样按时的完成,甚至提前完成,而且照样完成的非常理想,老板满意,客户满意。而做持续集成,无非就是动不动收到一封邮件,说这个build成功了,那个build失败了,不过就是一持续编译罢了,我自己打个命令编译一下,不就知道了吗?要做个daily build,我还要去set up,还要花力气去配置,效果也不见得好到什么地方去。对于这样一些问题,我想首先我们还得搞清楚,究竟为什么我们要去做持续集成,持续集成究竟可以给我们带来什么好处。同样在《Code Complete》里提到了,对于持续集成(在书中,Steve McConnell使用Incremental Integration的术语)有以下几点好处:易于定位错误。也就是当你的持续集成失败了,说明你新加的代码或者修改的代码引起了错误,这样你很容易的就可以知道到底是谁犯了错误,可以找谁来讨论。随着时间的推移,持续集成带来的更多好处,也逐渐被认识到了,比如说:工欲善其事,必先利其器。首先选择一个好的工具很重要,在我另一篇帖子《持续集成工具的选择》中,我已提到过了,这里不再多说。用下来,我觉得QuickBuild真得很不错。工具选好了,具体怎么做呢?这个没有什么标准可以遵循,每个项目都是不一样的,我谈谈我们这里的具体过程吧。首先,我们对编码有一些规范需要遵从,所以我们制定了一系列的FindBugs和PMD的规则用于检查代码。这个,也是Java领域中经常使用的一个完整的过程。有了这样一个脚本以后,我们开始配置我们的项目到QuickBuild中去,在QuickBuild中,我们配置一个configuration,然后设定我们的SCM repository,对应于我们的ant task,我们配置了一系列的step,用于完成整个过程。由于我们的测试需要跨平台,所以对应与同一个unit test的task,我们使用QuickBuild的分布式的step功能,使之在不同平台上可以进行测试,这一点也是使用CI Server的一个好处吧。对应于这个configuration,我们配置了四个子configuration,分布是Development Configuration, QA Configuration,Integration Configuration和Release Configuration。这几个configuration分别对应于我们开发过程的四个阶段,我们的每日构建都是在Development configuration上的,所以我们配置为每日一次,而对于其它三个则不做自动的构建。因为我们是通过Promote来做的。对于Development Configuration,我们没有对SCM自动打Label,而对于其它的,我们则对每一个Build自动对SCM进行打Label。有了这些以后,开发工作开始了,我们每天的代码在下班前都提交到subversion里去,第二天,Development Configuration就自动的编译完成了,并且发送通知给我们。我们通常会会开一个Morning Meeting,首先我们会到在QuickBuild的页面上,看到昨天有哪些个改动,测试的状况,比如说哪些测试修正了,哪些测试还没有被修正,哪些source code没有通过代码检查。然后我们会点到具体的报告中去分析,这些报告都可以很容易的打开source code,我们可以直接在上面对各个改动做code review。通常这个工程耗时约30分钟结束。通过这样做,我们基本上可以很容易的知道每一个版本之间有什么变化,甚至我们可以很容易的重新build出任何一个时间点上的版本。而且,我们基本上无需操心什么时候给SCM打什么样的Label,因为对于我们而言,我们需要看到的只是每一个版本的build。而如果用subversion来管理的话,也许你也可以通过命令来列出在SCM中各个版本的变化,但是如果有一天,你头昏忘记打label的话,或者打错label的话,也许要找到这个问题就不是那么容易了。又也许,你可以通过一系列的命令来完成这里提到的所有功能,但是我觉得如果计算机可以完成的话,还是让计算机去做吧。


原标题:为什么要做持续集成

关键词:

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。

可能感兴趣文章

我的浏览记录