gitlab ci 自动化部署_自动化持续集成：GitlabCI实践

持续集成

持续集成(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 bashyum 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  #激活runnergitlab-ci-multi-runner list    #查看当前runnergitlab-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文件如下：

# 定义 stagesstages:  - build  - test  - restart# 定义缓存cache:  key: ${CI_BUILD_REF_NAME}  paths:    - node_modules/    - .tmp/# 定义 jobbuild:  stage: build  script:    - npm install    - npm run build# 定义 jobtest:  stage: test  script:    - npm run test# 定义 jobrestart:  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中并默认启用。简单安装配置，就能自动化完成繁琐的集成工作，提高生产效率。