目录

  • 简介
    • 持续集成
    • 持续部署
  • Gitlab CICD
    • 如何使用 Gitlab CI/CD
    • CICD 工作流
  • .gitlab-ci.yml 文件结构
    • stages
    • variables
    • before_script
    • test_stage
      • stage
      • script
      • artifacts
      • allow_failure
    • build_stage
      • when
      • only
    • deploy_stage

简介

CICD 是 持续集成(Continuous Integration)和持续部署(Continuous Deployment)简称。指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率,在新代码从开发到部署的过程中,尽量减少人工的介入。

持续集成

持续集成指在和向远程仓库 push 代码后,在这次提交合并入主分支前进行一系列测试,构建等流程。假设现在有个应用的代码存储在 gitlab 上,每天开发者都 push 很多次提交,针对每次 push,你可以创建一系列脚本进行自动测试,降低往应用里引入错误的概率。这就是持续集成,它可应用在包括开发分支在内的多个分支上。

持续部署

持续部署在持续集成的基础上更进一步,指将推送指仓库默认分支的部署至产品环境。如果这部分需要手动触发,这就是一个持续交付(Continuous Delivery)环节。

Gitlab CICD

Gitlab 内置了 CICD 工具,不需要使用第三方工具。

如何使用 Gitlab CICD

使用 Gitlab 的 CICD ,只需要在 Gitlab 的仓库的根目录中添加 .gitlab-ci.yml 文件。

这个文件中,可以定义CICD 的各个环节,配置每个环节执行的命令,触发方式等。这个配置文件其实就是按照 YAML 规定了一些结构的 shell 脚本,里面的命令会在符合条件时逐一执行。一旦在仓库中添加这个文件,Gitlab 会检测到它并用名为 Gitlab Runner 工具执行它。每次触发的 CICD 会把配置中的脚划分为不同的 job,多个 job 组成一个 pipeline。最简单的 .gitlab-ci.yml 文件可以包含:

before_script:
 - apt-get install rubygems ruby-dev -y

run-test:
  script:
    - ruby --version

其中 before_scripts 属性会在执行任一脚本前预装一些需要的依赖(类似 unittestsetUp 方法),此后名为 run-test 的脚本会显示当前系统的 ruby 版本。这两个步骤组成了一个 pipeline 会在这个仓库的每次push后执行。这行任务的执行情况也可以在 Gitlab 的对应页面上查看,就像在 Terminal 中看日志一样。

CICD执行日志

而每个 pipeline 的 job 的执行情况也可以在页面上查看

pipeline查看

如果中途报错了,可以一键回滚

回滚按钮

CICD 工作流

假设你在本地修改了一些代码以增加一些特性,当你把这些改动 push 到远程仓库的特性分支后,项目里设定的 CICD pipeline 就被触发了,一般流程如下:

  • 运行自动脚本(串行或并行):
    • 构建并测试应用
    • 在合并前 review 改动

上述流程如果没有问题就可以把改动合并入主分支,CD 会自动把它部署到产品中,如果发现了任何问题,还能一键回滚。

工作流程图如下:

workflow_chart

该图简要显示了基本的工作流,想要了解 Gitlab CICD 的更多特请,请参阅CICD 索引表

.gitlab-ci.yml 文件结构

.gitlab-ci.yml 是指定了 CICD 相关配置的 YAML 文件。(YAML 是专门用来写配置文件的语言,简洁强大,和 python 一样用缩进代表层级,表达能力和 JSON 基本一致,但格式更方便。相关知识可以参考阮昱峰老师的博文

一般而言,CICD 过程会包含如下最外层的 key:

  • stages: 定义整个 CICD pipeline 的 job 数量和名称
  • variables: 定义 CICD 流程中的一些环境变量
  • before_scripts: 在每个 jobscripts 执行前进行的命令集,一般是创建目录,打印 context 目录等操作,可类比 unittestsetUp 方法
  • stage: 定义了一个 job 的具体流程,可以在前面加上名称

下面通过一个例子进行一些讲解

stages:
  - test
  - build
  - deploy

variables:
  GIT_STRATEGY: none
  PROJECT_REPO_NAMESPACE: test
  PROJECT_REPO_NAME: cicd_learn
  DEPLOYMENT_REPO_NAMESPACE: test
  DEPLOYMENT_REPO_NAME: deploy_test

before_script:
  - export ROOT_PATH=$(pwd)
  - echo 'root path:' $ROOT_PATH
  - mkdir $PROJECT_REPO_NAME
  - cd $PROJECT_REPO_NAME
  - <some git manipulation here>
  - echo 'date:' $DATE

test_stage:
  stage: test
  script:
    - <test related command here>
  artifacts:
    paths:
      - xxxx.html
    when: always
  allow_failure: false

build_stage:
  stage: build
  script:
     - <build related command here>
  when: manual
  allow_failure: false
  only:
    - master

deploy:
  stage: deploy
  script:
    - <deploy related command here>
  allow_failure: false
  only:
    - master

stages

例子中 stages 值为一个数组(p.s. 用 - 代表数组和 markdown 类似)。包含了三个 jobtest, build, deployr 分别实现自动测试,打包项目和部署。下方的 stage 必须在全局定义的 stages 内。

variables

值为键值对象,为了后续的流程,此处定义了开发项目和部署项目的 namespace 和 repo_name。同 shell 类似,后续使用其值需要加上 $ 符号。定义的变量也有对应的作用域,定义在顶层就可以作为全局变量供所有 job 使用,如果是一些 job 特有的变量,就定义在 job 内部。

before_script

值为数组,每一个元素其实就是一个 linux 命令,写的时候装作自己在写 shell 就好。该部分主要生成了后续构建需要的镜像标签,切换当前目录等。为了 debug 方便,这些变量最好打印。类似的,如果在 job 完成后有一些时候操作,可以定义 after_script。需要注意的是如果定义在顶层,内部的命令会在每个 job 运行之前执行,如果某些 job 需要特别的预操作,可以在 job 内部再配置一个 before_script 对象,它会复写外部的全局预操作。

test_stage

名为 testjob 的具体配置,一般是个复合对象。

stage

job 对应的 stage,如果有多个 job 对应同一个 stage,在执行时会并行执行这些 job

script

这个 job 执行的命令,此处是进入的项目仓库目录,并且执行了一个 shell 脚本,这个脚本定义了执行项目的所有单元测试。一般建议如果要执行的命令过多,就把这些命令写成脚本放在项目内。CICD 流程直接执行这个脚本。

artifacts

这个对象用来定义 job 的产出,比如我们让 test_stage 产出一个 html 格式的报告,显示每个单元测试的执行情况(报告生成相关代码写在项目内)。 数组内的 pathswhen 分别定义报告的路径和产出场景。此处表示报告放置于根目录下,任何时候都要提供报告。设定正确后,就可以 Gitlab 的 pipline 页面上可以下载相关文件。

allow_failure

见名知意,如果值为 true,那么即使没通过测试,也可以执行后续的 job.

build_stage

该步骤在测试通过的基础上,把项目编译打包,方便后续部署。

when

此处的 when 定义在 job 内的顶层,值为 manual 表示其需要在 Gitlab 上手动触发(页面上点击按钮即可)。

only

only 指明了 job 的执行场景,可以是分支名,表明只有 master 分支可以执行 build,如果要用排除法反向指定,可以用 except

deploy_stage

所有的 key 现在你应该都了解了,这里不再赘述。这一步骤主要是将部署产品的服务器上的内容更新。