CI

从GitLab 8.0开始，GitLab CI就已经集成在GitLab中，我们只要在项目中添加一个.gitlab-ci.yml文件，然后添加一个Runner，即可进行持续集成。而且随着GitLab的升级，GitLab CI变得越来越强大，本文将介绍如何使用GitLab CI进行持续集成。

基础概念

Pipeline

一次Pipeline其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者Merge Request的合并都可以触发Pipeline，如下图所示：

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

Stages

Stages表示构建阶段，说白了就是上面提到的流程。我们可以在一次Pipeline中定义多个Stages，这些Stages会有以下特点：

所有Stages会按照顺序运行，即当一个Stage完成后，下一个Stage才会开始
只有当所有Stages完成后，该构建任务(Pipeline)才会成功
如果任何一个Stage失败，那么后面的Stages不会执行，该构建任务(Pipeline)失败

因此，Stages和Pipeline的关系就是：

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

Jobs

Jobs表示构建工作，表示某个Stage里面执行的工作。我们可以在Stages里面定义多个Jobs，这些Jobs会有以下特点：

相同Stage中的Jobs会并行执行
相同Stage中的Jobs都执行成功时，该Stage才会成功
如果任何一个Job失败，那么该Stage失败，即该构建任务(Pipeline)失败

所以，Jobs和Stage的关系图就是：

+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+

Runner

一般来说，构建任务都会占用很多的系统资源(譬如编译代码)，而GitLab CI又是GitLab的一部分，如果由GitLab CI来运行构建任务的话，在执行构建任务的时候，GitLab的性能会大幅下降。GitLab CI最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情就交给GitLab Runner来做拉！因为GitLab Runner可以安装到不同的机器上，所以在构建任务运行期间并不会影响到GitLab的性能。

.gitlab-ci.yml

配置好Runner之后，我们要做的事情就是在项目根目录中添加.gitlab-ci.yml文件了。当我们添加了.gitlab-ci.yml文件后，每次提交代码或者合并MR都会自动运行构建任务了。

基础语法

# 定义 stages
stages:
  - build
  - test

# 定义 job
job1:
  stage: test
  script:
    - echo "I am job1"
    - echo "I am in test stage"

# 定义 job
job2:
  stage: build
  script:
    - echo "I am job2"
    - echo "I am in build stage"

用stages关键字来定义Pipeline中的各个构建阶段，然后用一些非关键字来定义jobs。每个job中可以可以再用stage关键字来指定该job对应哪个stage。job里面的script关键字是最关键的地方了，也是每个job中必须要包含的，它表示每个job要执行的命令。可以看一个更为复杂的例子：

stages:
  - install_deps
  - test
  - build
  - deploy_test
  - deploy_production

cache:
  key: ${CI_BUILD_REF_NAME}
  paths:
    - node_modules/
    - dist/

# 安装依赖
install_deps:
  stage: install_deps
  only:
    - develop
    - master
  script:
    - npm install

# 运行测试用例
test:
  stage: test
  only:
    - develop
    - master
  script:
    - npm run test

# 编译
build:
  stage: build
  only:
    - develop
    - master
  script:
    - npm run clean
    - npm run build:client
    - npm run build:server

# 部署测试服务器
deploy_test:
  stage: deploy_test
  only:
    - develop
  script:
    - pm2 delete app || true
    - pm2 start app.js --name app

# 部署生产服务器
deploy_production:
  stage: deploy_production
  only:
    - master
  script:
    - bash scripts/deploy/deploy.sh

最近更新于0001-01-01