CI/CD流水线实战：GitLab CI从代码提交到生产部署

CI/CD流水线是现代软件交付的核心设施，它把代码提交、测试、构建、部署串成自动化流程，减少人工介入带来的失误。GitLab CI 因为与代码仓库同源配置，是团队落地持续交付的常见选择。本文用一份完整的 .gitlab-ci.yml 示例，讲解流水线的阶段划分、缓存策略和部署回滚。

CI/CD 流水线解决什么问题

没有流水线时，代码合并、手动测试、人工上线这些环节都依赖个体经验，出错率与耗时都高。CI/CD 把「提交代码」到「发布上线」的路径自动化：提交触发流水线，流水线完成测试与构建，通过后自动发布到目标环境。自动化带来的直接收益是可追溯、可回滚、可重复，任何一步失败都能定位到具体 Job。

流水线阶段划分与文件结构

.gitlab-ci.yml 位于仓库根目录，GitLab Runner 读取后执行。阶段用 stages 声明，按顺序执行，同阶段的 Job 默认并行。典型结构如下：

stages:
  - test
  - build
  - deploy

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .cache/

before_script:
  - npm config set registry https://registry.npmmirror.com

before_script 在每个 Job 运行前执行，适合放公共初始化命令。cache 缓存依赖目录，避免每个 Job 重新安装依赖，显著缩短流水线时间。

测试阶段：静态检查与单元测试

测试阶段包含 lint 和单测，两个 Job 可以并行。单测需要数据库时，用 services 关键字启动临时服务，测试结束自动销毁。

lint:
  stage: test
  script:
    - npm run lint
  only:
    - merge_requests
    - main

unit-test:
  stage: test
  script:
    - npm run test -- --coverage
  artifacts:
    reports:
      junit: junit.xml
    expire_in: 7 days

artifacts 里的 junit 报告会展示在 GitLab 测试面板上，方便查看失败用例。only 限定了分支范围，避免每次 push 都跑全量。

构建阶段：镜像构建与制品上传

构建产物一般直接打容器镜像，推到私有仓库。镜像 tag 用提交哈希作为唯一标识，方便追溯和回滚。

build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  script:
    - docker build -t registry.example.com/app:$CI_COMMIT_SHORT_SHA .
    - docker push registry.example.com/app:$CI_COMMIT_SHORT_SHA
  only:
    - main

镜像 tag 建议同时带 CI_COMMIT_SHORT_SHA 与 CI_COMMIT_TAG，发布版本用 tag 标记，方便回滚到旧版本。

部署阶段：环境隔离与手动确认

部署 Job 按环境拆分，测试环境自动发布，生产环境手动确认。environment 声明关联环境，部署历史会记录在环境页。

deploy-staging:
  stage: deploy
  script:
    - ./scripts/deploy.sh staging $CI_COMMIT_SHORT_SHA
  environment:
    name: staging
  only:
    - main

deploy-production:
  stage: deploy
  script:
    - ./scripts/deploy.sh production $CI_COMMIT_SHORT_SHA
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v/'
  when: manual

生产环境发布设置 when: manual，由负责人确认后手动触发。回滚脚本提前写好：上线失败时把镜像 tag 切回上一版本，几秒内恢复服务。

流水线优化与稳定性

流水线跑稳定后做两件事：一是缩短反馈时间，把串行阶段拆成并行，必要时拆缓存粒度；二是加失败通知，Job 失败时通过 webhook 推送到企业微信或钉钉，团队第一时间处理。流水线配置本身也要走 MR 评审，避免一人改坏影响全员。