使用GitLabCI持续集成

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

#前言

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

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

#目录

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

1、为何要用GitLab CI/CD

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

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

##2、一点理论

在实践以前咱们先介绍一些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为例:

一、添加GItLa官方库

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

二、安装runner

sudo apt-get install gitlab-runner

###配置GitLab runner

这里咱们配置一个specific runner。至于shared runner 和 specific runner的区别，你们能够经过官方文档的介绍，本身去选择，这里不赘述了。Shared vs specific Runners

一、拿到token

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

二、进行配置

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

sudo gitlab-runner register

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

查看效果

更改代码并提交，而后在项目的CI/CD-->pipelines选项里直接能够看到构建状态：如图

一些问题

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

#总结

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