School of SRE 教程：从瀑布模型到 CI/CD——持续集成与持续交付的演进史与 DevOps 实践

CI/CD（持续集成 / 持续交付）并非一夜之间出现的流行词，而是软件工程在应对"交付周期过长、集成频繁失败、开发与运维割裂"等历史痛点中逐步演化出的方法论体系。本篇以 LinkedIn School of SRE 课程体系中的 CI/CD 演进史为骨架，系统梳理从瀑布模型到敏捷、再到 DevOps 与 SRE 的完整脉络，并给出本仓库课程中对应的定义、工具与实操路径，帮助你理解 CI/CD 为什么是 SRE 降低变更风险、缩短交付周期的核心杠杆。

传统开发模式：瀑布模型与"交付周期之痛"

在很长一段时间里，传统开发流程主导着大大小小的软件项目，其中最典型的就是瀑布模型（Waterfall Model）。瀑布模型按"需求分析 → 设计 → 开发 → 测试 → 部署"的顺序线性推进，在小型项目上确实取得了成功，但它有一个致命的弱点：交付周期过长。

代码在"孤岛"中积累，集成集中爆发

当多个团队成员并行开发同一项目时，代码变更会在各自的分支上不断累积，却直到计划好的构建日期才被整合。而构建通常按约定周期进行，这个周期短则一个月、长则一个季度。结果就是：

• 开发人员各自在"孤岛"（silo）上开发功能，互不感知对方改动；
• 等到集中构建时，大量集成问题同时爆发，构建频繁失败；
• 修复成本随累积时间急剧上升。

这种"攒大招式"的集成模式，本质上把风险推迟到了交付末端，让每一次发布都变成高风险事件。

运维团队的噩梦：部署靠"热修复"与"紧急补丁"

对运维团队（或任何负责把新版本部署到生产环境的人）来说，集中式发布堪称噩梦。原因在于：

• 每次变更缺乏完整文档，部署时无法确认环境配置要求；
• 生产环境配置与开发环境差异巨大，部署经常失败；
• 为了按时上线，往往只能临时打热修复（hot fix）和紧急补丁（immediate patch），进一步加剧生产环境的混乱。

协作鸿沟：开发不懂生产，运维不了解变更

另一个巨大的挑战是协作。开发人员很少与运维工程师直接沟通，对生产环境的运行约束（容量、流量、依赖、容灾等）缺乏完整认识；运维团队则在缺乏变更上下文的情况下被动接盘。这些挑战叠加在一起，最终导致代码交付的**周期时间（cycle time）**被不断拉长——这正是 CI/CD 要解决的核心问题。

敏捷方法论与持续集成（CI）的诞生

敏捷方法论的出现改变了游戏规则：它提倡在多个迭代中增量交付功能。具体到工程实践上：

• 开发人员以更小的增量提交代码变更；
• 发布节奏更频繁，而不是攒到季度末；
• 每次代码提交都会触发一次新构建，集成问题在提交的当下就被识别，而不是等数周后才暴露。

这一实践显著改善了构建过程，并有效缩短了交付周期。这套"频繁提交 + 每次提交自动构建验证"的机制，就是持续集成（Continuous Integration，CI）。在本仓库的 continuous_integration_build_pipeline.md 中，CI 被进一步定义为：团队成员频繁整合各自工作，每次整合通过**自动化构建（含测试）**来尽早发现集成错误。其落地前提包括：

• 所有代码变更维护在单一代码仓库中，成员可定期向各自特性分支推送；
• 代码变更能快速与主代码集成，自动化构建即时给出反馈；
• 存在一台 CI 服务器，代码一推送即触发构建。

典型的 CI 构建流程涉及：编译代码并打包为可执行产物（如 JAR、DLL，即 packaging）、执行带代码覆盖率的单元测试，可选地加入静态代码分析、漏洞检查等附加阶段。业界常用的 CI 工具包括 Jenkins、Bamboo、Travis CI、GitLab、Azure DevOps 等；构建打包可使用 Ant、Maven 等，单元测试可借助 JUnit、Selenium 等，静态代码分析与代码安全则可用 SonarQube。

CI 的价值在于把"集成问题"从交付末端前置到每次提交，让问题在最小的上下文中被定位和修复。

持续交付（CD）：让增量部署成为常态

CI 解决了"能否稳定集成"，而**持续交付（Continuous Delivery，CD）**解决的是"如何可靠地把变更送达环境"。在 continuous_delivery_release_pipeline.md 中，CD 被定义为：在 SIT、UAT、INT 等非生产（staging）环境中更频繁地部署构建产物，并自动执行集成测试与验收测试。

CD 有几个关键原则：

