CI/CD（持续集成/持续交付/持续部署）的发展史是一部软件交付效率不断进化、人工干预逐渐减少、自动化程度不断提高的历史。它从简单的脚本拼接，演变为如今的云原生、GitOps 和平台工程。
我们可以将其划分为五个主要阶段：
第一阶段：蛮荒时代（2000 年以前）
关键词：手工操作、"在我机器上是好的"、大爆炸发布
- 背景：软件开发遵循“瀑布模型”，开发周期长达数月甚至数年。
- 集成方式：“集成地狱” (Integration Hell)。开发人员各自在本地开发，直到项目截止日期前几周，大家才把代码合并到一起。
- 问题：
- 接口不兼容、依赖冲突频发。
- 修复 Bug 的时间远超开发时间。
- 发布是“大爆炸”式的，风险极高，一旦失败需回滚数周的工作。
- 工具：Makefile, Shell 脚本，FTP 手动上传文件。
第二阶段：持续集成 (CI) 的觉醒（2000 - 2010）
关键词：Kent Beck, CruiseControl, 每日构建，单元测试
- 起源：极限编程 (XP) 运动兴起。Kent Beck 在 2000 年左右正式提出“持续集成”概念。
- 核心理念：
- 频繁提交：开发者每天多次向主干提交代码。
- 自动构建与测试：每次提交都触发自动构建和单元测试，尽早发现错误。
- 快速反馈：如果构建失败，立即通知开发者修复。
- 标志性事件：
- 2001 年：CruiseControl (Java) 诞生，这是第一个流行的开源 CI 服务器。
- 2006 年：Hudson (Jenkins 的前身) 由 Kohsuke Kawaguchi 创建。它提供了友好的 Web UI 和插件架构，彻底改变了 CI 的易用性。
- 局限：此时主要关注“集成”和“测试”，部署到生产环境依然主要是手工或半自动化的脚本操作。
第三阶段：持续交付 (CD) 与 DevOps 的融合（2010 - 2015）
关键词：Jez Humble, Jenkins, 流水线，虚拟化，DevOps
- 理论奠基：2010 年，Jez Humble 和 David Farley 出版了《持续交付》(Continuous Delivery) 一书，定义了 CD 的核心：让软件随时处于可发布状态。
- 技术驱动：
- 虚拟化普及：VMware 等使得环境复制变得容易。
- 配置管理工具：Puppet, Chef, Ansible 出现，实现了“基础设施即代码” (IaC) 的雏形，解决了环境一致性问题。
- Jenkins 统治：Hudson 分叉为 Jenkins，凭借庞大的插件生态成为行业标准。
- 流程变革：
- 流水线 (Pipeline) 概念形成：构建 -> 测试 -> 预发布 -> 生产。
- DevOps 文化：开发与运维的界限开始模糊，强调协作和自动化。
- 特点：自动化覆盖了从代码提交到预发布环境的全过程，但生产环境的发布按钮通常还需要人工点击（持续交付）。
第四阶段：容器化与云原生爆发（2015 - 2020）
关键词：Docker, Kubernetes, GitLab CI, CircleCI, 微服务
- 颠覆者：Docker (2013-2014)：
- 解决了“环境不一致”的终极难题。构建产物不再是 Jar/War 包，而是包含运行环境的镜像。
- CI/CD 流程重心转移：构建镜像 -> 推送仓库 -> 拉取运行。
- 编排者：Kubernetes (2015+)：
- 容器编排成为标准，部署变得极其复杂（Pod, Service, Ingress, ConfigMap）。
- 传统的脚本式部署（
kubectl apply -f ...）难以管理大规模微服务。
- 工具多样化：
- SaaS 化 CI：CircleCI, Travis CI, GitHub Actions 兴起，无需自建服务器，开箱即用。
- 一体化平台：GitLab CI 将代码托管、CI、容器 registry 整合在一起，体验极佳。
- Jenkins 进化：推出 Pipeline as Code (Jenkinsfile)，支持动态 Agent (Docker/K8s)。
- 趋势：持续部署 (Continuous Deployment) 开始流行，即代码通过测试后自动发布到生产环境，无需人工干预（如 Facebook, Amazon）。
第五阶段：GitOps 与平台工程（2020 - 至今）
关键词：GitOps, ArgoCD, Flux, eBPF, AI, 平台工程
- 新范式：GitOps (2017 提出，2020 普及)：
- 核心思想：Git 是唯一的真理来源 (Single Source of Truth)。
- Pull 模式：不再由 CI 工具 pushing 部署到集群，而是在集群内部运行一个控制器（如 ArgoCD, Flux），持续监听 Git 仓库的变化，自动同步集群状态到 Git 定义的状态。
- 优势：完美的版本控制、一键回滚（git revert）、审计合规、多集群管理。
- 分工明确：CI 负责构建镜像和更新 Git 中的版本号；CD (GitOps) 负责将变更应用到集群。
- 内部开发者平台 (IDP)：
- 随着云原生复杂度爆炸，普通开发者难以驾驭 K8s。
- 平台工程兴起：构建自助式平台（如 Backstage + Tekton/Argo），让开发者只需关注代码，底层 CI/CD 逻辑被封装。
- 智能化与安全性：
- DevSecOps：安全扫描 (SAST/DAST) 嵌入流水线每一个环节。
- AI 辅助：利用 AI 分析构建失败原因、自动生成测试用例、预测发布风险。
- 渐进式交付：结合 Istio/Linkerd 等服务网格，实现金丝雀发布、蓝绿部署的自动化流量切换。
总结：CI/CD 演进路线图
| 阶段 | 时间 | 核心目标 | 关键工具/技术 | 部署频率 | 人工干预 |
|---|---|---|---|---|---|
| 蛮荒时代 | <2000 | 能跑就行 | Shell, FTP | 数月/次 | 100% 手工 |
| CI 觉醒 | 2000-2010 | 快速发现 Bug | CruiseControl, Hudson, JUnit | 周/次 | 构建自动，部署手工 |
| CD & DevOps | 2010-2015 | 随时可发布 | Jenkins, Puppet, Ansible, VM | 天/次 | 构建测试自动，发布需审批 |
| 云原生 | 2015-2020 | 微服务弹性 | Docker, K8s, GitLab CI, CircleCI | 小时/次 | 大部分自动，部分持续部署 |
| GitOps | 2020-至今 | 声明式、可观测、自愈 | ArgoCD, Flux, Tekton, AI | 分钟/次 | 极少 (完全自动化) |
未来的趋势 (2026+)
- 无感 CI/CD：开发者几乎感知不到流水线的存在，提交代码后，AI 自动处理测试、构建、安全扫描和部署，只在大问题发生时介入。
- 环境即代码 (EaC) 的深化：不仅是基础设施，连测试数据、网络策略、监控规则全部由 Git 管理。
- 混沌工程常态化：CI/CD 流水线中自动注入故障（网络延迟、节点宕机），确保系统在发布前已通过“抗压测试”。
- 供应链安全：基于 SLSA (Supply-chain Levels for Software Artifacts) 标准，确保从源码到二进制的全链路可追溯和防篡改。
CI/CD 的发展本质上是将软件交付中的不确定性转化为确定性的过程，让人类从重复劳动中解放出来，专注于创新。