如果你已经在使用 GitLab 管理代码那么 GitLab CI/CD 是最自然的选择——它内置在 GitLab 中无需额外部署 Jenkins 服务器。本章从零开始介绍 GitLab CI/CD 的核心概念Pipeline、Job、Stage、Runner以及 .gitlab-ci.yml 的语法。通过一个完整的示例你将学会如何用 YAML 文件定义 CI/CD 流水线。一、GitLab CI/CD 核心概念GitLab CI/CD 是 GitLab 内置的持续集成与持续交付功能与代码仓库无缝集成。核心规则同一个 Stage 中的 Job 并行执行。只有当前 Stage 的所有 Job 都成功后才会进入下一个 Stage。任何一个 Job 失败Pipeline 立即停止除非配置了 allow_failure: true。二、RunnerCI/CD 的执行引擎Runner 是 GitLab CI/CD 的执行器负责运行 Pipeline 中的 Job。GitLab 提供两种 Runner2.1 安装 GitLab RunnerLinux# 添加官方仓库curl-Lhttps://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh|sudobash# 安装sudoapt-getinstallgitlab-runner2.2 注册 Runnersudogitlab-runner register按提示输入GitLab 实例 URL如 https://gitlab.com 或自托管地址。注册 Token在项目 → Settings → CI/CD → Runners 中获取。描述如 docker-runner。标签如 docker用于指定 Runner 执行特定 Job。执行器选择 docker最常用或 shell、kubernetes 等。2.3 使用 Docker 执行器注册时选择 docker 执行器后每个 Job 会在一个新的 Docker 容器中运行保证环境隔离和一致性。# 注册时设置默认镜像Please enter the default Docker image: alpine:latest三、.gitlab-ci.yml声明式流水线定义GitLab CI/CD 的流水线通过项目根目录下的 .gitlab-ci.yml 文件定义。这是一个 YAML 文件GitLab 在每次代码推送时自动解析并执行。3.1 最简示例# 定义 Stages按顺序执行stages:-build-test-deploy# 每个 Job 属于一个 Stagebuild-job:stage:buildscript:-echo 正在编译代码...-mvn clean compiletest-job:stage:testscript:-echo 正在运行测试...-mvn testdeploy-job:stage:deployscript:-echo 正在部署到生产环境...-scp target/*.jaruserserver:/app/3.2 一个更完整的示例# 定义变量variables:MAVEN_OPTS:-Dmaven.repo.local.m2/repositoryDOCKER_REGISTRY:registry.gitlab.comIMAGE_TAG:$CI_COMMIT_SHORT_SHA# 定义 Stagesstages:-build-test-package-deploy# 缓存 Maven 依赖加速后续构建cache:paths:-.m2/repository/# 使用 Docker 镜像作为执行环境image:maven:3.8.4-openjdk-17# Build Jobbuild:stage:buildscript:-mvn clean compileartifacts:paths:-target/classes/# Test Job并行执行test:unit:stage:testscript:-mvn testartifacts:paths:-target/surefire-reports/reports:junit:target/surefire-reports/*.xmltest:integration:stage:testscript:-mvn verify-Pintegration-testallow_failure:true# 集成测试失败不阻断 Pipeline# Package Job打包并构建镜像package:stage:packageimage:docker:latestservices:-docker:dindscript:-docker build-t $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG .-docker push $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAGonly:-main# Deploy Job仅 main 分支触发deploy:stage:deployscript:-echo 部署 $IMAGE_TAG 到生产环境...environment:name:productionurl:https://myapp.example.comonly:-mainwhen:manual# 需要手动触发四、核心语法详解4.1 stages定义阶段顺序stages 定义了 Pipeline 的执行顺序Job 按照所属 Stage 的顺序依次执行。stages:-build-test-deploy未指定 stage 的 Job 默认属于 test 阶段。4.2 script执行命令script 是 Job 的核心包含要执行的 Shell 命令。job:script:-echo Hello-mvn clean package4.3 before_script 与 after_script在所有 Job 之前/之后执行的通用脚本before_script:-echo 开始执行 Pipeline...-apt-get update-qqafter_script:-echo Pipeline 执行结束-rm-rf /tmp/*4.4 cache 与 artifactscache:paths:-.m2/repository/artifacts:paths:-target/*.jarexpire_in:1 week# 1 周后自动清理4.5 only / except控制触发条件 yaml# 仅在 main 分支触发job:only:-main# 仅在 Tag 触发job:only:-tags# 排除特定分支job:except:-develop4.6 when控制执行时机deploy:when:manual# 需要人工点击按钮触发4.7 environment部署环境管理deploy:environment:name:productionurl:https://myapp.example.comGitLab 会记录每次部署到该环境的历史版本支持一键回滚。4.8 rules高级条件控制推荐rules 是 only/except 的增强版支持更复杂的逻辑job:rules:-if:$CI_COMMIT_BRANCH mainwhen:on_success-if:$CI_COMMIT_BRANCH developwhen:manualallow_failure:true-when:never# 其他情况不执行五、多分支自动构建GitLab CI/CD 天然支持多分支每个分支的代码推送都会触发独立的 Pipeline。只需在 .gitlab-ci.yml 中使用 only 或 rules 控制不同分支的行为即可。# main 分支完整构建 部署到生产build-and-deploy-main:stage:deployscript:-./deploy.sh productiononly:-main# develop 分支构建 部署到测试环境build-and-deploy-develop:stage:deployscript:-./deploy.sh stagingonly:-develop六、合并请求Merge Request流水线GitLab CI/CD 可以在合并请求触发时自动运行 Pipeline帮助在合并前验证代码质量。# 在 MR 中运行测试但不部署test-mr:stage:testscript:-mvn testonly:-merge_requestsexcept:-main七、实战Spring Boot 项目的完整 CI/CD# .gitlab-ci.ymlstages:-build-test-package-deployvariables:MAVEN_OPTS:-Dmaven.repo.local.m2/repositoryDOCKER_REGISTRY:registry.gitlab.comIMAGE_TAG:$CI_COMMIT_SHORT_SHAcache:paths:-.m2/repository/image:maven:3.8.4-openjdk-17# 构建build:stage:buildscript:-mvn clean compileartifacts:paths:-target/classes/# 测试并行test:unit:stage:testscript:-mvn testartifacts:reports:junit:target/surefire-reports/*.xmltest:integration:stage:testscript:-mvn verify-Pintegrationallow_failure:true# 打包镜像仅 main 分支package:stage:packageimage:docker:latestservices:-docker:dindscript:-docker build-t $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG .-docker push $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAGonly:-maindependencies:-build# 部署到测试环境develop 分支自动部署deploy-staging:stage:deployscript:-echo 部署到 Staging 环境...-kubectl set image deployment/myapp myapp$DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG-n stagingenvironment:name:stagingurl:https://staging.myapp.example.comonly:-develop# 部署到生产环境main 分支手动触发deploy-production:stage:deployscript:-echo 部署到 Production 环境...-kubectl set image deployment/myapp myapp$DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG-n productionenvironment:name:productionurl:https://myapp.example.comonly:-mainwhen:manual八、GitLab CI vs Jenkins核心差异九、小结GitLab CI/CD 将代码仓库与 CI/CD 流水线融为一体通过简洁的 YAML 语法定义构建、测试、部署流程。Runner 是执行引擎支持 Docker、Shell、Kubernetes 等多种执行器。对于已经在使用 GitLab 的团队GitLab CI 是最自然、最低门槛的选择。
第六章：GitLab CI 从零到一：Runner 配置与 YAML 语法
如果你已经在使用 GitLab 管理代码那么 GitLab CI/CD 是最自然的选择——它内置在 GitLab 中无需额外部署 Jenkins 服务器。本章从零开始介绍 GitLab CI/CD 的核心概念Pipeline、Job、Stage、Runner以及 .gitlab-ci.yml 的语法。通过一个完整的示例你将学会如何用 YAML 文件定义 CI/CD 流水线。一、GitLab CI/CD 核心概念GitLab CI/CD 是 GitLab 内置的持续集成与持续交付功能与代码仓库无缝集成。核心规则同一个 Stage 中的 Job 并行执行。只有当前 Stage 的所有 Job 都成功后才会进入下一个 Stage。任何一个 Job 失败Pipeline 立即停止除非配置了 allow_failure: true。二、RunnerCI/CD 的执行引擎Runner 是 GitLab CI/CD 的执行器负责运行 Pipeline 中的 Job。GitLab 提供两种 Runner2.1 安装 GitLab RunnerLinux# 添加官方仓库curl-Lhttps://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh|sudobash# 安装sudoapt-getinstallgitlab-runner2.2 注册 Runnersudogitlab-runner register按提示输入GitLab 实例 URL如 https://gitlab.com 或自托管地址。注册 Token在项目 → Settings → CI/CD → Runners 中获取。描述如 docker-runner。标签如 docker用于指定 Runner 执行特定 Job。执行器选择 docker最常用或 shell、kubernetes 等。2.3 使用 Docker 执行器注册时选择 docker 执行器后每个 Job 会在一个新的 Docker 容器中运行保证环境隔离和一致性。# 注册时设置默认镜像Please enter the default Docker image: alpine:latest三、.gitlab-ci.yml声明式流水线定义GitLab CI/CD 的流水线通过项目根目录下的 .gitlab-ci.yml 文件定义。这是一个 YAML 文件GitLab 在每次代码推送时自动解析并执行。3.1 最简示例# 定义 Stages按顺序执行stages:-build-test-deploy# 每个 Job 属于一个 Stagebuild-job:stage:buildscript:-echo 正在编译代码...-mvn clean compiletest-job:stage:testscript:-echo 正在运行测试...-mvn testdeploy-job:stage:deployscript:-echo 正在部署到生产环境...-scp target/*.jaruserserver:/app/3.2 一个更完整的示例# 定义变量variables:MAVEN_OPTS:-Dmaven.repo.local.m2/repositoryDOCKER_REGISTRY:registry.gitlab.comIMAGE_TAG:$CI_COMMIT_SHORT_SHA# 定义 Stagesstages:-build-test-package-deploy# 缓存 Maven 依赖加速后续构建cache:paths:-.m2/repository/# 使用 Docker 镜像作为执行环境image:maven:3.8.4-openjdk-17# Build Jobbuild:stage:buildscript:-mvn clean compileartifacts:paths:-target/classes/# Test Job并行执行test:unit:stage:testscript:-mvn testartifacts:paths:-target/surefire-reports/reports:junit:target/surefire-reports/*.xmltest:integration:stage:testscript:-mvn verify-Pintegration-testallow_failure:true# 集成测试失败不阻断 Pipeline# Package Job打包并构建镜像package:stage:packageimage:docker:latestservices:-docker:dindscript:-docker build-t $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG .-docker push $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAGonly:-main# Deploy Job仅 main 分支触发deploy:stage:deployscript:-echo 部署 $IMAGE_TAG 到生产环境...environment:name:productionurl:https://myapp.example.comonly:-mainwhen:manual# 需要手动触发四、核心语法详解4.1 stages定义阶段顺序stages 定义了 Pipeline 的执行顺序Job 按照所属 Stage 的顺序依次执行。stages:-build-test-deploy未指定 stage 的 Job 默认属于 test 阶段。4.2 script执行命令script 是 Job 的核心包含要执行的 Shell 命令。job:script:-echo Hello-mvn clean package4.3 before_script 与 after_script在所有 Job 之前/之后执行的通用脚本before_script:-echo 开始执行 Pipeline...-apt-get update-qqafter_script:-echo Pipeline 执行结束-rm-rf /tmp/*4.4 cache 与 artifactscache:paths:-.m2/repository/artifacts:paths:-target/*.jarexpire_in:1 week# 1 周后自动清理4.5 only / except控制触发条件 yaml# 仅在 main 分支触发job:only:-main# 仅在 Tag 触发job:only:-tags# 排除特定分支job:except:-develop4.6 when控制执行时机deploy:when:manual# 需要人工点击按钮触发4.7 environment部署环境管理deploy:environment:name:productionurl:https://myapp.example.comGitLab 会记录每次部署到该环境的历史版本支持一键回滚。4.8 rules高级条件控制推荐rules 是 only/except 的增强版支持更复杂的逻辑job:rules:-if:$CI_COMMIT_BRANCH mainwhen:on_success-if:$CI_COMMIT_BRANCH developwhen:manualallow_failure:true-when:never# 其他情况不执行五、多分支自动构建GitLab CI/CD 天然支持多分支每个分支的代码推送都会触发独立的 Pipeline。只需在 .gitlab-ci.yml 中使用 only 或 rules 控制不同分支的行为即可。# main 分支完整构建 部署到生产build-and-deploy-main:stage:deployscript:-./deploy.sh productiononly:-main# develop 分支构建 部署到测试环境build-and-deploy-develop:stage:deployscript:-./deploy.sh stagingonly:-develop六、合并请求Merge Request流水线GitLab CI/CD 可以在合并请求触发时自动运行 Pipeline帮助在合并前验证代码质量。# 在 MR 中运行测试但不部署test-mr:stage:testscript:-mvn testonly:-merge_requestsexcept:-main七、实战Spring Boot 项目的完整 CI/CD# .gitlab-ci.ymlstages:-build-test-package-deployvariables:MAVEN_OPTS:-Dmaven.repo.local.m2/repositoryDOCKER_REGISTRY:registry.gitlab.comIMAGE_TAG:$CI_COMMIT_SHORT_SHAcache:paths:-.m2/repository/image:maven:3.8.4-openjdk-17# 构建build:stage:buildscript:-mvn clean compileartifacts:paths:-target/classes/# 测试并行test:unit:stage:testscript:-mvn testartifacts:reports:junit:target/surefire-reports/*.xmltest:integration:stage:testscript:-mvn verify-Pintegrationallow_failure:true# 打包镜像仅 main 分支package:stage:packageimage:docker:latestservices:-docker:dindscript:-docker build-t $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG .-docker push $DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAGonly:-maindependencies:-build# 部署到测试环境develop 分支自动部署deploy-staging:stage:deployscript:-echo 部署到 Staging 环境...-kubectl set image deployment/myapp myapp$DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG-n stagingenvironment:name:stagingurl:https://staging.myapp.example.comonly:-develop# 部署到生产环境main 分支手动触发deploy-production:stage:deployscript:-echo 部署到 Production 环境...-kubectl set image deployment/myapp myapp$DOCKER_REGISTRY/$CI_PROJECT_PATH:$IMAGE_TAG-n productionenvironment:name:productionurl:https://myapp.example.comonly:-mainwhen:manual八、GitLab CI vs Jenkins核心差异九、小结GitLab CI/CD 将代码仓库与 CI/CD 流水线融为一体通过简洁的 YAML 语法定义构建、测试、部署流程。Runner 是执行引擎支持 Docker、Shell、Kubernetes 等多种执行器。对于已经在使用 GitLab 的团队GitLab CI 是最自然、最低门槛的选择。
