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

前言

在实际工作中，为了防止当前分支大幅度偏离主干，开发人员每天都会频繁地将代码集成到主干。如果不使用持续集成，人工重复进行编译部署等工作，无疑是低效且易出错的。所以持续集成的优点显而易见：

减少人工编译部署过程中的低级错误
缩短开发周期，快速进行版本迭代
随时可部署
让开发人员专心coding（高效）

目录

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

为什么要用GitLab CI/CD

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

GitLab CI 预览图.png

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

Jenkins 主界面(来自网络).jpg

一点理论

在实践之前我们先介绍一些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的工作流程应该大致已经清晰了，即下图：

流程图.png

但是还有一个疑问就是：谁去统筹做上面一系列的事情呢？就是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文件：

屏幕快照 2017-12-17 下午3.24.58.png

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