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
字段定义:
yaml
stages:
- build
- test
- deploy
如上述代码所示,定义了build
、 test
和deploy
三个阶段。定义的顺序即为执行顺序,这意味着在执行test
阶段之前会先执行build
,然后再执行deploy
。
Job
在GitLab的Pipeline中,每个阶段(stage)可以进一步划分为一个或多个作业(jobs)。
作业是Pipeline中的基本执行单元,用于定义执行特定任务的配置:
yaml
build_job:
stage: build
script:
- echo "Building the project..."
- build_command
如上述代码中所定义的build_job
作业,包含了以下配置:
stage
:指定该作业属于哪个阶段。script
:指定在执行该作业时要运行的命令列表。可以是构建命令、测试命令或任何其他shell命令。
以下是一个简单的.gitlab-ci.yml文件demo。
yaml
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。
yaml
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。
yaml
build_job:
stage: build
tags:
- runner1
script:
- echo "Building the project..."
- build_command
上述代码指定了build_job作业由runner1执行。
before_script:
定义在运行PipeLine前执行的命令。
yaml
before_script:
- chmod +x ./gradlew
- ./gradlew clean
variables
该变量统一定义.gitlab-ci.yml需要用到的变量,其优点是方便了变量的管理。
yaml
variables:
GITLAB_CI_BUILD_ROOT_PATH: "gitlabci"
GITLAB_CI_BUILD_SCRIPT_PATH: "${GITLAB_CI_BUILD_ROOT_PATH}/scripts"
当需要使用时,只需使用或者{}将变量名包裹起来,如使用GITLAB_CI_BUILD_SCRIPT_PATH时。
yaml
- source ${GITLAB_CI_BUILD_SCRIPT_PATH}/gitlabci-envsetup.sh
其它进阶玩法具体可以参考官方文档CI/CD YAML syntax reference | GitLab。
写在最后
文章到这里就结束啦,最后不得不吐槽一句GitLab的code review真难用,peace。