📚 课程目录第1章 CI/CD概念与价值

1. CI/CD 概念与价值

1.1 先聊聊我们为什么要 CI/CD

我记得刚带团队那会儿，最头疼的就是“集成地狱”。

每个人在自己的分支上写代码，一合并就冲突。修完一个 bug，又冒出三个新 bug。项目经理天天追问“什么时候能发版”，开发说“再测两天”，测试说“环境还没搭好”。

说白了，那时候的软件交付就是一场赌博。

CI/CD 这套东西，就是用来终结这种混乱的。它不是某个工具，也不是某条命令，而是一整套工程方法论。

一句话概括：CI/CD 让代码从提交到上线，变成一条自动化的流水线。

1.2 三个核心概念

概念	英文	核心动作	交付物
持续集成	Continuous Integration	频繁合并 + 自动构建 + 自动测试	可验证的代码增量
持续交付	Continuous Delivery	自动部署到类生产环境 + 人工审批	随时可上线的手动候选版本
持续部署	Continuous Deployment	自动部署到生产环境	每次代码变更自动上线

这三者的关系就像爬楼梯：持续集成是地基，持续交付是中间层，持续部署是顶楼。没有持续集成，后面两个都是空中楼阁。

1.3 持续集成 —— 把冲突扼杀在摇篮里

持续集成的核心就一句话：每天多次把代码合并到主干，每次合并都自动构建并跑测试。

我在项目中遇到过最极端的情况：一个团队两周才合一次代码，合进来 300 个文件变更。光是解决冲突就花了两天，改完又发现单元测试挂了 80 个。那个月整整延期了 10 天。

持续集成能帮你做三件事：

早发现冲突——代码间隔不超过 24 小时，冲突范围极小
早发现缺陷——每次提交自动跑单元测试、静态检查
保持主干健康——失败时立即通知，修复优先于新功能

一个典型的 CI 流程，在推送代码后自动触发：

git push origin feature/login

→ CI 服务器收到 Push Hook
→ 检出代码
→ 安装依赖（npm ci / pip install）
→ 执行单元测试（pytest --junitxml）
→ 执行代码规范检查（flake8 / ESLint）
→ 构建产物（docker build / webpack）
→ 生成测试报告
→ 通知结果（绿勾 / 红叉）

  我个人的经验：CI 流程必须控制在 10 分钟以内。一旦超过 15 分钟，开发者就会开始反感。没人愿意等一个 40 分钟的红叉再修复。

1.4 持续交付 —— 随时准备好，但先别按按钮

持续交付是在 CI 的基础上，把构建产物自动部署到 类生产环境（staging / pre-prod）。

为什么要先到类生产环境？说白了，你的单元测试跑绿了，不代表在真实环境里也能跑通。数据库版本差异、依赖包的兼容性、网络配置……这些在 CI 环境里不会暴露。

我曾经遇到过：开发环境 Redis 版本是 6.2，生产环境是 5.0。CI 一切正常，结果上线后缓存操作全部报错。后来我们就把持续交付加了进来——每次合入主干后自动部署到 staging，跑一整套集成测试和冒烟测试。

持续交付≠自动上线。关键差异在于：是否保留一个人工审批的“门”。

# 典型的持续交付流水线
CI pass → 自动部署到 staging → 自动运行集成测试 → 测试通过后
→ 发送通知给负责人：“候选版本 v1.3.2 已就绪，请审批上线”
→ 负责人点击【批准】
→ 手动执行部署到生产

注意：持续交付要求你的类生产环境和生产环境尽可能一致。环境漂移是持续交付最大的敌人。我见过有些团队 staging 的机器配置是生产的一半，结果上线后直接 OOM。强烈建议使用基础设施即代码（IaC）来保证环境一致性。

1.5 持续部署 —— 全自动，零人工干预

持续部署是最终形态：代码一合入主干，自动测试、自动构建、自动部署到生产。整个过程没有人工按钮。

这不是所有团队都适合的。你想想看，如果测试覆盖率不到 80%，或者监控告警体系不完善，全自动部署就是在玩火。

什么样的团队适合持续部署？

有完善的单元测试、集成测试、端到端测试
有灰度发布 / 蓝绿部署 / 金丝雀发布机制
有快速的回滚能力（分钟级）
有实时的监控和告警系统

交付模式	人工审批	生产部署	典型场景
持续集成	每次提交	手动	小型团队 / 内部工具
持续交付	版本发布时	手动	金融、医疗等合规要求高的项目
持续部署	无	自动	SAAS 产品 / 互联网业务

1.6 CI/CD 的核心价值 —— 不只是快

很多新人以为 CI/CD 就是为了“快”。其实不然。它带来的价值是多维度的：

降低风险——每次变更很小，出问题也好排查。我遇到过一个大版本发布，上线后发现性能下降 50%，因为改动量太大，根本定位不到是哪一行代码导致的。现在用 CI/CD 做小步快跑，这种问题几乎绝迹。
提升团队信心——当每次提交都能自动验证，开发者心里有底。不用再提心吊胆地问“这个版本能上线吗？”
缩短反馈周期——从“写完代码两周后才知道有 bug”变成“写完代码 10 分钟后就知道”。反馈越快，修复成本越低。
自动化重复劳动——构建、测试、部署这些机械动作，让机器去做。人只做决策和代码编写。

  一句话总结 CI/CD 的价值：它把软件交付从“手工作坊”升级为“自动化工厂”。质量由流程保证，而非靠某个人拍胸脯。

1.7 本章知识结构图

1.8 落地时要注意什么

CI/CD 不是银弹。我见过不少团队上了 Jenkins / GitLab CI / GitHub Actions 后就以为“万事大吉”，结果流水线天天飘红，大家反而更累了。

这里分享几个我踩过的坑：

测试质量比测试数量重要——100 个从不失败的断言，不如 10 个真正有效的测试。如果你的测试从来不翻车，说明你的测试太弱了。
流水线要快，但不能牺牲可靠性——我见过有人把测试全删了只留构建，号称“速度提升 80%”。实际上只是加速了灾难的来临。
环境一致性是关键——本地能跑通、CI 能跑通、生产跑不通，90% 是因为环境差异。Docker 和容器化是最直接的解法。
失败时立刻停，不要等——流水线如果某个环节失败了，后面的环节不应该继续。否则你得到的是一个半成品，还得花时间清理。

曾经的教训：我曾经在一个项目中，CI 流水线里忘记加代码规范检查。结果两个月后，代码库变得乱七八糟，缩进混用、大括号位置不一致、命名毫无规范。重构成本高到不敢动。后来不得不花一周时间全量重构。从那以后，我每个项目的第一件事就是把 lint 和 format 检查塞进 CI。

1.9 本章小结

CI/CD 不是什么高深的理论，它就是一套自动化工程流程。你想想看，如果每次代码提交后系统能自动告诉你“没问题”或“这里错了”，你的开发效率能提升多少？

持续集成解决的是“代码能不能合”、持续交付解决的是“代码能不能上线”、持续部署解决的是“能不能自动上线”。这三个概念逐层递进，但都围绕着同一个目标：让软件交付变得可预测、可重复、高质量。

嗯，这就是 CI/CD 最核心的价值。后面的章节，我们会深入每个环节的实操细节，包括如何搭建流水线、如何设计测试策略、如何保证稳定性等。但无论讲得多深，地基就是今天这些概念——理解它们，后面的路才稳。