GitLab CI/CD 流水线实践

1. 一条流水线的骨架
2. Cache 与 Artifact：CI 提速的关键
3. 多环境部署策略
4. 让流水线更可靠的 5 个细节

1. 一条流水线的骨架

所有流水线都写在仓库根目录的 .gitlab-ci.yml 中。核心概念就四个：

Stage —— 阶段，按顺序执行（build → test → deploy）。
Job —— 最小执行单元，归属于某个 stage，可并行运行。
Runner —— 执行 Job 的机器，负责真正跑命令。
Pipeline —— 一次提交触发的所有 Job 的集合。

一个最小可用的完整流水线：

stages:
  - build
  - test
  - deploy

variables:
  IMAGE_NAME: registry.example.com/demo/app

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $IMAGE_NAME:$CI_COMMIT_SHORT_SHA .
    - docker push $IMAGE_NAME:$CI_COMMIT_SHORT_SHA

test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm run lint
    - npm test
  artifacts:
    paths:
      - coverage/

deploy:
  stage: deploy
  image: alpine:3.19
  script:
    - echo "deploy to prod..."
  environment:
    name: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

这里用到两个内置变量：CI_COMMIT_SHORT_SHA（提交短哈希）作为镜像 tag， CI_COMMIT_BRANCH（当前分支）用于控制部署条件。

2. Cache 与 Artifact：CI 提速的关键

两者经常被混淆，区别很重要：

特性	Cache	Artifact
用途	加速依赖安装	传递构建产物
是否传给下个 Job	否，仅复用	是
过期策略	自动失效重建	可设 expire_in
典型示例	node_modules、pip cache	JAR、Docker 镜像、覆盖率

# 为 npm 依赖启用缓存，build 时间可以从 5 分钟降到 40 秒
test:
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
      - .npm/
  before_script:
    - npm ci --cache .npm --prefer-offline

注意 Cache 和 Artifact 不要混用：cache 用于「加速」，artifact 用于「传递」。试图用 cache 跨 Job 传产物会因无法保证可用性而出诡异问题。

3. 多环境部署策略

用 rules 按分支把流程区分开，实现「开发分支自动部署测试环境，main 手动部署生产」：

deploy:
  stage: deploy
  script:
    - ./deploy.sh $ENV_NAME
  environment:
    name: $ENV_NAME
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      variables:
        ENV_NAME: production
      when: manual          # 生产环境手动触发，加一道人工审核
    - if: $CI_COMMIT_BRANCH =~ /^release\//
      variables:
        ENV_NAME: staging
    - if: $CI_COMMIT_BRANCH == "develop"
      variables:
        ENV_NAME: dev

结合 GitLab 的 Environment 功能，每次部署自动生成「部署历史」，配一个回滚按钮，出问题一键回滚。

# 在 deploy 脚本中补充回滚支持
rollback:
  stage: deploy
  script:
    - kubectl rollout undo deployment/app -n $ENV_NAME
  environment:
    name: $ENV_NAME
    action: rollback
  when: manual

4. 让流水线更可靠的 5 个细节

每个 Job 加超时 —— timeout: 10m，防止挂起的 Job 卡死 Runner。
只构建需要的镜像层 —— Dockerfile 按「依赖 → 源码 → 启动」分层 COPY，配合缓存层加速。
镜像 tag 用提交哈希 —— 永远不用 latest 作为可回滚 tag，便于精确定位版本。
敏感信息走变量 —— 在 CI/CD Settings 里配置 MASKED 变量，不要写死在 .gitlab-ci.yml。
失败即停止，不再继续 —— 默认 Job 失败流水线就红，不要让「修复测试」变成常态。

把流水线当成「会一直运行的生产系统」来维护，每一行配置都要能回答「为什么需要它」。这样的流水线，才能成为团队交付的稳定通道，而不是时不时断掉的瓶颈。

← 返回首页