---
title: "06-CI-CD"
created: 2026-04-13
tags:
  - 项目
aliases:
  - CI-CD
---

# 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` 就行，剩下的测试、打包、上传、重启全部由机器在云端自动化完成。

---

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