在开源社区的持续集成领域,当Jenkins/Hudson一统天下的时候,天边突然有个家伙踩着云朵飞了过来,风格非常小清新,而且表现得和最近大红大紫的Github非常亲昵。Ruby on Rails、Ruby和Node.js等项目已经被他吸引,或者说大部分有身份的Ruby开源项目都成了他的粉丝,事实上投靠他的项目已经超过7,500个,他每天执行超过4,000次的构建,他支持Ruby、Java、Python、Perl……好吧,其实是除了C/C++/C#之外的所有主流语言。
他是Travis CI,为开源社区提供的云端持续集成服务。
我还记得07年接触CruiseControl的时候,所有配置都得通过后台的XML文件完成,修改完了再重启服务,如此反复,久而久之,烦不胜烦。然后08年接触到Hudson,修改配置有比较友好的Web界面了,自然一见倾心。现在来看,travis-ci似乎回到了CruiseControl的原始时期?其实不是这样,下面是一个典型的travis-ci的构建配置:
language : javascript : mvn -q clean install# whitelistbranches :only :- masternotifications :email :irc :- “irc.freenode.org#cucumber”
首先,和XML相比,非常小清新,现在好像大家都喜欢这么搞,比如Gradle较之于Maven,这么简洁性感的配置,无疑是非常有吸引力的。其次,这里的配置和CI服务其实是没有关系的,因此对于项目开发人员来说,我只关心怎么构建我的项目,而不用关心CI服务器如何配置。
这个DSL模型是非常简单的,它主要只包含了四个部分:
值得一提的是,Travis CI提供了工具travis-lint帮助你验证DSL的语法。
另外,由于构建配置是存储在版本控制仓库中的文本,因此天生就继承了版本控制带来的各种好处,例如可以回溯历史、不怕丢失、一有更改大家都能看到。
Travis CI只支持Github,但是集成得非常平滑,你可以直接用Github账号登陆,看到自己的Git仓库,然后点个按钮开启集成并授权Travis CI访问你的仓库即可,之后默认每次的push都会触发集成。
换句话说,默认Travis CI不支持你自己的Git仓库,更不用说Subversion什么的了。但是,Travis CI是开源的,因此技术上来说支持其他形式的SCM不是什么困难的事情。
从InfoQ的这篇报道我们可以看到,Travis CI已经试图将这一成功的开源项目在企业层面复制,名字也想好了:Travis Pro。
在我看来,这是Travis CI大有可为的一个领域,首先,云CI可以解放开发人员的生产力,正如我们在前面看到的,开发人员一方面不需要考虑CI背后的基础设置,另一方面又能够很轻松地对自己的构建任务实现可控。传统的做法,一种是开发人员自己维护CI服务器,包括服务器本身和集成任务的配置;一种是交给配置管理员,那开发人员想要修改集成任务配置的时候,就需要和配置管理员协调。
其次,这种将CI作为服务按需提供给开发人员的方式,可以节省企业的成本,从这篇关于Travis CI环境的文档我们可以看到,Travis CI在执行每次构建之前才开启虚拟机,执行完之后立刻关闭,这可以让硬件资源得到充分的利用。
当然,真正把Travis CI部署到企业环境中还是有许多工作要做的,这需要有人熟悉它的工作原理;可能要进一步开发以集成企业内部的各种环境,例如常见的LDAP;Travis CI目前对Ruby支持非常好,但对于Java就一般,还不支持C#。
Travis CI还有很多非常Cool的特性,包括:
Travis CI有没有革命性的新技术?看起来是没有,不过它用到了很多当前最流行的技术和工具,比如DSL、Github、RESTful、Chef等等,而且达到了非常好的效果,这自然吸引了大量Geek,这也受益于开源社区所独有的特别开放的氛围。
关于Travis Ci和Jenkins/Hudson的关系,在我看来,短时间Jenkins/Hudson的主流地位并不会受到挑战,这主要是因为Jenkins的生态圈目前更为成熟,对Java的支持更好,另外对大多数中小企业来说,部署Jenkisn/Hudson容易得多。但长期来看,Travis CI这种云的方式必然会在大型的企业中占据主流的地位。
本文只是从用户角度简单分析了Travis CI,关于Travis CI的架构和实现,希望有机会再学习分享,目前,感兴趣的读者可以参考这篇架构概览。
还有其他 https://github.com/defunkt/cijoe