【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 已经自动测试、构建了为什么有的公司还要人工点发布​ 答案就是CDContinuous Delivery / Deployment。它决定代码最终如何上线是人工触发还是自动上线。六、总结一次git push不只是上传代码而是触发了一台“自动部署机器人”。CI 的核心任务是保证每次合并到主分支的代码都是安全、可运行、可构建的。CI 消灭了手动部署中最大的风险人为出错和环境不一致。CD 决定代码最终如何上线这部分我们下一篇再聊。