Gitlab CI，你值得拥有

文鹏飞

2017-08-05

gialab

先唠叨一下持续集成的概念和为什么要去用它，如果有一定了解的话可以跳过直接去看正文

持续集成(Continuous integration简称CI)是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

上面那段话怎么去理解呢？先回想一下我们产品开发的基本过程，传统开发模式一般是这样的：

1	开发 --> 编译 --> 部署 --> 测试 --> 上线

上面流程再细分就变成了：

分配任务给开发人员
开发
部署到测试环境
测试团队进行测试
出现bug，记录在bug列表
分配bug给开发人员
重复开发 -> 部署 -> 测试
直到所有bug都解决，部署到生产环境

上面的开发过程中有很多问题，又是我们大部分人都在面临的：

大量重复劳动
Bug总是在最后才发现
越到项目后期，问题越难解决
程序经常需要变更（无限循环开发、编译、测试、部署）
交付时机无法保障

所以我们需要持续集成去尽早发现我们的问题，尽早的去解决，并且减少我们开发过程中各个环节的时间，提升我们的开发效率，持续集成的工具有很多，比如：Travis、Jenkins、Codeship、Strider还有今天我们要介绍的GitLab CI

接下来会有几个步骤去完成我们的注册，值得注意的是我们要找到gitlab server url和项目token并设置，参考下图的How to setup specific Runner for a new project（Setting -> Pipelines）。runner支持的执行方式有ssh, docker machine, docker-ssh machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell，我使用的是ssh

配置

安装完成之后我们去Gitlab选择一个项目 Setting -> Pipelines:

我们会看到两种Runner：

Specific Runners
Shared Runners

Specific Runners是我们自己创建的，可以针对我们自己的项目，Shared Runners是Gitlab管理员创建的，针对所有的Gitlab项目。可以看到可用的Specific Runners下面有个17c17f05，这个就是我们刚才注册的Runner。

点击Enable for this project启用，并且Disable shared Runners禁用Shared Runners。

现在Runner已经和我们的项目绑定好了，下面就是需要定义我们的工作流和脚本了。

手动创建一个.gitlab-ci.yml文件或者在项目首页点击Set up CI，下面是我在用的一个Nodejs配置：

stages:
  - build
  - test
  - deploy

cache:
  paths:
  - node_modules/
  - dist/

before_script:
  - cp .env.example .env
  - yarn install
  - yarn build

build:
  stage: build
  script:
   - yarn build

test:
  stage: test
  script:
   - yarn test

deploy:
  stage: deploy
  only:
   - master
  script:
   - pm2 delete api || true
   - pm2 start dist/index.js --name api

配置完成，当分支变更Gitlab就会通知我们注册的Runner开始干活，首先runner会在我们的vps上签出变更的分支，然后这个例子的pipeline分为三个阶段：

build
test
deploy

任何一个阶段出错，都不会继续往下进行，详细的配置参考：.gitlab-ci.yml

Gitlab CI，你值得拥有

目录

介绍

架构

安装

配置