前言
前19篇讲了 CI/CD 的各种概念、工具和实践。本篇作为 CI/CD 系列收官，把这些知识串联成一个完整的企业级 CI/CD 平台搭建路线图。你可以把这篇当作 checklist，对照检查你的平台缺什么。
一、企业级 CI/CD 平台架构
┌─────────────────────────────────────────────────────────┐
│ 开发者工作流 │
│ 代码编写 → 提交 PR → 代码审查 → 合并 → 自动部署 │
└────────────────────────┬────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 代码托管层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ GitLab │ │ GitHub │ │ Gitea │ │
│ │ (代码仓库)│ │ (代码仓库) │ │ (代码仓库)│ │
│ └──────────┘ └──────────┘ └──────────┘ │
└────────────────────────┬────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ CI/CD 引擎层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ GitLab CI│ │ Jenkins │ │ Actions │ │
│ │ (流水线) │ │ (流水线) │ │ (流水线) │ │
│ └─────┬────┘ └─────┬────┘ └─────┬────┘ │
│ └──────────┬───┘─────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ 共享库 / 模板仓库 │ │
│ │ (标准流水线模板、安全检查、部署策略) │ │
│ └──────────────────────────────────────┘ │
└────────────────────────┬────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 制品管理层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Harbor │ │ Nexus │ │ GHCR │ │
│ │ (镜像仓库)│ │ (制品仓库)│ │ (镜像仓库)│ │
│ └──────────┘ └──────────┘ └──────────┘ │
└────────────────────────┬────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 部署运行层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ K8s Prod │ │ K8s Stage│ │ K8s Test │ │
│ │ (生产) │ │ (预发) │ │ (测试) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└────────────────────────┬────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 可观测性层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Prometheus│ │ Grafana │ │ Alertmgr │ │
│ │ (监控) │ │ (看板) │ │ (告警) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────┘二、搭建路线图（6个阶段）
阶段一：基础搭建（第1-2周）
目标：代码托管 + 基础 CI 跑通
□ 部署代码托管平台
- 选择 GitLab / GitHub Enterprise / Gitea
- 配置 LDAP/SSO 集成
- 设置分支保护策略（main 分支只允许 PR 合并）
□ 部署 CI/CD 工具
- 选择 GitLab CI / Jenkins / GitHub Actions
- 部署 Runner（推荐 Docker executor）
- 配置 Agent/Runner 标签
□ 建立标准流水线模板
- 构建阶段（编译打包）
- 测试阶段（单元测试）
- 代码检查（lint + format check）
□ 配置基础安全
- CI/CD 管理员权限
- 代码仓库访问权限
- Secret/Variable 基础管理阶段二：制品管理（第3-4周）
目标：构建产物可追溯、可管理
□ 部署制品仓库
- Docker 镜像仓库: Harbor / GHCR
- 包仓库: Nexus / GitLab Package Registry
- 配置存储和备份
□ 规范镜像构建
- 多阶段 Dockerfile 模板
- 镜像标签策略: BRANCH-COMMIT-TIMESTAMP
- 镜像清理策略（保留最近50个版本）
□ 流水线扩展
- 增加 Docker 镜像构建和推送阶段
- 增加镜像签名（Cosign）
- 增加镜像扫描（Trivy）阶段三：自动部署（第5-8周）
目标：自动化部署到测试和预发环境
□ 部署测试环境
- K8s 命名空间: myapp-test
- 配置 CI Runner 到 K8s 的访问权限
- 编写部署 Job（kubectl set image + rollout status）
□ 部署预发环境
- K8s 命名空间: myapp-staging
- 与生产环境同构（相同配置、相同数据量级）
- 手动触发部署（when: manual）
□ 配置管理
- ConfigMap 模板化（envsubst）
- Secret 管理（SOPS 或 Sealed Secrets）
- 多环境配置文件管理
□ 部署验证
- 健康检查（readiness probe）
- 冒烟测试
- 自动回滚机制阶段四：质量保障（第9-12周）
目标：质量门禁 + 安全扫描 + 测试自动化
□ 代码质量
- SonarQube 部署和集成
- 质量门规则定义
- 代码覆盖率报告
□ 安全扫描
- SAST（源代码安全扫描）
- 依赖扫描（CVE 检查）
- 容器镜像扫描（Trivy）
- DAST（运行时安全扫描）
□ 测试自动化
- 单元测试覆盖率 > 70%
- 集成测试套件
- E2E 测试（关键链路）
- 性能基线测试
□ 质量门禁
- 统一质量门 Job
- 低于阈值阻断流水线
- MR 中展示质量报告阶段五：生产部署（第13-16周）
目标：安全的生产部署 + 金丝雀 + 自动回滚
□ 生产环境部署
- K8s 命名空间: myapp-prod
- 人工审批（environment: production）
- 部署审计日志
□ 金丝雀发布
- Argo Rollouts 或 Flagger 安装
- 金丝雀策略: 10% → 观察5分钟 → 50% → 观察5分钟 → 100%
- 自动指标分析（Prometheus 查询）
□ 自动回滚
- 指标: 错误率 > 1% → 回滚
- 指标: 延迟 P99 > 基线 200% → 回滚
- 指标: 成功率 < 99% → 回滚
□ 数据库变更
- 扩展-收缩模式（Expand-Contract）
- 数据库迁移版本化（Flyway / Liquibase）
- 回滚脚本准备阶段六：度量优化（第17-20周）
目标：可度量、可视化、持续优化
□ CI/CD 度量
- 部署频率统计
- 变更前置时间
- 变更失败率
- MTTR
□ 监控告警
- Prometheus 指标采集
- Grafana Dashboard
- 流水线失败告警
□ 性能优化
- 构建缓存优化
- 并行执行
- 增量构建
- 流水线提速到 < 15分钟
□ 持续改进
- 月度回顾
- 瓶颈分析
- 优化计划三、组织与流程保障
团队角色
| 角色 | 职责 | 技能要求 |
|---|---|---|
| 平台工程师 | 维护 CI/CD 平台和共享库 | K8s + Docker + CI/CD 工具 |
| DevOps 工程师 | 维护流水线和部署策略 | 流水线编写 + 部署策略 |
| 开发工程师 | 编写应用代码和测试 | 编程 + 单元测试 |
| SRE | 监控和可靠性保障 | Prometheus + K8s |
流程规范
1. 代码提交规范
- 分支命名: feature/xxx, fix/xxx, hotfix/xxx
- Commit message: type(scope): description
- PR 必须有至少1人审查 + CI 通过
2. 部署规范
- 测试环境: 自动部署
- 预发环境: 手动触发 + 自动验证
- 生产环境: 人工审批 + 金丝雀 + 自动回滚
3. 应急流程
- 流水线失败: 自动通知 → 责任人15分钟内响应
- 生产故障: 自动回滚 → 人工介入 → 事后复盘
- 安全事件: 阻断流水线 → 安全团队审查 → 修复后放行四、常见问题与对策
| 问题 | 原因 | 对策 |
|---|---|---|
| 流水线太慢 | 无缓存、串行执行 | 加缓存、并行化、增量构建 |
| 构建经常失败 | 环境不一致 | 容器化构建、固定镜像版本 |
| 密钥泄漏 | 硬编码 | Vault/SOPS + 最小权限 |
| 部署后故障 | 缺乏验证 | 金丝雀 + 自动回滚 + 健康检查 |
| 团队不用 | 太复杂、门槛高 | 共享库 + 模板 + 培训文档 |
| 插件/工具升级出问题 | 没有测试环境 | 先 staging 验证再升级 |
五、CI/CD 成熟度自评
Level 1：入门级（手动+脚本）
- 有代码仓库
- 有手动构建脚本
- 部署靠手动操作
- 无自动化测试
Level 2：CI 基础级
- 有自动化流水线（构建+测试）
- 有 CI Runner
- 有代码审查流程
- 有基础的单元测试
Level 3：CD 持续交付级
- 有 Docker 镜像构建和推送
- 有制品仓库
- 自动部署到测试环境
- 有预发环境
- 有质量门禁
Level 4：DevOps 成熟级
- 有金丝雀/蓝绿部署
- 有自动回滚
- 有安全扫描（SAST/DAST/依赖/镜像）
- 有监控告警
- 有度量指标（DORA 四指标）
- 流水线 < 15分钟
Level 5：持续部署级
- 通过测试自动部署到生产
- 功能开关（Feature Flags）
- 混沌工程
- 每天部署多次
- MTTR < 1小时
培训要点：绝大多数企业达到 Level 3 就已经是行业领先。Level 4-5 需要团队文化和工程能力的长期积累。不要急于求成，每个 Level 至少稳定运行3个月再向下一个 Level 迈进。
六、本篇要点回顾
- 企业级 CI/CD 平台五层架构：代码托管 → CI/CD 引擎 → 制品管理 → 部署运行 → 可观测性
- 20周路线图：基础搭建 → 制品管理 → 自动部署 → 质量保障 → 生产部署 → 度量优化
- 组织保障：平台工程师 + DevOps + 开发 + SRE 协同
- 流程规范：代码规范 + 部署规范 + 应急流程
- 成熟度五级评估，多数企业达到 Level 3 即领先
CI/CD 系列结语
20篇文章从"CI/CD 是什么"开始，经过 Jenkins、GitLab CI、GitHub Actions 三大工具实战，到安全实践、度量优化，最后到企业级平台搭建路线图。读完并实践后，你应该具备从零搭建一个生产级 CI/CD 平台的能力。
下一篇系列预告：接下来进入 GitOps 系列。GitOps 是 CI/CD 的"升级版"------用 Git 作为唯一可信源，实现声明式交付。我们将从理念到 ArgoCD/Flux 实战，带你进入下一代交付方式。
系列下一篇：《GitOps·入门篇》GitOps是什么：从基础设施即代码到声明式交付的演进》