认识CI/CD：持续集成、持续交付、持续部署
说实话，我刚入行那会儿，CI/CD 这三个字母对我来说就是一串缩写。什么持续集成、持续交付，感觉就是换个说法搞自动化。直到在一次项目中，团队手动合并代码花了三天，最后上线时出了大问题——打回重来的成本比写代码还高。
嗯，从那以后我就明白了：CI/CD 不是锦上添花，而是保命工具。
到底什么是 CI/CD？
咱们先拆开看。这三件事其实是一套流水线，把代码从提交到上线的过程分段自动化。
| 缩写 | 全称 | 一句话解释 |
|---|---|---|
| CI | 持续集成 | 代码频繁合并，每次合并自动构建+测试 |
| CD1 | 持续交付 | 确保代码随时可以部署到生产环境（但手动触发） |
| CD2 | 持续部署 | 自动部署到生产环境，无需人工审批 |
你看，本质上就是从「写完代码跑一遍测试」到「一键上线」的进化。我个人习惯把 CI 理解为「质量门」，把 CD 理解为「发布阀」。
一个小技巧： 如果团队刚起步，先做到 CI 就够了。我见过太多团队一上来就想搞全自动部署，结果流水线裂成了蜘蛛网……
CI/CD 核心流程长什么样？
下面这张图是我自己画的一个简化版流程，你一看就懂。
简单说下流程：你提交代码到仓库 → 自动触发构建、跑单元测试、跑集成测试 → 如果全部通过，进入交付/部署决策 → 最终上线。为什么会分成两条路径？因为持续交付和持续部署的最大区别就是——有没有人按那个按钮。
为什么非要搞 CI/CD？
我再给你讲个真事儿：以前团队做一个小功能，三个人同时改同一个模块。改完大家各自跑了一遍本地测试，没问题。结果合并的时候，冲突处理错了，一个变量被覆盖，上线后用户登录全挂。那次事故的修复花了整整两天。
有了 CI，每次合并都会自动拉取最新代码、编译、跑测试。你想想看，冲突可能在代码提交后的几分钟内就被发现，而不是等到上线前一秒。
- 减少集成痛苦：频繁集成，问题早暴露，修复成本低
- 提高发布信心：每次提交都有自动化验证，心里有底
- 加速交付节奏：从「一周发一次」变成「一天发多次」
- 降低人工失误：手动漏掉测试、漏打标签？再也不担心了
核心观点： CI/CD 不是工具，而是一种工程纪律。我的经验是，团队只要坚持三个原则——代码必测、构建必过、部署可回滚——哪怕用最简单的 Jenkins + shell 脚本，也能把交付速度提升一个量级。
避坑指南
我曾经在一家公司看到，流水线跑了整整两个小时还没结束。为什么呢？因为把所有测试都塞进去了，包括那些跑一次要20分钟的端到端测试。结果大家都等着，一上午就没了。
所以我的建议是：
- 分层测试：单元测试（快）→ 集成测试（中等）→ 端到端测试（慢）。每一层都设置合理的超时。
- 不要过度自动化：刚开始手动部署比自动快？那就别上 CD，先做好 CI 再说。
- 关注流水线的“健康度”：我见过流水线三天两头红，大家习以为常，最后变成了摆设。红线必须立刻处理。
警告： 别把 CI/CD 当成银弹。如果代码质量本身一塌糊涂，自动化只是让烂代码跑得更快。先建好代码规范和测试覆盖，再上流水线。
好了，这一章就这么多。搞清楚这些概念，后面的配置实战你就知道每一块是干什么的了。