GitLab CI/CD流水线实战：多环境自动部署与流水线编排

从代码提交到生产发布，中间环节每多一次手工操作就多一分出错概率。GitLab CI/CD把构建、测试、部署串联成可复现的流水线，通过 .gitlab-ci.yml 文件声明式定义，配合 Runner 分布式执行，能够实现push即部署的全自动链路。本文给出多环境流水线的完整配置与常见踩坑点。

Runner部署与流水线基础配置

先在目标服务器注册Runner，与项目绑定：

# 安装并注册 runner（tag 用于分组）
gitlab-runner register \
  --url https://gitlab.example.com \
  --token 项目注册token \
  --executor docker \
  --docker-image alpine:latest \
  --tag-list docker

项目根目录创建 .gitlab-ci.yml，定义阶段与任务。流水线分构建、测试、部署三个阶段：

stages:
  - build
  - test
  - deploy

variables:
  IMAGE_TAG: "$CI_COMMIT_SHORT_SHA"

build-image:
  stage: build
  image: docker:stable
  services: [docker:dind]
  script:
    - docker build -t registry.example.com/app:${IMAGE_TAG} .
    - docker push registry.example.com/app:${IMAGE_TAG}

test:
  stage: test
  script:
    - npm ci
    - npm run test:unit

deploy-staging:
  stage: deploy
  environment: staging
  script:
    - kubectl set image deployment/app app=registry.example.com/app:${IMAGE_TAG} -n staging

多环境隔离：受保护分支与手动确认

生产发布不能与预发一样全自动。用 when: manual 加 environment: production 把生产部署设为手动触发，并限制在受保护分支执行：

deploy-production:
  stage: deploy
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
  script:
    - helm upgrade app ./deploy/charts/app --namespace prod --set image.tag=${IMAGE_TAG}

同时为项目配置多组环境变量：STAGING_* 与 PROD_* 分开，生产环境的密钥在CI/CD Settings中设置为 Protected，只在受保护分支流水线中注入，避免MR误触发泄露。

流水线失败告警与缓存策略

依赖下载是流水线耗时大头，使用GitLab缓存避免每次都全量拉取：

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - vendor/bundle/

在CI/CD界面配置Webhook通知飞书或钉钉，failure状态推送负责人。同时设置流水线超时（如30分钟）与重试次数，避免挂死的Job占用Runner资源。快速失败原则：把静态检查、单元测试放在最前面，坏代码在构建阶段就拦下，避免部署到一半才发现问题。

CI/CD演进建议

从项目实际出发，.gitlab-ci.yml 应保持单一职责：构建只做构建、测试只做测试、部署走统一入口脚本。任务矩阵复杂后拆分为include文件复用模板。回滚路径要与部署脚本同时交付，helm rollback 或镜像版本回退命令必须出现在部署Job中，回滚是发布能力的一部分。