Gitlab CI/CD 实践总结

Gitlab CI/CD 实践总结

11月 15, 2018
DevOps, Tools

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

参考 #

https://docs.gitlab.com/ee/ci/introduction/

本文共 1423 字,上次修改于 Jul 9, 2024,以 CC 署名-非商业性使用-禁止演绎 4.0 国际 协议进行许可。

相关文章

» 使用 Github Pages 建立免费的静态网站

» Docker 使用笔记

» Vagrant 虚拟机 Ubuntu16.04 安装 MariaDB

» Ubuntu 下部署 Django 应用