再谈持续集成

我们必须先明确一点，持续集成大体上是有这样几个步骤的：
1 开发者更新代码到代码仓库，触发持续集成的pipeline
2 pipeline中进行build，test，package，deploy

简单提一下Jenkins和travis

Jenkins做持续集成可以说是学习和使用成本很低的，思路也很简单。例如一个github的项目，他可以监听仓库的push来触发更新，然后运行设定好的shell语句。例如我们可以设置mvn package这样的语句，将仓库进行测试和打包，当然这需要Jenkins这台机器安装了maven并设置为了环境变量。而部署则比较灵活，如果是本机部署，直接将打包好的jar包进行复制到特定目录下，运行即可。因为都是shell所以很灵活。Jenkins的原理比较容易理解，我们甚至可以自己通过github的webhook自己写一个类似的功能。其核心思想就是代码仓库的webhook触发执行一系列的shell语句。在这些shell语句一开始运行一个git clone先把代码克隆下来，之后对代码构建，测试，打包，部署，都可以用shell去操作。这里我就不再写例子了，网上有很多Jenkins用法的教程，我以前也写过一个

travis则是github上最受欢迎的持续集成工具（插件），主要是用在开源项目的build。一般不用来进行部署，当然也可以这样做。travis需要在github仓库根目录创建.travis.ci这个文件，并指定使用什么语言。在travis官网中有介绍都有哪些语言的环境。其运行原理是，当代码push后会触发travis开始集成，首先读取这个文件，按照上面指定的语言环境申请一个临时的机器（容器），然后运行后面的脚本。可以看出travis和Jenkins不同的是他提供了很多语言环境的机器，供所有github用户使用，不需要自己的计算机或服务器。travis的例子网上也很多，我以前也写过一个

github上的开源项目只进行构建的话，travis是最好的选择。如果不用github或者不开源或者还有复杂的部署的步骤的话，用Jenkins是最稳的。虽然我们现在来看Jenkins的界面感觉像是20年前的东西，但是Jenkins却非常稳定可靠，所以仍旧是最主流的CI工具之一。

Docker为持续集成带来了革命

Docker的出现使得持续集成过程中的环境搭建问题得以解决，travis提供了多种语言的环境，直接提供一个docker镜像就解决了。在部署阶段如果用Jenkins我们可能是将打包好的程序复制到指定目录然后运行。如果使用docker，我们甚至直接将打包好的程序连同运行环境构建成一个docker镜像。然后将这个镜像传到私有仓库，或者直接部署这个镜像就可以了。

DaoCloud

Daocloud是一个国产平台，他在docker容器的管理编排和利用docker做持续集成方面都有建树。他的持续集成方式也是监听代码仓库的hook，目前可以接入github gitlab coding等平台。push代码后触发pipeline，这个pipeline是图形化添加的，也可以通过根目录下daocloud.yml编辑，效果一样。可以选择自定义环境进行各种构建和测试，就是自己写一个docker镜像名，然后写shell脚本。这样我们可以完成各种测试和构建任务。除了代码构建任务，DaoCloud还提供了docker的构建任务，默认就是将根目录下的Dockerfile进行构建(可以修改)，并按照git版本号命名为这个docker镜像的版本号，这个docker镜像会存到属于自己这个账号的空间下，且默认是私有的，非常方便。至于打包和部署，自定义的流程中可以设置“输出”将打包好的程序如jar包或者dist目录等输出，这个输出会在依赖于这个流程的流程中下载下来，放到原来的目录下。最后部署则直接将这个docker部署到自己的主机上即可（当然要事先用daocloud提供的脚本绑定一下主机）。

这个平台的优点非常明显，国内速度非常快，而且非常实用，提供了镜像仓库配合平台使用速度更快。另外daocloud本身是容器编排的一个工具，对于持续交付的最后一环节可以替换已经部署的docker。代码仓库如果放在coding，持续集成放在daocloud，那在国内环境下应该是最快速docker的持续集成搭配了。要说缺点的话，这个平台是基于docker进行构建和部署的，而且必须使用docker，再有就是不能自己在局域网安装，这个是基于云平台提供的服务，所以不能在私网内单独使用。

GitLab

Gitlab的持续集成是通过根目录下的.gitlab.ci进行的，这个文件的写法和daocloud.yml类似也有自己的一套dsl，且用法更复杂。这个文件中你可以定义CICD的阶段，和每个阶段运行的脚本。oh，环境怎么办，你可以写在脚本最开始安装apt-get install xxxx。这个例子就是这样。当然这是不用docker的情况下，如果使用docker就变得简单很多，直接在开始指定image，之后的步骤都在这个镜像中运行。这个例子就是基于docker image运行的。当然我们还应该想到的是package后的程序包怎么传给下一个流程，就像daocloud通过“输出”+“依赖流程”解决了这个问题。gitlab中也采用了类似的“artifacts”+“dependencies”，默认不加dependencies就可以一直传输的。artifacts还可以设置时效等属性，参考文章。gitlab的工件(artifacts)可以在web界面中查看和下载。另外gitlab也可以实现docker的构建，即在docker in docker中运行docker build即可参考。gitlab为每个仓库都提供了一个docker仓库。在最后的部署问题上，gitlab比较自由，需要自己写shell脚本进行部署。gitlab执行这些任务的机器可以是他给提供的机子也可以是自己的一台linux机器（注册到仓库下即可）。

Gitlab本身是git仓库，daocloud本身是编排docker的工具，所以gitlab和代码的提交触发天然融合，通过docker进行持续集成持续交付的工作，最后的部署是较为自由shell指令。而daocloud则和自动部署天然集成直接将更新后的代码按照git版本号生成一个新的镜像，并可以替换原来的镜像。还可以写docker-compose进行多容器部署。Gitlab的功能是更强大的，ci文件的语法非常多，而且gitlab有很多贴心的设置。另外很重要一点是gitlab服务器可以在本地自己搭建，运行在私网中。

不要盲目的崇拜docker

docker容器的概念慢慢变成一种时尚，但是这种时尚不一定适合所有项目。比如你是个web应用用户上传的头像等数据直接就保存在了源码仓库的img文件夹下。如果你部署在docker中，docker镜像升级后意味着用户头像的全部丢失。对于这种集中式的小项目还是不推荐使用docker。一般只负责提供服务不进行数据存储的服务可以单独封装成docker看做是一个微服务，这种无状态的应用是非常适合使用docker的。

小结

对于持续集成持续交付，如果项目不大服务器就一台，选择coding管理代码+Jenkins持续集成是最稳健，而且学习和使用成本最低的。如果你的应用使用了docker，那coding+daocloud是非常不错的选择。如果你的代码不能放到别的服务器，那就git本地仓库+Jenkins。如果上一种情况下你还要用docker那你可以专门找一台机子搭建个公司内网的gitlab服务器。gitlab除了CICD还有很多强大而丰富的功能一定不会让你失望的。