CI/CD

1. 核心概念：什么是 CI/CD？

这两个缩写代表了自动化工作流的两个阶段：

• CI (Continuous Integration - 持续集成): 当你（或者你的团队）把代码 git push 到代码库（如 GitHub/GitLab）时，系统会自动触发一系列动作：检查代码格式规范、运行自动化测试（看看有没有低级 Bug）、以及执行打包编译（比如把前端的 TypeScript 编译成浏览器认识的 JS）。 目的：确保新写的代码“合规”且“不破坏老功能”，能成功集成到主线中。
• CD (Continuous Deployment/Delivery - 持续部署/交付): 在 CI 阶段确认代码没问题、且打包出成品后，系统会自动把这些成品（比如 .next 文件夹、Python 脚本）传输到生产服务器，并自动执行重启命令（如 pm2 restart）。 目的：让最新版本的代码安全、快速地呈现在用户面前，无需人工干预服务器。

2. 技术演进：从 WebHook 到现代流水线

业界是怎么一步步优化的：

阶段一：WebHook 触发器（你的构想阶段）

• 原理： 就像给服务器配了一部“专属座机”。GitHub 发现有新代码 push，就给服务器打个电话（发送一个 HTTP 请求）。服务器接听后，自己执行 git pull -> npm install -> npm run build -> 重启。
• 痛点：
  • 1. 服务器压力大： npm run build 是个极其消耗 CPU 和内存的重体力活。如果在生产服务器上直接跑打包，可能会导致服务器在打包的这几分钟内卡顿，甚至用户的正常访问都会变慢或崩溃。
  • 2. 环境污染： 服务器上除了运行环境，还得装一堆打包用的开发工具（DevDependencies）。

阶段二：CI/CD 平台（现代企业的主流选择）

为了解决上面的痛点，业界诞生了专门干苦力活的工具，比如 GitHub Actions、GitLab CI、Jenkins。

• 原理： 引入了一个叫做 Runner（执行器） 的中间人（通常是云端免费提供的一台临时服务器）。
• 流程巨变：
  1. 你本地 git push 到 GitHub。
  2. GitHub 启动一台临时的云端服务器（Runner）。
  3. 这台临时服务器拉取代码，在它上面执行耗资源的 npm run build。
  4. 临时服务器把打包好的纯净成品（压缩包）直接发送（比如通过 SSH/SCP）给你的生产服务器。
  5. 生产服务器只负责解压并执行 pm2 restart。临时服务器随即销毁。
• 优势： 你的生产服务器只负责运行，没有任何打包压力，绝对稳定。而且万一打包失败，报错会显示在 GitHub 网页上，根本不会影响到线上还在跑的旧版本。

3. CI/CD 流水线是如何工作的？

有了 CI/CD 之后，开发者的日常就会变成：只需关注本地写代码，写完 push 就行，剩下的测试、打包、上传、重启全部由机器在云端自动化完成。

组内导航：⬅️ Jenkins | 🏠 00-DevOps与运维 | ➡️ CI-CD流水线技术详解-对话存档