云原生交付（02）：CI/CD 流水线——代码→构建→测试→部署、缓存策略、流水线加速、发布策略

更新时间：2026-09-01。本文是 cloud/delivery/ 云原生交付第 02 篇，接 Helm 包管理。CI/CD 是持续集成和持续交付，让代码从提交自动到部署，减少人工操作，更快发布。理解流水线步骤、缓存、发布策略，才能构建高效交付流程。

本文要回答的问题

• CI 和 CD 分别是什么？流水线完整流程？
• 怎么加速流水线？依赖缓存、镜像缓存？
• 常见发布策略：蓝绿、金丝雀、滚动发布？
• 常用 CI/CD 平台对比：GitHub Actions、GitLab CI、Jenkins？

一、CI vs CD

概念	含义	作用
CI（持续集成）	开发者每次提交代码自动构建测试	尽早发现集成问题，代码仓库一直可集成
CD（持续交付）	集成后的代码自动部署到环境	每次提交都能发布到生产环境
CD（持续部署）	自动部署到生产（持续交付的极致）	从代码到生产完全自动化

二、典型流水线流程

┌─────────────┐
│  代码拉取    │  → git clone 或 checkout
└──────┬──────┘
       │
┌──────▼──────┐
│  依赖安装    │  → npm install / go mod download / pip install
└──────┬──────┘
       │
┌──────▼──────┐
│  代码检查    │  → lint / format / static check
└──────┬──────┘
       │
┌──────▼──────┐
│  单元测试    │  → 运行单元测试，生成覆盖率
└──────┬──────┘
       │
┌──────▼──────┐
│  构建镜像    │  → docker build，打标签
└──────┬──────┘
       │
┌──────▼──────┐
│  镜像扫描    │  → 漏洞扫描，不安全镜像阻断
└──────┬──────┘
       │
┌──────▼──────┐
│  推送镜像    │  → 推到镜像 registry
└──────┬──────┘
       │
┌──────▼──────┐
│  部署环境    │  → 部署到测试/预发布/生产
└──────┬──────┘
       │
┌──────▼──────┐
│  集成测试    │  → 自动化测试部署后的服务
└─────────────┘

失败机制： 任意步骤失败，流水线终止，阻断部署。

三、流水线加速——缓存策略

1. 依赖缓存

# GitHub Actions 缓存 node_modules
steps:
  - uses: actions/checkout@v4
  - uses: actions/cache@v4
    with:
      path: ~/.npm
      key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-node-
  - run: npm install

缓存 Key 设计：

• Key 根据 lock 文件哈希（package-lock.json / go.sum / requirements.txt）
• lock 文件不变 → 依赖不变 → 命中缓存 → 跳过下载
• lock 文件变 → 重新下载 → 更新缓存

2. Docker 层缓存

# Docker 层缓存：把依赖放前面，代码放后面
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci  # 依赖层，package 不变缓存命中
COPY . .
RUN npm run build

# 好处：代码变，依赖层不变，不用重新下载依赖

3. 构建缓存

# docker build 利用远程缓存
docker build --cache-from my-app:latest -t my-app:v1 .

# BuildKit 构建缓存导出导入
docker build --export-cache type=local,dest=/cache -t my-app .
docker build --import-cache type=local,src=/cache -t my-app .

4. 其他加速技巧

• 用 runner 本地缓存依赖目录
• 并行跑测试，减少总时间
• 增量构建（只构建修改的代码）
• 镜像用 multi-stage build，小镜像推送快

四、常见发布策略

1. 滚动发布（默认，推荐）

┌─────┐  ┌─────┐
│ 旧1 │  │旧2 │  原来 2 个旧版本
└─────┘  └─────┘
    ↓ 滚动更新，逐个替换
┌─────┐  ┌─────┐
│旧1 │  │新1 │  滚动中
└─────┘  └─────┘
    ↓
┌─────┐  ┌─────┐
│新1 │  │新2 │  完成，全新版本
└─────┘  └─────┘

特点：

• 逐步替换旧版本，不停止服务
• 配置 maxSurge 和 maxUnavailable
• 回滚就是反向滚动
• 适用：无状态应用，Deployment 默认

2. 蓝绿发布

蓝版本：v1 线上运行
绿版本：v2 准备好

切换前：
流量 → 蓝（v1），绿无流量

切之后：
流量 → 绿（v2），蓝还在

出问题：切回蓝（几秒钟）

特点：

• 切换快，回滚快
• 资源需要两倍，成本高
• 适用：数据库迁移、有状态应用、切换频繁

3. 金丝雀发布（灰度发布）

v1：90% 流量
v2：10% 流量（金丝雀）

观察一段时间，v2 没问题 → 逐步切到 100% v2
v2 有问题 → 切回 100% v1

特点：

• 少流量验证，风险小
• 可以按用户分（10% 用户），按地域分
• 回滚快
• 适用：大版本上线，重要特性验证

对比

策略	资源	风险	复杂度	适用
滚动	一倍+少量额外	低	简单	默认场景，无状态
蓝绿	两倍	极低	中等	切换快，重要版本
金丝雀	逐步增加	极低	高	大版本验证，少流量测试

五、常见 CI/CD 平台对比

平台	特点	适用
GitHub Actions	GitHub 集成好，免费额度够，生态好	GitHub 项目，中小团队
GitLab CI	GitLab 集成，配置简单，内置 Registry	GitLab 用户，全栈团队
Jenkins	插件多，灵活，可自托管	企业，定制化需求
CircleCI	速度快，缓存好，云原生	SaaS 用户，快速流水线
Argo Workflows	K8s 原生，复杂工作流	K8s 环境，复杂流水线

六、常见坑对照

坑	现象	对策
缓存不更新	依赖版本变了还在用旧缓存	Key 用 lock 文件哈希
流水线太慢	每次构建都重新下载依赖	依赖缓存 + Docker 层缓存
发布影响用户	滚动发布超时，服务不可用	配置健康检查，就绪探针
镜像标签不对	部署用了 latest 标签，拉到旧镜像	用 commit hash 标签，每次唯一

相关与延伸

下一篇：GitOps——ArgoCD/Flux、声明式部署、回滚、漂移检测；Helm 包管理，见 Helm 与包管理。

一句话总结

CI/CD 流水线：CI 持续集成（每次提交自动构建测试），CD 持续交付（自动部署到环境）；完整流程：代码拉取 → 依赖安装 → 代码检查 → 单元测试 → 构建镜像 → 镜像扫描 → 推送镜像 → 部署；流水线加速：依赖缓存（根据 lock 文件哈希）、Docker 层缓存（依赖放前面）、多阶段构建；发布策略：滚动发布（默认，Deployment 原生）、蓝绿发布（两倍资源，切换回滚快）、金丝雀发布（灰度验证，风险低）；GitHub Actions 适合中小项目，Jenkins 适合企业定制。