前端项目gitlab CI（持续集成）实践

[WarpPrism]

CI是什么？

CI，全称 Continuous Integration，指的是短时间内多次集成代码到主干，它是一种软件开发实践。在每次集成中，可以部署自动化的测试、编译和发布，从而在带代码集成时就发现潜在的错误。

gitlab上如何进行CI？

gitlab 8.0+默认提供持续集成服务，要使用CI服务，需要配置两项内容：

• .gitlab-ci.yml

  放在项目根目录下，每次代码push时，会自动根据该配置文件生成pipeline，然后交给runner执行

• runner

  是一组非gitlab服务器上的进程，用来实际执行pipeline里的任务（jobs）

执行后的CI流水线如下图所示：

正确配置好上述两项内容后，就可以进行CI测试了，当然，CI时执行什么样的任务要根据具体项目和环境来定，比如说一个前端项目，就包括npm依赖安装、eslint语法检测、单元测试、e2e测试、webpack打包、测试服务器发布等任务，总之，配置很灵活，多看文档，多实践就可以

如何配置runner？

runner的类型有很多种，如

• 本机运行的runner
• 虚拟机或服务器上运行的runner
• docker等容器上运行的runner

不同环境，配置也不同，可以参照官方文档来配置：
gitlab runner

这里以我的windows本机为例来安装runner：

1、 在D盘下创建文件夹 D:\GitLabRunner

2、 下载gitlab runner程序到此文件夹，下载地址，注意下载版本是windows x86或amd64即可。重命名为gitlab-runner.exe

3、 以管理员身份运行cmd，运行下面的命令

4、 gitlab-runner 注册

$ gitlab-runner.exe register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
填写项目url
Please enter the gitlab-ci token for this runner
填写项目token
Please enter the gitlab-ci description for this runner
填写描述
Please enter the gitlab-ci tags for this runner (comma separated):
填写runner的标签说明，以逗号分隔，可填可不填
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
这里填写shell（适用于windows本机运行）

其中url和token需要从项目网站上获取，如下图：

5、 安装并运行

$ gitlab-runner install
$ gitlab-runner start

6、 适当调整D://GitlabRunner/config.toml文件，切换为powershell来执行

concurrent = 1
check_interval = 0

[[runners]]
shell = "powershell"

运行成功后，可以在任务管理器中看到gitlab-runner进程，同时在gitlab页面上能看到runner信息，这样就大功告成了，不过记得勾选下面的选项：

使得runner可以运行未设置标签（tag）的jobs，因为出于习惯，很多job都没有设置tag，runner默认只会识别和自己tag一致的job

如何配置.gitlab-ci.yml文件？

先看一个例子：

额，好吧，上面的图截下来文字太小了，贴个文字版的：

variables:  # 变量，可根据情况定义。gitlab也提供许多预置变量

stages:   # 流水线阶段，不同阶段是串行执行，stage下面的jobs却是并行执行。stages默认有3个，分别是build，test和deploy
  - eslint
  - unit_test
  - build

before_script:  # 在每个job执行前触发
  - npm config set registry https://registry.npm.taobao.org
  - npm install # 安装依赖包

cache:  # 创建node_modules缓存，不用每次都重新安装依赖了
  key: ${CI_BUILD_REF_NAME}  # gitlab内置变量
  paths:
    - node_modules/

# 代码检查
eslint check:   # job name，定义每个job实际执行的指令
  stage: eslint
  script: npm run lint # eslint代码风格检查

# 单元测试
unit test:
  stage: unit_test
  script: npm run unit # 运行单元测试

# 打包
build:
  stage: build
  script: npm run build
  only:
    - master   # 表示该job只在master分支上执行
  allow_failure: false   # 表示该job不允许失败，若失败则表示这次CI失败

配置好的runner会根据上述文件依次执行stage，stage下的job并行执行，如果某个stage执行失败，则CI会忽略掉之后的stage，直接进入失败状态。当且仅当所有allow_failure为false的job都执行成功时，这次CI才算成功。

上面配置文件只适用于一个简单的前端项目，要在其他项目中使用，请参照 其他项目配置demo 以及
gitlab-ci.yml配置文档

生成徽章

在pipeline setting里面可以找到指定分支的徽章地址，加入到README里面即可 :)

其他有用参考

• 重温大师经典：Martin Fowler的持续集成
• 持续集成是什么？阮一峰
• 基于Gitlab CI搭建持续集成环境
• 用 GitLab CI 进行持续集成