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。