CI/CD是什么

CI/CD，代表继续集成（Continuous Integration）和继续交给/布置（Continuous Delivery/Continuous Deployment），是现代软件开发流程中的关键实践，旨在进步开发效率和软件质量。

  • CI（Continuous Integration）

    在遵从严格开发流程标准的项目中，开发人员向线上Git库房提交代码时，通常会主动触发一系列操作，包含主动构建、代码标准检测和主动化测验，这些操作共同构成了继续集成的进程。

    CI的好处是能够避免不符合标准的代码提交到线上库房，在一定程度上确保了代码的质量。

  • CD（Continuous deployment）

    在CI的基础上，CD进一步主动化了软件的发布流程或布置到出产环境的进程。

    CD的好处是能够使得软件发布/布置更高效。

GitLab供给了一套完整的CI/CD功用：PipeLine。

GitLab PipeLine基础知识

GitLab PipeLine有两个中心组件：runner和.gitlab-ci.yml文件

runner

runner是指来负责运行界说在.gitlab-ci.yml文件中的脚本和指令（CI/CD）的程序，runner有两种方式获取：

  • 运用布置在GitLab官方服务器上的runner。优点是无需装备，缺陷是要钱。

  • 运用布置在私有服务器/电脑上的runner。在私有服务器上装置runner的一起，在GitLab中注册该runner，除此之外，还需装备executor详细的可参考GitLab Runner | GitLab。

    优点是免费（除了服务器的钱），缺陷是要手动装备。

.gitlab-ci.yml文件

.gitlab-ci.yml文件是装备GitLab CI/CD的中心，坐落项目的根目录，GitLab会主动识别该文件来履行CI/CD。

Stage

在GitLab的Pipeline中，CI/CD进程被划分为多个阶段（stages），每个阶段包含了一组作业（jobs）。

阶段经过.gitlab-ci.yml文件中的stages字段界说：

stages:
  - build
  - test
  - deploy

如上述代码所示，界说了build 、 test和deploy三个阶段。界说的顺序即为履行顺序，这意味着在履行test阶段之前会先履行build ，然后再履行deploy。

Job

在GitLab的Pipeline中，每个阶段（stage）能够进一步划分为一个或多个作业（jobs）。

作业是Pipeline中的根本履行单元，用于界说履行特定任务的装备：

build_job:
  stage: build
  script:
    - echo "Building the project..."
    - build_command

如上述代码中所界说的build_job作业，包含了以下装备：

  • stage：指定该作业归于哪个阶段。
  • script：指定在履行该作业时要运行的指令列表。能够是构建指令、测验指令或任何其他shell指令。

以下是一个简单的.gitlab-ci.yml文件demo。

stages:
  - build
  - test
  - deploy
build_job:
  stage: build
  script:
    - echo "Building the project..."
    - build_command
test_job:
  stage: test
  script:
    - echo "Running tests..."
    - test_command
deploy_job:
  stage: deploy
  script:
    - echo "Deploying the project..."
    - deploy_command

.gitlab-ci.yml文件进阶参数

至此，信任各位读者对GitLab的Pipeline有大致的了解，能初步读懂自己公司的.gitlab-ci.yml文件或者写写简单的.gitlab-ci.yml了，下面介绍下在装备GitLab Pipeline进程中可能会用到的进阶参数。

rules

rules界说了规则，能够与workflow和job调配运用，常见的用法是用来界说流水线和作业的触发规则，以与workflow调配运用为例来介绍。

workflow界说了Pipeline的行为，其可与rules参数调配运用来界说什么情况下履行PipeLine。

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "api"'
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - if: '$CI_PIPELINE_SOURCE == "triggers"'
    - if: '$CI_PIPELINE_SOURCE == "schedules"'

上述代码的意思是如果流水线是由以下事件之一触发，则履行PipeLine：

  • 合并恳求事件（merge_request_event）
  • API调用（api）
  • Web操作（web）
  • 触发器（triggers）
  • 计划任务（schedules）

CI_PIPELINE_SOURCE是gitlab预界说的变量，代表触发PIPELine的事件，api和web等值详细的意思能够参考以下材料。

Choose when to run jobs | GitLab

tags

前面讲到过GitLab pipeline的中心之一是runner，tags参数的作用是指定履行job的runner。

build_job:
  stage: build
  tags: 
    - runner1
  script:
    - echo "Building the project..."
    - build_command

上述代码指定了build_job作业由runner1履行。

before_script:

界说在运行PipeLine前履行的指令。

before_script:
  - chmod  x ./gradlew
  - ./gradlew clean

variables

该变量统一界说.gitlab-ci.yml需求用到的变量，其优点是方便了变量的管理。

variables:
  GITLAB_CI_BUILD_ROOT_PATH: "gitlabci"
  GITLAB_CI_BUILD_SCRIPT_PATH: "${GITLAB_CI_BUILD_ROOT_PATH}/scripts"

当需求运用时，只需运用$或者${}将变量名包裹起来，如运用GITLAB_CI_BUILD_SCRIPT_PATH时。

- source ${GITLAB_CI_BUILD_SCRIPT_PATH}/gitlabci-envsetup.sh

其它进阶玩法详细能够参考官方文档CI/CD YAML syntax reference | GitLab。

写在最终

文章到这里就完毕啦，最终不得不吐槽一句GitLab的code review真难用，peace。