自动化持续集成：Gitlab-CI实践
2018-06-15
持续集成
持续集成（Continuous Integration）是一种软件开发实践。团队在开发过程中，提倡每个成员写完一个小功能就集成到主干中，尽快暴露开发过程出现的问题，早发现早解决。这也是我们常说的“小步快跑”，防止到项目后期合代码的时候才发现严重问题，到时改动的成本和风险都会很大。
虽然持续集成有许多好处，但每次集成的工作细碎繁琐，要合并代码、编译、跑测试用例、部署。如果跟以往一样，都由人工完成的，那会非常麻烦。于是我打算引入Gitlab-CI来自动化这个过程。以下介绍部署的过程。
原理
首先准备两台服务器。一台部署Gitlab，具体参考上一篇博客。另一台作为Runner服务器，用于编译、测试、部署，可以是平时用的编译机、开发或测试的环境、甚至本地电脑。一个项目允许同时存在多个Runner服务器，今天以最简单的单台Runner服务器为例。核心流程如下图：
环境准备
安装：
Gitlab服务器部署方式参考上一篇博客。
Runner服务器只需要安装gitlab-ci-multi-runner服务即可。这次用的是一台CentOS的服务器，安装命令如下：
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash yum install gitlab-ci-multi-runner
注册：
安装完之后需要注册一个runner。首先我们在Gitlab上找到需要集成的项目，左侧Settings->CI/CD->Runners settings ，找到域名和token：
回到Runner服务器，运行注册命令：
gitlab-ci-multi-runner register
根据提示补充相关信息，输入上图的URL和token，选择runner存放和执行的目录，随便输入一个名字，类型选择shell就行。
注册过程Gitlab服务器会传一个token给Runner，作为以后通信的凭证，以后所有通信都会用到。这个token存在/etc/gitlab-runner/config.toml配置中。token的原理请参考我另一篇博客《什么是token》。
运行：
执行下面命令：
gitlab-ci-multi-runner verify #激活runner gitlab-ci-multi-runner list #查看当前runner gitlab-ci-multi-runner run #运行runner
如果想要查看执行的细节，还有debug模式：
gitlab-ci-multi-runner --debug run
gitlab-ci-multi-runner run默认是前台运行的。如果想要把Runner安装为一项服务，用以下指令：
gitlab-ci-multi-runner install #安装 gitlab-ci-multi-runner uninstall #拆卸 gitlab-ci-multi-runner start #开启服务 gitlab-ci-multi-runner stop #停止服务 gitlab-ci-multi-runner restart #重启 gitlab-ci-multi-runner status #查看状态
至此，Runner服务器已准备就绪。此时在debug下看到不断打出“Checking for jobs...”，它是在Gitlab服务器轮询，看看有没有新的任务要执行。如果这一步抛出了http错误码，可以根据错误码对症下药。
编写集成脚本
在项目的根目录下新建.gitlab-ci.yml文件如下：
# 定义 stages
stages:
- build
- test
- restart
# 定义缓存
cache:
key: ${CI_BUILD_REF_NAME}
paths:
- node_modules/
- .tmp/
# 定义 job
build:
stage: build
script:
- npm install
- npm run build
# 定义 job
test:
stage: test
script:
- npm run test
# 定义 job
restart:
stage: restart
script:
- npm run stop
- npm run start.gitlab-ci.yml文件用于配置集成一套完整的集成任务stages，一个stages下包含若干的jobs，即不同阶段。
以上面的配置为例，在这个集成任务中有三个阶段：构架build，测试test，重启服务restart。这三个任务的执行顺序在stages中定义，而每个阶段需要执行的命令在下面的jobs中的script。
每执行完一个jobs，得到成功的结果，才会继续执行下个阶段，失败则抛出错误提示，不再执行下个阶段。每个阶段执行完都会清除gitignore的文件，所以我们需要对node_modules等目录进行缓存，以避免重复运行npm install。
.gitlab-ci.yml的详细使用方法可以参考官方文档。
自动化集成
上述配置完成之后，就可以体验自动化集成咯。
随便提交点代码，push一下。在Gitlab的项目中，左侧CI/CD->Pipelines中，可以看到一个Pedding状态的stages。Runner服务器查到这个stages就会开始执行了。
还记得上面注册runner时填写的目录吗？runner就在这个目录下clone了这个项目，pull了指定版本的代码，开始依次执行jobs。如果脚本里需要调用其他目录，建议使用绝对路径，这样不管runner部署在哪个目录下都不受影响。
执行的结果（成功或失败）会回传给Gitlab服务器。debug模式下，看到打出“Submitting job to coordinator...”，就是这个过程。如果Gitlab服务器卡住了出现502错误，或者因为其他原因抛出http错误码，不用慌，Runner自己会不断重试，直到成功为止。
我们在Pipelines中查看运行的结果：
成功的状态已经改为passed，而失败的则是failed。可以看到是在哪个阶段出错的，比如编译失败啦，测试用例跑不过啦，那就可以对症下药找bug了。右边还有一个重新执行的按钮，如果有需要，可以重新将这个stages置为pedding阶段，让Runner服务器重新集成一次。
后记
Gitlab-CI最大的优势是内嵌于Gitlab中并默认启用。简单安装配置，就能自动化完成繁琐的集成工作，提高生产效率。
本文未经许可禁止转载，如需转载请联系 JAY@oonne.com
