关于GitLab CI常用策略 | 许大仙的博客

正好今晚处理了博客的SEO问题，配置了一下GitHub Action，就顺便回顾一下GitLab CI常用的策略吧。

背景

GitHub是一款非常优秀的产品，但企业还是更倾向于在内部自建仓库，所以在运维流程上，还是接触的GitLab稍多一些。

我刚来的时候公司运维环节比较薄弱，所以还是沿用之前的GitLab CI/CD流程，故学习了一阵，如果你们还没有完善的CI/CD流程，建议使用Jenkins。

简介

在GitLab CI上常用的动作

单元测试，跑完之后会有个测试覆盖率，部分企业会作为发布的硬性标准。
质量评估，可能会运行语法检测，或者集成一些第三方的代码质量管理平台，例如Sonar
打包容器，现在是云原生时代，建议使用，更多的应该关注业务本身，不应该过多的把时间花在重复配置环境上。

至于部署？

实际生产上，从来都不会把部署的工作放到GitLab上做，不可控因素太多了。

除非就几个人的创业公司，为了省事，可以这样做。

言归正传，我们先看下完整的构建配置.gitlab-ci.yml

stages:
  - unitest
  - qa
  - build

variables:
  Name: example

before_script:
  - echo "run script"

job-unitest:
    stage: unitest

job-qa:
    stage: qa

job-build:
    stage: build

相比乱七八糟的教程，常用的就这么几种

stages，定义这个构建有几个流程，会按顺序执行下去，分别对应的job的stage字段
variables，定义环境变量，在之后的流程中可以引用它。
before_script，流程开始前，执行的准备工作，可以完成一些配置性的工作。
job-xxx，这个名字是可以随意定义的，只要stage字段匹配即可。

单元测试流程

也就是我们介绍的stage: unitest阶段，名称为job-unitest，可以随意定义。

拿Python举例，常用的方案会使用pytest进行单元测试工作，同时生成一个测试报告。

job-unitest:
    stage: unitest
    tags:
      - docker
    image: python:3
	script:
    	- pytest --junit-xml=report.xml

额外介绍一些tags，它的可选项一般为shell和docker作为它的Runner，建议使用后者，需要在编译Runner的时候集成docker。

shell模式的问题：会直接用Runner宿主机的shell命令，在多Runner环境下，要保证每台机器都要配置依赖环境，非常麻烦。同时在以后的Runner升级工作中，可能会有未知的风险。

另外一种场景是，应用可能依赖数据库，那么配置就会变成这样。

job-unitest:
    stage: unitest
    tags:
      - docker
    image: python:3
    services:
      - mysql:5.7
	script:
    	- pytest --junit-xml=report.xml

使用数据库的官方文档 GitLab CI MySQL

需要注意的是，MySQL的User字段可能为root，官方文档显示的是runner，注意对应版本。

友情提示：不会真有人忘记创建DB吧？

容器打包流程

这个阶段没什么好说的，无外乎使用Dockerfile，进行build、push工作，直接给个范例。

job-bulid:
    stage: build
    tags:
      - docker
    services:
    	- docker:dind
    image: docker:latest
    script:
      - docker build -t ${Name}:1.0 .
      - docker push

这里唯一要注意的，只有docker:dind这个服务，它是必须要存在的，否则会报错。

还记得之前我们定义过一个变量，这里就用上了。

push的命令我没有补全，自行查找文档。

睡了狗命要紧。