持续集成与持续交付：从"手工作坊"到"自动化流水线"

各位好，我是这次课程的老周。在讲冒烟测试之前，咱们得先把底层的 CI/CD 概念理清楚。很多同学把 CI/CD 挂在嘴边，但真问起来，能说清楚核心价值的人并不多。

说白了，CI（持续集成）和 CD（持续交付/持续部署）就是一套自动化流程。它把代码从提交到上线的所有环节串起来。嗯，先不急着背定义，咱们聊聊我遇到过的真实场景——

为什么需要 CI？一个血的教训

几年前我带过一个团队，做电商后端。大家每天早上拉最新代码，各自开发自己的模块。等到周五下午，所有人把代码合并到主干——开始"集成地狱"：编译报错、接口对不上、数据库脚本冲突……有一次硬是搞到凌晨两点才把主干修好。你想想看，这种模式多折腾？

那次之后，我下定决心引入持续集成。核心思想很简单：每次代码提交都自动执行编译、测试、检查，让问题在几分钟内暴露，而不是攒到周五集体爆发。

持续集成 vs 持续交付 vs 持续部署

这块经常有人混为一谈。我画个简化的对比表：

我个人习惯是：先做好 CI 再谈 CD。没有可靠的 CI 基础，自动部署到生产就是在玩火。

CI 的收益到底有多大？

说实话，以前我也不信一套流程能改变团队。直到我实际尝到甜头：

• 反馈速度：从几个小时缩短到 5 分钟。提交代码 → 自动构建 → 跑冒烟测试 → 出报告。谁的问题谁立刻改。
• 主干稳定性：合并前必须通过 CI 检查，不合格的 Pull Request 连合并按钮都点不了。
• 降低风险：每次集成只改动一小块，出问题了回滚也快。我曾经遇到一次数据库迁移脚本写错了，CI 在 3 分钟内就报警了，避免了全线崩溃。
• 提升信心：团队敢频繁提交了。以前一周提交一次，现在一天提交十几次。你想想看，这种节奏下代码质量反而更高？因为问题都被及时揪出来了。

典型工作流：CI 流水线长什么样？

一个标准的 CI 流水线，通常包含这几个阶段。我拿一个 Java 项目举例：

1. 代码检出：从 Git 仓库拉取最新代码。
2. 依赖安装：下载 Maven/Gradle 依赖。
3. 静态分析：检查代码风格、潜在 bug（比如 SonarQube）。
4. 单元测试：跑 JUnit / TestNG，覆盖率达标才放行。
5. 构建打包：编译并生成 jar/war。
6. 冒烟测试：部署到测试环境，验证核心功能是否正常——这是本章重点。
7. 产出报告：通知团队结果。

为了让你看得更直观，我把上面的流程画成了结构图：

CI 工具怎么选？

市面上的 CI 工具五花八门。我整理了一个常见工具的对比，帮你快速决策：

讲个小故事：我最早用 Jenkins 的时候，一个流水线脚本写了一千多行 Groovy，改配置比写代码还痛苦。后来切到 GitLab CI 之后，整个人都清爽了——YAML 文件几百行搞定。所以工具没有好坏，关键看团队习惯。

CD 管道的延伸

说完 CI，简单提一嘴 CD。你想想看，如果每次构建成功之后，手动部署到测试环境，再手动点发布——这就是持续交付。如果连这步都自动化了，就是持续部署。

不过我个人不太建议一上来就搞全自动部署。除非你们有非常完善的灰度发布和监控回滚机制。否则，一个错误的配置发布出去，整个站都慌了。