GitLab CI 持续集成
GitLab CI是一套持续集成开发方案。
什么是持续集成
在多人协作开发中，如果一个人修改了代码并提交，可能会对其他人的代码造成影响，从而导致程序出现bug，持续集成的目的是让我们能够及时的发现并改正这些bug，避免bug被累计，从而导致代码最终不可合并。
为了达到这一要求，需要做到两方面：
- 每完成一个小功能，就把代码及时提交到主干，及时暴露问题。
- 对提交的代码进行编译、测试、部署等一系列的操作，中间任何一步发生问题，就通知对应的开发人员进行修改。
GitLab CI主要是帮助我们将对代码的编译、测试、部署等一系列中间工作自动化掉，提升我们的效率。
GitLab CI的工作原理
如图，当我们提交代码的时候，GitLab会通知GitLab-CI服务器中的runner程序，runner会对我们的代码进行相应的处理，一旦处理中发生错误，就会通过发送邮件等通知到我们，整个的过程我们可以称为：进行了一次构建（Pipeline）。
runner是由gitlab提供的，我们只需要下载安装就可以了，下载地址>>。
为了不让runner的执行影响GitLab系统，runner需要部署在独立的服务器上运行（如上图中的GitLab-CI服务器），该服务器上可以跑多个runner程序，用于处理不同的构建任务。
GitLab怎么知道有哪些runner的
安装了runner之后，我们需要通过向GitLab注册，之后GitLab就知道有哪些runner可以使用了，注册的方式>>。
runner怎么知道要跑哪些任务的
我们需要在项目根目录当中放置一个.gitlab-ci.yml配置文件，然后在配置文件中配置上我们需要运行的任务（比如测试、部署等），.gitlab-ci.yml的内容形如：
stages:
- build
- test
- deploy
job 1: # 编译任务
stage: build
script: make build dependencies
job 2: # 编译任务
stage: build
script: make build artifacts
job 3: # 测试任务
stage: test
script: make test
job 4: # 部署任务
stage: deploy
script: make deploy
在配置文件中有两个概念我们需要注意一下：stage和job
stage
Stages 表示阶段，我们可以定义多个 Stages，这些 Stages 会有以下特点：
- 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
- 只有当所有 Stages 完成后，整个构建过程才算成功
- 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务失败
因此，构建（Pipeline）和stage的关系是
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
job
Jobs 表示构建工作，表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
- 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务失败
所以，Jobs 和 Stage 的关系图就是：
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
