Gitlab CI/CD 实践总结
11月 15, 2018
Gitlab 的 CI/CD 功能可能是区别于 GitHub 的一个最有价值的功能之一。接触了 CI/CD 以来，很多以前需要手动测试、打包、部署的工作，现在都可以通过编写 .gitlab-ci.yml 来实现了，一方面持久化、规范化了部署服务的操作流程，另一方面 CI/CD 功能与 Gitlab 深度结合，方便了开发测试流程，下面总结下最常用到的功能。
概念 #
CI/CD #
在软件工程中，CI/CD 通常指的是持续集成（Continuous Integration）和持续交付（Continuous Delivery）或持续部署（Continuous Deployment）的组合实践。现代 DevOps 实践涉及软件应用程序在整个开发生命周期内的持续开发、持续测试、持续集成、持续部署和持续监控，CI/CD 实践构成了现代 DevOps 业务的主干1。
Pipeline #
Pipelines are the top-level component of continuous integration, delivery, and deployment.
Pipeline（生产线、管线），由 Jobs（任务） 和 Stages（阶段） 两部分组成，是每条定义的 CI/CD 的全部执行过程，每个 Stage 可以运行多个 Jobs，比如：
- Build
- build frontend
- build backend
- Test
- test frontend
- test backend
- Deploy
- deploy frontend
- deploy backend
可以通过以下方式来开启一个 Pipeline：
- 手动点击触发；
- 通过计划表（Schedule）触发
- 通过触发器（Trigger）触发
默认情况下 Gitlab 已经开启了 Pipeline 的执行，意味着每一次代码提交都会触发执行，Pipeline 的执行也可以重试和取消。
Schedule #
通过 Schedule（计划表）可以定义在什么情况下触发 CI/CD 的执行，比如每天早上 5 点针对 maser 分支执行一次 Pipeline。
Runner #
所有的 Pipeline 是在 Gitlab Runner 里执行的，Runner 根据 .gitlab-ci.yml 定义的执行步骤和执行命令逐一进行执行。
如果使用的是 Gitlab 的官网服务，Gitlab 有一些公开的 Shared runners 可以直接使用，但是有一定的限额，如果是自建的 Gitlab 服务，也可以自己搭建 Runner 服务器。
Variables #
在 CI/CD 的执行过程中，很多时候会需要敏感信息，比如登陆服务器的 SSH 的密码。可以在 Variables 里面进行设置，然后在 .gitlab-ci.yml 进行引用即可。
配置文件 #
CI/CD 的具体执行的工作内容由项目根目录下的 .gitlab-ci.yml 文件进行配置，在提交后满足，文件中的内容会由 Runner 进行执行，这里对一些文件里常用的关键字进行总结以了解其核心功能。
image #
指定了执行任务（Job）的容器基于的 Docker 镜像，即不同 Job 可以有不同的镜像。
stage #
stage 指定了 Pipeline 的各个阶段，并对 Job 进行了分组，每个阶段执行声明了指定 stage 的 job。
stages:
- build
- test
- deploy
job1:
stage: build
script:
- echo "This job compiles code."
job2:
stage: test
script:
- echo "This job tests the compiled code. It runs when the build stage completes."
job3:
script:
- echo "This job also runs in the test stage".
job4:
stage: deploy
script:
- echo "This job deploys the code. It runs when the test stage completes."
before_script #
可以是一组命令，定义了在 Job 执行前的一些准备工作。
script #
可以是一组命令，定义了 Job 执行的具体工作。
after_script #
可以是一组命令，定义了在 Job 执行后的一些收尾工作。
job:
before_script:
- echo "Execute this command before any 'script:' commands."
script:
- echo "An example script section."
after_script:
- echo "Execute this command after the `script` section completes."
when #
定义了 Job 何时执行，枚举有：
- on_success
- manual
- always
- on_failure
- delayed
- never
coverage #
值为一个正则表达式，定义了准确地如何从 Job 的 output 中提取 coverage 的值，并最终会将结果显示在 Gitlab 的 Pipeline UI 界面中。
job1:
script: rspec
coverage: '/Code coverage: \d+\.\d+/'
比如上面的 \d+\.\d+/ 就可以提取到字符串 Code coverage: 67.89% of lines covered 中的 67.89。
default #
有一些关键字可以通过 default 声明在全局环境里，然后在一些特殊的 Job 里又可以被替换，以实现灵活的配置，以下的关键字可以被声明在 default 里面：
举例 #
default:
image: ruby:3.0
rspec:
script: bundle exec rspec
rspec 2.7:
image: ruby:2.7
script: bundle exec rspec
更多详细的关键词请参考 GitLab CI/CD YAML文件配置，更多语言的 demo 可以参考官方提供 GitLab CI/CD Examples 。
Variables #
可以自定义一些变量，然后在后续的地方通过 $xxx 重复使用。Gitlab 也提供了一些定义好的变量，比如在打包、打 tag 的情况下使用，都非常实用，请参考 Predefined variables reference。
variables:
DEPLOY_SITE: "https://example.com/"
deploy_job:
stage: deploy
script:
- deploy-script --url $DEPLOY_SITE --path "/"
deploy_review_job:
stage: deploy
variables:
REVIEW_PATH: "/review"
script:
- deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH