【CI/CD】02_一次 git push 后发生了什么？CI 是怎么工作的

前篇：【CI/CD】01_为什么手动部署是个危险游戏

​ 上一篇我们聊过，手动部署是一场危险游戏：SSH 登录、拉代码、重启服务，每一步都可能出错。

​ 如果你曾经也是算法工程师，就会明白，上线其实很抽象，但危险却很真实。那么问题来了：现在很多团队说用 CI/CD，一次 push 就能自动测试、构建甚至上线，它到底在干什么？

​ 这篇文章，我们就拆开这个"魔法"。

一、CI/CD 不是工具，而是一条流水线

• 很多新人一听 CI/CD，第一反应是：
  • Jenkins、GitHub Actions、GitLab CI......
  • "安装它就行了？"
• 其实不对，CI/CD 本质上不是工具 ，而是一条自动化流水线 ：它把原本需要人工执行的部署流程，变成了机器自动执行的规则。
• 换句话说：
  • 你手动做的每一步：拉代码、安装依赖、构建、重启服务
  • CI/CD 都会自动做
  • 而且不会忘、不会出错、每次都一样

二、一次 push 后，流水线发生了什么

​ 当你执行：

git push origin main

​ 表面上只是把代码上传到远程仓库，但 CI/CD 眼里，整个世界开始运转：

​ 也就是说，push = 启动远程机器人，机器人按照规则完成你以前手动做的每一步。

三、CI 在做什么（Continuous Integration）

​ CI，全称 Continuous Integration（持续集成），解决的是一个核心问题：这份代码，真的可以安全地合进主分支吗？

​ 在多人协作中，每天都会有新功能提交 、Bug 修复、Hotfix 合并，如果没有 CI，主分支很快就会变成"不稳定版本"。

• CI 的工作就是：
  • 拉取最新代码
  • 安装依赖（npm install / pip install ...）
  • 运行单元测试
  • 进行代码规范检查（lint）
  • 尝试构建项目
• 如果任何一步失败，流水线立即停止，合并被阻止。

四、CI 的核心优势

​ 以下场景我们经常遇到：

• 今天部署的人使用 Node 18
• 下周同事部署时服务器升级成 Node 20
• 某次 npm install 下载了更新后的依赖版本
• 有人手动修改过服务器配置，却没有记录

​ 结果就是代码没变，但是运行结果却变了，这类问题在工程中有一个经典名字："在我电脑上是好的"（Works on my machine）

手动部署	CI
人执行步骤，容易忘	机器执行步骤，永远一致
每次手动部署时，服务器的运行环境可能并不完全一致	环境标准化，可复现
没有记录	全流程可追溯

​ CI 并不是让代码"自动变正确"，而是让每一次执行环境完全一致，从而消灭人为带来的不确定性。

五、为什么还有 CD？

​ 现在你可能会问既然 CI 已经自动测试、构建了，为什么有的公司还要人工点发布？

​ 答案就是 CD（Continuous Delivery / Deployment） 。它决定代码最终如何上线，是人工触发还是自动上线。

六、总结

1. 一次 git push 不只是上传代码，而是触发了一台"自动部署机器人"。
2. CI 的核心任务是：保证每次合并到主分支的代码都是安全、可运行、可构建的。
3. CI 消灭了手动部署中最大的风险：人为出错和环境不一致。
4. CD 决定代码最终如何上线，这部分我们下一篇再聊。