如果你已经在使用 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二、GitLab RunnerCI/CD 的执行引擎Runner 是 GitLab CI/CD 的执行器负责运行 Pipeline 中的 Job。2.1 安装 GitLab RunnerLinux# 下载 GitLab Runner 二进制文件curl-L--output/usr/local/bin/gitlab-runner\https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64sudochmodx /usr/local/bin/gitlab-runner# 创建 gitlab-runner 用户并启动服务sudouseradd--commentGitLab Runner--create-home gitlab-runner--shell/bin/bashsudogitlab-runnerinstall--usergitlab-runner --working-directory/home/gitlab-runnersudogitlab-runner start2.2 注册 Runnersudogitlab-runner register按提示输入GitLab 实例 URL如 https://gitlab.com 或自托管地址注册 Token在项目 → Settings → CI/CD → Runners 中获取描述如 docker-runner标签如 docker用于在 .gitlab-ci.yml 中指定 Runner执行器选择 docker最常用或 shell2.3 使用 Docker 执行器推荐选择 docker 执行器后每个 Job 会在一个新的 Docker 容器中运行保证环境隔离和一致性。注册时设置默认镜像textPlease enter the default Docker image: alpine:latest2.4 配置 Runner 使用 Docker-in-DockerDinD如果 Job 需要构建 Docker 镜像需要配置 Runner 支持 Docker-in-Docker。编辑 /etc/gitlab-runner/config.tomltoml[[runners]]executor “docker”[runners.docker]image “alpine:latest”privileged falsevolumes [“/var/run/docker.sock:/var/run/docker.sock”,“/cache”]⚠️ 注意使用 privileged false 更安全。如果无法使用 Docker-in-Docker可以挂载宿主机的 Docker socket。三、.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: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 的执行顺序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 week4.5 only / except控制触发条件# 仅在 main 分支触发job:only:-main# 仅在 Tag 触发job:only:-tags4.6 when控制执行时机yamldeploy:when: manual4.7 environment部署环境管理deploy:environment:name:productionurl:https://myapp.example.comGitLab 会记录每次部署到该环境的历史版本支持一键回滚。五、在 GitLab UI 中查看 Pipeline代码推送后Pipeline 会自动触发。在 GitLab 项目中点击左侧菜单 CI/CD → Pipelines查看 Pipeline 列表及其状态passed、failed、running、pending点击 Pipeline ID 查看详细 Stages 和 Jobs点击 Job 名称查看实时日志六、GitLab CI vs Jenkins核心差异七、小结GitLab CI/CD 将代码仓库与 CI/CD 流水线融为一体通过简洁的 YAML 语法定义构建、测试、部署流程。Runner 是执行引擎支持 Docker、Shell、Kubernetes 等多种执行器。对于已经在使用 GitLab 的团队GitLab CI 是最自然、最低门槛的选择。