06 - 什么是 CI/CD，它解决什么问题
现代部署的引擎是 CI/CD。我们先不急着讲它的定义，而是从”没有它的时候有多痛”讲起——这样你才能真正理解它存在的意义。
先感受”手动部署”的痛
回忆第 01 章，你每次想更新线上代码，得手动做这些：
- 打开终端，SSH 登录服务器
git pull拉最新代码- 装可能新增的依赖
- 前端重新
build - 重启后端服务
- 刷新 Nginx，清缓存
- 打开网站，祈祷它没坏
这套流程手动做，会带来一连串问题：
- 容易漏步骤：忘了装依赖、忘了重启，线上就崩了
- 容易出错：命令敲错、传错文件、连错服务器
- 谁会谁不会：只有那个”懂部署的人”能发版，他请假了就没人敢动
- 半夜发版：为了不影响用户，只能挑深夜发，发到崩溃还得连夜回滚
- 无法追溯：线上到底是哪个版本的代码？谁也说不清
一句话：手动部署 = 又慢、又容易错、又依赖某个人、又没法追溯。
CI/CD 是什么
CI/CD 就是把上面这套流程自动化：你只要把代码 push 到仓库，剩下的构建、测试、部署，全部由机器自动完成。
它由两部分组成：
CI = Continuous Integration（持续集成）
“持续地把大家的代码合到一起，并自动检查有没有问题。”
每次有人提交代码，就自动：拉代码 → 装依赖 → 跑测试 → 构建。目的是尽早发现问题——别等上线了才发现代码是坏的。
类比：一群人合写一本书，每人写完一段就立刻自动校对、和整本书拼一次，而不是全写完了才发现互相矛盾、改到崩溃。
CD = Continuous Delivery/Deployment（持续交付/部署）
“检查通过的代码，自动发布到线上。”
CI 把代码验证、打包好之后，CD 负责把它自动部署到运行环境（比如推到 OSS/CDN、部署到 Serverless）。
CI 管”把代码变成一个可用的、验证过的成品”，CD 管”把这个成品自动送到线上”。合起来就是 CI/CD。
CI/CD 到底解决了什么问题
把它对着上面的痛点看：
| 手动部署的痛 | CI/CD 怎么解决 |
|---|---|
| 容易漏步骤 | 步骤写成脚本，每次一模一样地执行 |
| 容易出错 | 机器执行，不会手抖敲错命令 |
| 依赖某个人 | 谁 push 都能触发，不用”懂部署的人” |
| 半夜发版 | 一键/自动发布，还能一键回滚，随时发 |
| 无法追溯 | 每次部署都有记录，知道上的是哪个版本 |
| 上线才发现代码坏了 | CI 阶段自动测试，坏代码根本上不了线 |
[配图：左边”手动”——开发者深夜对着终端逐条敲命令、满头大汗；右边”CI/CD”——开发者 push 完就去喝咖啡，流水线自动把代码送上线]
小结
- 痛点：手动部署慢、易错、依赖人、难追溯、发现问题太晚。
- CI = 持续集成：每次提交自动拉代码、测试、构建，尽早发现问题。
- CD = 持续交付/部署：把验证过的成品自动发布到线上。
- CI/CD 的价值：让”push 代码”到”上线”这条路变得自动、可靠、可追溯、人人可发。
知道了它解决什么问题，下一章我们拆开看：一条 CI/CD 流水线，具体分哪几步、每步在干嘛。
下一章 → 07 - 一条 CI/CD 流水线的主流程