深入浅出gitlab CI

日常开发中，如何提升交付效率，打造高效、灵活、高可用的 CI(持续集成) /CD(持续交付)系统，一直是老生常谈的话题。这方面已经有很多的开源项目与工具，比如Jenkins、Travis 以及本文要谈到的GitLab CI。

gitlab CI的介绍

先引入GitLab官方文档里的一张图，可以让我们更加方便的了解 CI/CD 做了哪些事情。

从左往右看，首先是gitlab里面代码的提交，gitlab触发runner去执行定义好的服务(包括build/unit test等)。

接着就是codeReview，预发布，正式部署到线上。

每家公司的流程大致都是如此，利用好自动化的CI流程，就可以大大加快开发迭代的速度了。

GitLab CI 相关术语

Job，它是最小的任务单元，只负责一件事情，编译/测试等；
Stage，阶段，每一个 Job 都会有一个阶段，一个阶段可以包含多个 Job。阶段是有先后顺序的。通过 stage 可以间接的控制 Job 执行的先后顺序；
Pipeline，多个 Stage 有顺序的排列就是 Pipeline，流水线；
GitLab Runner，是实际处理 Job 的，每个 Runner 可以单独配置，Runner 支持多种类型的 Job，同一时间单个 runner 只能处理一个 Job；
Executor，每个 Runner 都需要指定一个 Executor，来决定 runner 最终使用哪个执行器进行处理。（下面的项目中使用的shell，也可以选用docker等）

一个典型的 Pipeline如上，一共有 5 个阶段，Build，Test，Release， Staging， Production，每个阶段里都至少有一个 Job，Test 中有两个 Job。GitLab 会从左往右依次把任务给到 Runner 处理，默认情况下如果中途有一个任务没有处理成功，则整个 Pipeline 就会退出。

Gitlab Runner

GitLab-Runner通过http，接收处理gitlab的定义pipeline。 runner可以安装在不同的机器上。

更具体的gitlab runner安装配置等本篇不予讨论，有兴趣可以看下面的相应链接查看或自行谷歌。

gitLab runner: www.cnblogs.com/cnundefined…

配置(.gitlab-ci.yml)

yml语法传送门，learnxinyminutes.com/docs/yaml/

# 定义需要执行哪些阶段，默认情况下按顺序执行
# 默认情况下，前面一个阶段执行成功后，下一个阶段方可执行
stages:
  - build
  - deploy

# 定义变量
variables:
  GIT_CLEAN_FLAGS: none

# build任务
build:
  # 此任务属于build同名阶段，前面有说，一个阶段可以有多个任务，多个任务会并行执行
  stage: build
  variables:
    NODE_ENV: production
    BOSS_ENV: test
  # 相对应的runner配置的是shell，下面将以shell脚本执行
  script:
    - yarn --production=false
    - NODE_ENV=$NODE_ENV BOSS_ENV=$BOSS_ENV yarn build
  # 执行中间产物，将要传递给下一个阶段
  # 也会出现在gitlab pipleline页面，可供查看及下载
  artifacts:
    expire_in: 1 week
    paths:
      - dist
  # 绑定标签为`vue`的runner执行操作
  tags:
    - vue
  # 只有test分支有提交时，才会进行相应的动作
  only:
    - test

# deploy 阶段配置大致相同，省略不聊

更详情具体的配置请看官方配置文档：yaml

开发福利

对应上面的gitlab-ci配置，我们开发到测试环境时，只需要把改动合并到test分支就行了，免去了之前的自己提工单的麻烦。

之所以要自己合test分支呢，文件冲突自己解决嘛，没有了boss系统的文件锁定功能，难免会有文件冲突产生。

当然最重要的还是要保持提交前合master的好习惯。

完成了上面的步骤后，就欣赏下gitlab的漂亮美观的可视化pipeline界面了。下面的贴图以某一个项目为例。

pipeline列表，可以清楚的看到每个stage的通过情况及总的执行时间

单个pipeline里面的job也是清楚可见，执行结果一目了然，包括artifacts(可以理解为部署产物)也是可以下载及在线查看的

教科书级别的pipeline，可以看到state里面的job是可以并行执行的

job的执行日志也是清楚可见的呢

可在线查看的artifacts(可以理解为部署产物)也是可以下载及在线查看的，artifacts需要在job里面配置

其他配套配置

消息推送结合Integrations可以扩展其他功能，这里选用Pipelines emails来进行执行结果通知

只想收到与自己有关的提醒怎么弄？有办法的，打开通知设定，选中关闭其他提醒即可。

未来可期

使用企业微信机器人，在相关群里进行@指定人的消息推送，避免foxmail没打开的情况
use docker image 对于前端来说，哪天上了nodejs应用，可以试下了

其他可选方案

webhook

webhook监听到相应的钩子触发时，去请求定义好的URL，由URL对应的服务去完成后续的操作，也就需要自己单独专门写一个后端服务了，项目之间并不能很好的共用。

jenkins

与gitlab CI的对比：不足：

部署配置与代码仓库分离，不利于开发人员自身维护
缺少对于docker与k8s的天然支持

其他的一些比较可参考：about.gitlab.com/devops-tool… www.thecodecampus.de/blog/jenkin…

我的博客即将同步至腾讯云+社区，邀请大家一同入驻：cloud.tencent.com/developer/s…