niudrw1. GitLab CI/CD Pipeline基础概念解析
在软件开发领域，持续集成和持续交付（CI/CD）已经成为现代DevOps实践的核心组成部分。GitLab作为一款强大的DevOps平台，其内置的CI/CD功能允许开发团队自动化构建、测试和部署流程。Pipeline（流水线）是GitLab CI/CD的核心执行单元，它由一系列按顺序或并行执行的作业（Job）组成，每个作业代表一个独立的执行环境。
.gitlab-ci.yml文件是GitLab CI/CD的配置文件，采用YAML语法编写，存放在项目根目录下。这个文件定义了Pipeline的结构和行为，包括：
- 需要执行哪些作业
- 这些作业在什么条件下运行
- 它们之间的依赖关系
- 执行环境要求等
当开发者将代码推送到GitLab仓库时，系统会自动检测.gitlab-ci.yml文件的存在，并根据文件内容创建并执行Pipeline。这种自动化机制显著减少了人工干预，提高了软件交付的效率和质量。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 创建基础.gitlab-ci.yml文件
2.1 文件结构与基本元素
一个最简单的.gitlab-ci.yml文件只需要包含作业定义。以下是一个基础模板：
yaml复制stages:
- build
- test
- deploy
build_job:
stage: build
script:
- echo "Building the application..."
- make build
test_job:
stage: test
script:
- echo "Running tests..."
- make test
deploy_job:
stage: deploy
script:
- echo "Deploying to production..."
- make deploy
only:
- main
这个配置文件定义了三个阶段（stage）和对应的三个作业。每个作业都属于特定的阶段，并包含一系列要执行的shell命令。
2.2 关键配置项说明
- stages：定义Pipeline中的阶段顺序，作业将按照阶段顺序执行
- stage：指定作业所属的阶段
- script：作业要执行的实际命令
- only：限制作业在特定条件下运行（如仅main分支）
在实际项目中，我们通常会需要更复杂的配置。比如，你可能希望测试作业只在构建成功后运行，或者部署作业需要手动触发。这些都可以通过GitLab CI/CD的丰富配置选项实现。
3. 配置提交触发机制
3.1 自动触发条件设置
GitLab Pipeline默认会在以下情况下自动触发：
- 代码推送到仓库（包括分支、标签和合并请求）
- 手动通过UI界面触发
- 通过API调用触发
- 定时触发（Pipeline schedules）
要让Pipeline在代码提交后自动运行，最简单的做法就是在.gitlab-ci.yml中不做任何特殊限制。但更常见的做法是使用rules或only/except关键字进行精确控制：
yaml复制build_job:
stage: build
script: make build
rules:
- if: '$CI_PIPELINE_SOURCE == "push"'
when: always
- if: '$CI_MERGE_REQUEST_IID'
when: never
这个配置表示：
- 当代码直接推送到仓库时（非合并请求），总是运行构建作业
- 当Pipeline由合并请求触发时，跳过构建作业
3.2 分支策略配置
针对不同的开发分支，我们通常需要不同的P