GitLab CI基于分支实现多环境部署的核心是用分支名作触发开关，配合rules判断$CI_COMMIT_BRANCH（如dev/test分支自动部署）或$CI_COMMIT_TAG（如v1.2.3标签手动触发生产部署），结合GitLab变量组或Helm values文件实现配置隔离，并通过environment字段声明环境归属，确保构建测试阶段通用、部署动作精准且敏感操作需人工确认。
GitLab CI 基于分支实现不同环境部署，核心是用分支名作为环境触发的“开关”，配合 rules 或 only 控制作业执行，再结合环境专属配置完成差异化部署。不依赖外部工具，一份 .gitlab-ci.yml 就能清晰分隔 dev/test/prod 等环境。
用分支名精准触发对应环境作业
每个环境部署作业只响应特定分支的提交，避免误触发。关键靠 rules 中的 $CI_COMMIT_BRANCH 判断：
-
开发环境（dev 分支）：部署脚本只在
dev分支推送时运行 -
测试环境（test 分支）：仅当提交到
test分支才触发 -
生产环境（main 分支打 tag）：不按分支，而是匹配语义化版本标签（如
v1.2.3），且设为when: manual强制人工确认
环境配置要独立、可复用
不同环境需要不同的服务地址、数据库连接、功能开关等。推荐两种轻量可靠的方式：
-
GitLab 变量组（Variables）：在项目 Settings → CI/CD → Variables 中为每个环境创建变量组（如
DEV_ENV、PROD_ENV），在对应作业中引用：variables: { API_URL: $PROD_API_URL } -
配置文件分离（Helm/Kustomize）：把环境差异抽成独立文件，比如
values-dev.yaml、values-prod.yaml，部署时通过参数指定：helm upgrade -f values-prod.yaml
部署动作要明确指向目标环境
作业本身需体现环境归属，便于追踪和管理：
- 使用
environment:字段声明环境名称和访问地址，GitLab 会自动聚合该环境下的所有部署记录，并提供回滚入口 - 部署命令需明确操作目标：例如
ssh deploy@192.168.1.41对应 dev 服务器，kubectl apply -f k8s/prod-ns.yaml针对生产命名空间 - 敏感操作（如 prod）必须加
when: manual，防止自动执行；也可配合审批规则（Approval Rules）要求指定角色确认
构建与测试阶段保持通用性
构建镜像、运行单元测试这类动作通常不随环境变化，应设计为共享阶段：
-
build阶段对所有分支生效，产出统一镜像或 jar 包，通过artifacts传递给后续部署作业 -
test阶段可并行执行多种测试（单元、集成、安全扫描），但跳过生产环境的测试（因rules已排除main分支） - 避免在部署作业里重复构建，既节省时间，也保证部署包一致性
