使用GitLabCI持续集成
使用持续集成应该是一个软件开发工程师的自觉。 ——沃兹基.索德
#前言
在实际工作中，为了防止当前分支大幅度偏离主干，开发人员每天都会频繁地将代码集成到主干。如果不使用持续集成，人工重复进行编译部署等工作，无疑是低效且易出错的。所以持续集成的优点显而易见：
- 减少人工编译部署过程中的低级错误
- 缩短开发周期，快速进行版本迭代
- 随时可部署
- 让开发人员专心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。