CI/CD（持续集成/持续交付）是现代软件工程的核心基础设施，目标是让代码变更快速、安全、可重复地到达生产环境。本文从工程实践、工具链、部署策略、度量体系四个维度，系统梳理 CI/CD 的完整知识体系。
持续集成的本质是频繁集成、快速反馈。Martin Fowler 在 2000 年首次提出 CI 概念时，强调的是"每天多次将代码集成到主干"，这一原则在今天依然有效，只是频率从"每天"变成了"每次提交"。
核心实践清单：
| 实践 | 说明 | 频率 |
|---|---|---|
| 代码频繁提交 | 小批量变更，降低合并冲突风险 | 每天多次 |
| 自动化构建 | 提交触发编译、打包、镜像构建 | 每次提交 |
| 自动化测试 | 单元测试、集成测试、代码扫描 | 每次构建 |
| 即时反馈 | 失败时立即通知，修复后再继续 | 实时 |
Hugo 的踩坑记录： 早期团队曾允许"构建失败也能合并"，结果一周内主干代码无法编译了 3 次，全团队停工半天。后来强制要求"绿灯才能合并"，虽然初期有人抱怨流程慢，但两周后大家适应了小步提交，整体效率反而提升。
分支策略决定了团队如何协作，直接影响发布频率和代码稳定性。
适合发布周期明确、需要版本号管理的项目：
master ──→ release/v1.0 ──→ develop ──→ feature/login
↑ │ ↑
└────────────┘ └──────── feature/payment
适用场景： 桌面软件、移动应用、需要维护多个版本的 B2B 产品。
适合持续交付、发布频率高的团队：
main/trunk ─────────────────────────────
↑ ↑ ↑
│ │ └─ 小功能 A（存活 <1天）
│ └── 小功能 B（存活 <1天）
└──── 小功能 C（存活 <1天）
选型建议：
| 维度 | Git Flow | Trunk-Based |
|---|---|---|
| 发布频率 | 月/季度 | 周/日/按需 |
| 团队规模 | 中小团队 | 任何规模 |
| 版本管理 | 需要版本号 | 持续交付，无版本号 |
| 学习成本 | 较高 | 较低 |
| 工具支持 | Git 原生 | 需要特性开关平台 |
Hugo 的经验： 金融系统早期用 Git Flow，每季度发布一次，release 分支上修 bug 修到崩溃。后来切换到 Trunk-Based + 特性开关，发布频率提升到每周两次，紧急修复从"切 hotfix 分支"变成"关开关回滚"，平均恢复时间从 2 小时降到 5 分钟。
GitHub Flow（简化版 Git Flow）：
GitLab Flow（带环境分支）：
典型的流水线阶段设计：
Stage 1: Checkout → 拉取代码，准备环境
Stage 2: Build → 编译、静态分析、依赖检查
Stage 3: Test → 单元测试、覆盖率检查
Stage 4: Integration → 集成测试、数据库迁移测试
Stage 5: Security → 漏洞扫描、密钥检测
Stage 6: Package → 构建 Docker 镜像、Helm Chart
Stage 7: Push → 推送镜像到仓库
设计原则：
Pipeline as Code 示例（GitLab CI）：
stages:
- build
- test
- security
- package
- deploy
build:
stage: build
script:
- ./gradlew build -x test
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- .gradle/
unit-test:
stage: test
script:
- ./gradlew test
coverage: '/Total.*?([0-9]{1,3})%/' # 解析覆盖率报告
integration-test:
stage: test
needs: [build] # 只要 build 完成就开始，不等 unit-test
script:
- ./gradlew integrationTest
security-scan:
stage: security
script:
- trivy fs --severity HIGH,CRITICAL .
allow_failure: true # 失败不阻塞，但会标红
docker-build:
stage: package
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
代码随时可发布，但发布需要人工审批：
关键实践：
代码通过测试后自动部署到生产：
成熟度要求：
| 维度 | 要求 |
|---|---|
| 测试覆盖率 | ≥ 80% 单元测试 + 关键路径 E2E |
| 监控覆盖 | 业务指标、技术指标、日志全覆盖 |
| 回滚能力 | 一键回滚，< 5 分钟恢复 |
| 数据库变更 | 向后兼容的迁移策略 |
| 特性开关 | 所有新功能必须有开关 |
Hugo 的经验： 内部工具平台采用持续部署，每天自动发布 5-10 次。关键经验是"数据库变更必须向后兼容"——先部署新代码（兼容旧 schema），再执行迁移，再清理旧代码。这样任何时间点回滚都不会导致数据不一致。
逐步替换旧版本实例：
时间 →
v1: [A][B][C][D]
v2: [A][B][C][D] ← 逐个替换
Kubernetes 实现：
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 最多多跑 1 个 Pod
maxUnavailable: 0 # 不允许少于期望数量
两套环境并行，瞬间切换：
流量 → [Blue: v1] 准备 [Green: v2]
↓
流量 → [Green: v2] 保留 [Blue: v1]（回滚备用）
实现要点：
Hugo 的经验： 支付核心系统用蓝绿部署，数据库采用"扩展/收缩"策略。一次发布新版本需要改订单表结构，提前 2 周在表中加了新字段（不影响旧代码），发布当天只切换代码，表结构不变。发布后一周再清理旧字段。整个过程零停机。
小流量验证，逐步放量：
流量: 100% → 95% v1 + 5% v2 → 50/50 → 0% v1 + 100% v2
↑
监控指标确认健康才继续放量
放量策略：
| 阶段 | 流量比例 | 观察时间 | 通过标准 |
|---|---|---|---|
| 暗启动 | 0%（只复制流量，不响应） | 30 分钟 | 无异常日志 |
| 小流量 | 1% | 1 小时 | 错误率 < 0.1% |
| 中流量 | 10% | 2 小时 | P99 延迟正常 |
| 大流量 | 50% | 4 小时 | 业务指标正常 |
| 全量 | 100% | - | - |
工具支持：
代码已部署，功能通过开关控制：
if (featureFlags.isEnabled("new-payment-flow", userId)) {
return newPaymentService.process(order);
} else {
return legacyPaymentService.process(order);
}
开关生命周期管理：
开发中 → 内部测试 → 灰度发布 → 全量发布 → 清理代码
↑___________________________________________|
（开关长期不清理 = 技术债）
Hugo 的内部约定：
{team}-{feature}-{action}，如 payment-new-flow-process| 策略 | 资源需求 | 回滚速度 | 风险 | 复杂度 | 适用场景 |
|---|---|---|---|---|---|
| 滚动 | 低 | 慢（重新滚动） | 中 | 低 | 无状态服务、兼容变更 |
| 蓝绿 | 高（2x） | 秒级 | 低 | 中 | 关键系统、快速回滚 |
| 金丝雀 | 中 | 中 | 最低 | 高 | 大规模服务、渐进验证 |
| 特性开关 | 低 | 即时 | 低 | 中 | 功能灰度、A/B 测试 |
| 工具 | 特点 | 适用 | 定价 |
|---|---|---|---|
| GitLab CI | 与 GitLab 深度集成、YAML 配置、自带 Registry | GitLab 用户 | 开源/付费 |
| GitHub Actions | 生态丰富、Marketplace 插件多、社区活跃 | GitHub 用户 | 免费额度+付费 |
| Jenkins | 插件丰富、灵活度高、企业级 | 复杂定制需求 | 开源 |
| CircleCI | 云原生、配置简洁、并行能力强 | 中小团队 | 付费 |
| Travis CI | 早期云 CI、简单易用 | 开源项目 | 开源免费 |
| Argo Workflows | Kubernetes 原生、DAG 编排 | K8s 集群 | 开源 |
选型建议：
Hugo 的经验： 团队用 Harbor 作为统一镜像仓库，集成了漏洞扫描（Trivy）和签名验证（Notary）。关键配置是"不可变标签"——生产镜像一旦推送，标签不可覆盖，保证可追溯性。
配置分层原则：
基础配置（代码仓库）
↓
环境配置（ConfigMap/环境变量）
↓
实例配置（启动参数）
↓
敏感配置（Secrets/Vault）
最佳实践：
Git 作为唯一事实来源（Single Source of Truth）：
Git 仓库（配置/清单）
↓
CI 构建镜像 → 更新 Git 中的镜像标签
↓
CD 控制器（ArgoCD/Flux）监听 Git 变化
↓
自动同步到 Kubernetes 集群
应用定义示例：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: payment-service
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/hugogu/gitops-repo.git
targetRevision: HEAD
path: apps/payment-service/overlays/production
destination:
server: https://kubernetes.default.svc
namespace: payment
syncPolicy:
automated:
prune: true # 删除 Git 中不存在的资源
selfHeal: true # 自动修复 drift
syncOptions:
- CreateNamespace=true
Hugo 的经验： GitOps 最大的好处是"回滚 = git revert"。一次生产故障，通过 revert 镜像标签提交，ArgoCD 30 秒内自动回滚。对比以前"找上一个版本镜像 → 手动 kubectl set image → 验证"的流程，时间从 15 分钟降到 30 秒。
代码进入下一阶段的必要条件：
| 门禁 | 阈值示例 | 说明 |
|---|---|---|
| 单元测试通过率 | 100% | 任何测试失败都阻塞 |
| 代码覆盖率 | ≥ 80%（逐步提升） | 新代码覆盖率 ≥ 80% |
| 静态分析 | 0 严重漏洞 | SonarQube 阻断级问题 |
| 依赖漏洞 | 无高危 CVE | Trivy/Snyk 扫描 |
| 性能回归 | P95 延迟增幅 < 10% | 对比基线 |
| 代码评审 | 至少 1 人 Approve | 核心模块 2 人 |
门禁偶尔失败时的策略：
Hugo 的经验： 曾遇到 SonarQube 误报导致所有 PR 阻塞，团队差点养成"跳过门禁"的习惯。后来建立"门禁豁免审批"流程——需要技术负责人审批、记录原因、设定期限修复。既保证了灵活性，又避免了破窗效应。
Google DevOps 研究与评估团队提出的四个核心指标，被业界广泛认可：
| 指标 | 精英表现 | 高表现 | 中等表现 | 低表现 | 含义 |
|---|---|---|---|---|---|
| 部署频率 | 按需/每日多次 | 每周一次到每月一次 | 每月一次到每半年一次 | 每半年少于一次 | 小批量、快速流动 |
| 变更前置时间 | < 1 小时 | 1 天到 1 周 | 1 周到 1 月 | > 1 月 | 从代码提交到生产 |
| 变更失败率 | < 5% | 5%-15% | 16%-30% | > 30% | 部署后需要修复的比例 |
| 恢复时间 | < 1 小时 | < 1 天 | < 1 周 | > 1 周 | 从故障到恢复 |
度量方法：
Hugo 的经验： 团队每月做"Pipeline 健康度"复盘，统计各阶段耗时和失败率。一次发现集成测试阶段占整个 Pipeline 60% 时间，原因是测试数据库每次重建。优化为"测试数据库模板 + 快照恢复"后，集成测试从 15 分钟降到 3 分钟。
现代 CI/CD 面临的最大风险之一是供应链攻击：
防护措施：
| 风险 | 防护措施 |
|---|---|
| 依赖混淆 | 私有仓库优先、依赖锁定（lockfile）、签名验证 |
| 恶意镜像 | 镜像扫描（Trivy/Clair）、只使用可信基础镜像 |
| 密钥泄露 | GitLeaks 扫描、Vault 动态密钥、短期凭证 |
| CI/CD 入侵 | 最小权限、OIDC 认证（不存储长期凭证）、网络隔离 |
金融行业的 CI/CD 需要满足额外合规要求：
CI/CD 不是目的而是手段。最终目标是让团队专注于创造价值，而不是被发布流程拖累。
关键成功因素：
相关页面：