• 面向集成后的应用测试：在微服务架构下，测试针对集成后的完整应用而非单个服务，覆盖全部功能测试与可能包含 UI 测试的验收测试；
• 构建产物不可变（immutable）：同一个包必须原样部署到包括生产在内的所有环境，杜绝"每个环境重新编译"造成的环境漂移；
• 生产部署通常仍为手动：在补充执行性能测试等额外验收测试后，人工触发生产发布。

当生产环境的部署也实现全自动化时，即为更进一步的持续部署（Continuous Deployment）——它与持续交付（CD）的关键区别在于：CD 不会自动部署到生产。持续部署通常还需要特性开关（feature toggle），以便在无需重新部署代码的情况下随时关闭某个特性。此外，生产部署往往涉及不止一个环境，例如蓝绿部署（blue-green）先把应用部署到 blue 环境再切到 green 环境，从而做到零停机发布。

DevOps 与 SRE：打破开发与运维的壁垒

回到演进史的视角：CI/CD 之所以能在组织层面生根，离不开 DevOps 文化的推动。DevOps 由 Development（开发）与 Operations（运维）组合而成，本质是把两个团队拉到一起深度协作。这背后存在天然的张力：

• 开发团队希望引入更多功能与变更；
• 运维团队更关注应用在生产环境中的稳定性；
• 对运维而言，任何变更都被视为可能动摇环境稳定性的威胁。

DevOps 正是一种文化——它引入流程来消解开发与运维之间的壁垒，而不是仅仅靠工具堆砌。随着组织逐步采纳 DevOps 与 SRE（站点可靠性工程） 纪律，开发与运维之间的鸿沟被大幅收窄：

• 双方协作显著改善，端到端跟踪生产部署；
• 两个团队使用相同的工具与流程，消除了对流程的冲突理解；
• 持续交付成为主要驱动力之一，保证小变更的增量部署；
• 在进入生产环境之前，设置多个预生产（staging）环境逐级验证。

这种协作带来更频繁、更可控的部署节奏，而 CI/CD 正是支撑这一切的关键流程要素。在本仓库课程结构中，这一主题位于 Level 102 的 Continuous Integration and Continuous Delivery 模块，其前置知识包括软件工程基础、Git 与 Docker 容器化。

CI/CD 的收益与 SRE 视角下的实战价值

本仓库 introduction_to_cicd.md 总结了 CI/CD 的五大核心收益：

1. 显著减少集成问题；
2. 团队能更快地开发出内聚的软件；
3. 开发与运维的协作改善，降低生产集成问题；
4. 更快、更少摩擦地交付新特性；
5. 更高效地调试生产问题，并在下一个版本/补丁中修复。

对 SRE 而言，CI/CD 的意义远不止"自动化构建"。正如 conclusion.md 所指出的，**监控、自动化与消除琐事（toil）**是 SRE 纪律的核心支柱，SRE 往往需要将约 50% 的时间投入自动化重复性任务、消除 toil，而 CI/CD 管道正是其中最关键的自动化载体：

• 部署时间（Deployment time）、成功率（Success rate）、周期时间（Cycle time）、自动化测试通过率等 CI/CD 指标，是持续改进产品质量与可靠性的关键观测点；
• 基础设施即代码（Infrastructure-as-Code）是 SRE 自动化重复配置任务的标准实践——所有配置都以代码维护，再通过 CI/CD 管道部署到生产，从而保证变更的版本化、跨环境一致并避免人工错误；
• SRE 常需要审查应用 CI/CD 管道，并建议补充静态代码分析、安全与隐私检查等阶段，以提升产品的安全性与可靠性。

课程还配套了基于 Jenkins 的实操实验（jenkins_cicd_pipeline_hands_on_lab.md）：在 Docker 中运行 Jenkins、Fork 示例 Java 应用、创建 Pipeline 类型的 Jenkins Job，并通过仓库根目录的 Jenkinsfile 声明式定义 Build 与 Test 等阶段，从而亲手完成一条从"代码提交"到"自动构建+测试"的真实 CI 管道。

结语

回看整条演进线：瀑布模型暴露了长交付周期与集中式集成的风险 → 敏捷以增量迭代催生了 CI（每次提交即构建验证）→ DevOps / SRE 文化弥合了开发与运维的鸿沟，让 CD（小变更的增量部署 + 多级预生产环境验证）成为常态 → 最终形成以 CI/CD 为核心的现代软件交付体系。对 SRE 而言，CI/CD 不仅是效率工具，更是质量与可靠性的度量与保障机制——这正是本仓库将其列为 Level 102 必修模块、并在 SRE 工作流中反复强调"通过管道交付一切变更"的原因。