中兴软创(ZTEsoft)基于Jenkins和Docker的CI实践

本次分享从四个方面展开:基于Jenkins的CI过程、基于Docker的应用发布、基于Dubbo的跨主机的容器连接、困难与展望。

基于Jenkins的CI过程 一切要从2013年4月开始说起,当我4月份从委内瑞拉回来之后立即投身到国内一个运营商的大型后端建设项目的尾声中(项目历时3年多,当时已经接近尾声),这个项目涉及100多台主机,包含数十个集群,除了传统的WEB应用外,还用到了流程引擎、ESB、规则引擎、搜索引擎以及缓存和日志,是当时比较复杂的体系结构(当然不能跟现在的云平台相比,但在项目开始的年代这还是一个很不错的架构),整个项目当时一两百号人占了局方整整一层楼十几个办公室。
我到了项目组之后成为了一个小组的小头目,管个四五个人,小组美其名曰“平台组”,干的都是打杂的事情,包括编译、打包、部署,日常监控以及系统优化等工作,说起来简单,做起来还是很复杂的,当时所有的工作基本上是靠人工的,可想而知,100来台机器的环境一台一台的部署环境,还得靠人工监控,手工检查,四五个到处救火忙得不可开交,当时我虽然还不知道CI为啥物(压根儿就没这个概念),但也下定决心要改变忙乱的状态,累一点不要紧,但是累得跟狗似的还干不好那就白辛苦了。
在2013年的4~8月份,我们主要研究的是自动编译、打包和发布,采用的基本方式是各种脚本,包括windows下的批处理bat、Linux上的 shell甚至Python,虽基本上完成了自动从SVN取代码、自动编译、自动打包以及将应用发布到WebSphere上的这些工作(如下图):

1.png

但也明显存在一些问题:

自动执行靠的是Windows任务计划,执行过程、执行情况只能通过检查脚本执行时写的日志文件,不直观。

代码只作了编译,没有做代码走查,对代码质量的提升作用不大。

发布过程利用IBM提供的wsadmin脚本,只能进行全量的发布,发布过程较长。


9月份之后,项目基本稳定后我也离开了项目现场,但自那之后对这块工作更加着迷,我从项目现场回来之后也组建了一个科室,还是四五个人,当时我查阅了一些资料,尤其是看到了一本书《持续集成,软件质量改进和风险降低之道》,从此学到一个名词:CI(持续集成),一发而不可收拾,逢人就鼓吹CI。我组织科室人员一起研究了CruiseControl、Apache Continuum、QuickBuild、Hudson等业界CI常用工具,最后决定以Hudson为框架来逐步实现CI.。一早采用的是 Hudson,后来为便于作二次开发切换到其社区版本Jenkins上。
Jenkins提供了一个管理界面,并且有丰富的第三方插件,支持定时任务,支持从SVN取代码,支持Ant编译和Maven编译(我们产品编程框架逐渐从ANT转向maven模式),支持向tomcat、JBoss、Weblogic和WAS发布应用(Jenkins的WAS插件不支持集群模式,我们仍然沿用了wsadmin脚本),支持用PMD、Checkstyle、findBugs进行代码走查并以图形化方式展现走查结果(包括趋势图和结果详情),支持调用Windows批处理bat、Linux的Shell等。
在采用Jenkins框架的基础上,我们作了一些二次开发,实现了:

根据任务单增量从SVN取代码(有一些奇葩的项目现场要求挑任务单升级,因此我们修改了jenkins的svn插件以支持这种需求)。

2.png

支持增量编译(采用两个Jenkins的JOB,一个做全量编译,作为首次编译并产生一个jar包给增量编译使用,此全量编译JOB只使用一次;另一个JOB就引用全量JOB产生的jar包,只对变更(或新增)的代码编译产生class等文件,并将它们按部署目录放好以便于作增量发布,同时将这些class文件再打入到全量JOB下的jar包中以备下次增量编译使用)。

支持增量发布,通过调用lftp脚本实现快速的应用部署(在比较了cwRsync、unison、wget、lftp、ftpsync、csync、Syncrify、DeltaCopy、tar、bacula等工具后,最终lftp胜出,我们采用: lftp -c \'open -e "mirror --allow-chown -x vssver.scc -R --parallel=10 --use-pget-n=10 --log=%LOG_FILE% %LOC_DIR% %REMOTE_DIR%" sftp://%USER%:%PASSWORD%@%IP%\'
这样的脚本来进行增量发布,将编译后的结果与部署环境上的进行自动比对更新)。

支持基于Ant和基于Maven的代码走查,编写Ant 脚本和Maven脚本以支持PMD、Checkstyle、findBugs进行代码走查(由于jenkins中代码走查插件生成界面时会消耗大量系统资源,对机器性能影响很大,后面我们改成了通过脚本方式生成并将走查结果打成压缩包发邮件给相关人员)。

支持基于Maven的代码的单元测试(采用TDD编码方式)。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwgxfg.html