使用GitLabCI持续集成

使用持续集成应该是一个软件开发工程师的自觉。 ——沃兹基.索德

前言

在实际工作中，为了防止当前分支大幅度偏离主干，开发人员每天都会频繁地将代码集成到主干。如果不使用持续集成，人工重复进行编译部署等工作，无疑是低效且易出错的。所以持续集成的优点显而易见：
1. 减少人工编译部署过程中的低级错误
2. 缩短开发周期，快速进行版本迭代
3. 随时可部署
4. 让开发人员专心coding（高效）

目录

• 为什么要用GitLab CI/CD
• 一点理论
• 一点实践
• 一点问题

为什么要用GitLab CI/CD

GitLab8.0之后，GitLab CI就已经集成在GitLab里了。使用GitLab CI可以说是非常的简单方便，先看下预览图

作者之前也尝试了Jenkins。Jenkins作为老牌的持续集成框架，在这么多年的发展中，积累很多优秀的插件工具，不可否认它具有很多GitLab CI不具备的功能，但是Jenkins的使用复杂度跟GitLab CI 相比还是高了不止一点（不信往下看）。而且我觉得Jenkins的页面设计太out。如果你跟我一样是个初学者，还是建议你从GitLab CI开始尝试。

一点理论

在实践之前我们先介绍一些GitLab CI的相关概念。

pipeline

每次代码提交就会触发一次pipeline。一次pipeline可以看成一次构建任务。构建任务一般会包含：安装依赖，测试，编译，部署服务等多个阶段。

stage

stage就是上述构建任务中的各个构建阶段。一个pipeline可以定义多个stage。stage有以下特点：

1.所有的stage按顺序运行，前一个stage完成后，下一个stage才会开始执行。

2.只有当所有的stage都完成后，该构建任务(pipeline)才会成功。

3.如果一个stage失败，那么下一个stage不会执行，该构建任务(pipeline)失败。

job

job表示构建工作，是每个stage构建阶段里具体执行的工作。跟pipeline与stage的关系类似，stage与job也是一对多的关系，即一个stage里可以定义多个job，而job具有以下特点：

1.同一个 stage 中的 jobs 会并行执行

2.同一个 stage 中的 jobs 都执行成功时，该 stage 才会成功

3.如果任何一个 job 失败，那么该 stage 失败，即该构建任务 (pipeline) 失败

GitLab runner

在了解了上面几个主要概念之后，我们对GitLab CI的工作流程应该大致已经清晰了，即下图：

但是还有一个疑问就是：谁去统筹做上面一系列的事情呢？就是GitLab runner。

工作流程

综合上述理论，要使用GitLab CI，我们首先要在项目的根目录下添加一个 .gitlab-ci.yml 文件，用来定义我们的stages，jobs等一系列具体内容，好让GitLab runner据此来完成它的工作。然后需要在服务器（开发或生产环境）上，配置一个GitLab runner，好让GitLab runner去统筹持续集中过程中的所有事。

一点实践

作者在自己的GitLab上初始化了一个express项目作为例子，带大家来实践一下。

配置 .gitlab-ci.yml 文件

Configuration of your jobs with .gitlab-ci.yml 这是官方文档。

我简单配置下demo项目的.gitlab-ci.yml文件：

作如下解释：
GitLab runner 会根据这个文件内容进行构建，不难看出整个构建工作分为两个stage（阶段），第一阶段install_deps：安装依赖包，而具体的job内容就是执行:npm install。 第二阶段：启动程序。每次代码提交，都会触发这两个构建工作。添加缓存cache是因为每个job执行成功后，runner都会去删除.gitignore中的文件。

安装GitLab runner

GitLab runner的安装很简单。installing-the-runner 官方文档

作者以Ubuntu为例:

1、添加GItLa官方库

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

2、安装runner

sudo apt-get install gitlab-runner

配置GitLab runner

这里我们配置一个specific runner。至于shared runner 和 specific runner的区别，大家可以通过官方文档的介绍，自己去选择，这里不赘述了。Shared vs specific Runners

1、拿到token

在你的项目setting->CI/CD->Runners settings下面找到url和token。

2、进行配置

在服务器上输入以下命令来配置一个runner：

sudo gitlab-runner register

然后根据提示把信息填完。（作者为了简单方便演示。Please enter the executor ：选择的shell。）

查看效果

更改代码并提交，然后在项目的CI/CD–>pipelines选项里直接可以看到构建状态：如图

一点问题

在上面的实践中我遇到的一些坑：
1、npm命令找不到：
因为gitLab runner构建的时候是以runner身份操作服务器的，解决方法是：通过link命令把npm链接到 /usr/local/bin/npm。

总结

如果你的代码仓库使用的是GitLab，那么你好像没有什么理由不使用GitLab CI。