基于Jenkins的自动化部署环境优化思路

在我们的自动化部署环境中,源码管理是用Gitlab,构建是Jenkins,运行环境是Docker。这三者的结合方式是这样的:开发人员上传代码到Gitlab,Gitlab调用回调钩子,Jenkins对应的Job开始构建,生成一个个Docker镜像。所谓的回调钩子,其实就是在Gitlab项目里设置的一个Jenkins Job地址。Job是Jenkins的一个项目或者叫任务,当Gitlab调用钩子时,这个Job就运行起来,可以执行一系列的脚本来完成项目的构建,比如自动从Gitlab下载源码,然后执行编译命令等。

刚开始的时候,我们的项目不多,那么只要求这个逻辑跑得通就好了,也就是自动构建能完成就好了。对于每一个Gitlab上的项目,我们在Jenkins创建对应的一个Job,然后给Gitlab的项目设置钩子,每次Job运行起来时执行脚本构建Docker镜像。但是我们自动构建不仅仅是生产环境,开发环境、测试环境也要自动构建,这样一来,一个Gitlab项目就要对应3个Jenkins Job。后来,我们把项目的配置和源码分开,生产环境的配置文件包含密钥等信息,只有运维人员或者公司具有更高权限的人员才能访问。对于Gitlab上的每个项目,我们建了一个新的项目,里面只包含配置文件,这个项目同样设置钩子,当配置文件有修改时,同样触发Jenkins的自动构建。再后来,我们的V1版本开发告一段落了,开发人员进入V2版本的开发,比如原来项目的名称叫cms-v1,现在又多了一个项目cms-v2,V2可能采用的技术跟V1完全不一样,构建的方式也不一样,因此针对cms-v2和其配置项目,我们又得在Jenkins上创建新的Job来完成自动构建。

我们发现这样下去的话,Gitlab上的Project和Jenkins上的Job越来越多,越来越难维护。比如一个cms项目,在Gitlab上有两个源码Project了,还有两个存放配置文件的Project,以后到了V3,又得增加2个Project。Jenkins上的Job也是一样增加,Jenkins我们是基于Pipeline构建的Job,每个Job的构建逻辑直接通过UI界面编辑,比如这样:

这样每次我们要修改构建方式时,直接在这个UI界面修改,也就是直接在UI界面写代码,只是代码保存在Jenkins里面。我们又发现,现在看起来是两套源码管理系统了,一个是Gitlab,还有一个是Jenkins,因为它也保存了构建代码,只是少量而已。

针对上述种种情况,我们的优化思路是,尽量减少Gitlab上的Project数量和Jenkins上的Job数量,同时不直接在Jenkins的UI界面上编写构建脚本,而是把构建脚本写进Jenkinsfile中,Jenkinsfile同源码一样托管在Gitlab上,修改它就像修改项目功能源码一样,这样代码相关的内容都在Gitlab上统一管理,Jenkins构建时会从Gitlab上获取Jenkinsfile然后执行构建。然后对应比如cms项目,不同版本不再分Project,而是用branch,不过目前Gitlab没看到可以基于branch设置钩子,但是Jenkins有插件可以获取到更新的是哪个branch的代码,这样在Jenkins上针对cms的Job也可以不同源码版本使用同一个,只是需要在Jenkinsfile里面区分是哪个branch提交了代码,执行相应的构建逻辑即可,这样大大减少了Jenkins上的Job数量和Gitlab上的Project数量,检索和维护起来更加方便。

目前我们的优化思路也就这些了,如果您有更好的优化思路,欢迎在评论里分享下哈。

发表评论

电子邮件地址不会被公开。