部署与运行
持续集成与持续部署CI/CD
你可能会问
持续集成与持续部署到底是什么？为什么代码一合并，网站自己就更新了？
简单来说
自动执行测试、构建和发布，减少手动操作带来的错误。
手动发布流水线发布靠自觉，还是靠流程
周五晚 · 手一抖周五晚 · 机器不抖流程固化，发布才敢频繁
01 · 先这样理解
把抽象概念放进真实场景
自动执行测试、构建和发布，减少手动操作带来的错误。
换个角度想CI/CD 像自动洗车机：以前洗车靠人拿水管，认真不认真看心情；进了洗车机，每辆车都是同一套流程出来的。
02 · 点击演示
每次发布五道工序，漏一步就出事，怎么办？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 改动合入主线
提交「新增导出功能」接下来把它发上线 「小改动，测试就不跑了吧」
一个老功能被悄悄改坏
全量测试自动跑
214 个用例 · 全绿才放行
- 在自己电脑上打包
环境装过一堆全局依赖产物「在我电脑上是好的」干净环境从头构建环境每次全新产物跟谁的电脑都无关 - 手一抖传错目录，线上挂了半小时五道工序，每道都可能出人祸稳定上线和上次一模一样的流程，几分钟完成机器不嫌烦，也不会漏步骤
1 / 4
Push · 代码合入仓库
03 · 放进真实任务
什么时候会遇到它
发布不再是大事
每天发几次也不慌，因为每次流程都一模一样。
AI 改动的守门员
Agent 提的代码必须过全量测试，才能走到线上。
消灭环境差异
统一环境构建，「在我电脑上是好的」不再出现。
04 · 想一想
用一个问题检查理解
团队每次发布都要一个人手动跑测试、打包、上传服务器，偶尔漏一步就出事故。怎么改进？
查看答案
把这套步骤写成 CI/CD 流水线：合并代码自动触发测试、构建、部署。人会漏步骤，机器不会——发布事故大多数就是这么消灭的。
最容易踩的坑
CI/CD 的底气来自测试。测试稀疏的流水线只是「自动化地裸奔」——自动化越快，坏代码上线也越快。