CI/CD 是什么：概念、流程与常见组件
约 2169 字大约 7 分钟
布欧-Lewyon
2026-06-04
前言
CI/CD 是持续集成（Continuous Integration）与持续交付/部署（Continuous Delivery / Deployment）的合称。名字听起来抽象，本质只有一件事：让「提交代码 → 可运行产物 → 上线」尽量自动化、可重复、可追踪。
本文从概念到流水线结构做系统梳理，便于对照实践文档理解「构建阶段」「部署阶段」「制品」「Agent」分别扮演什么角色。文中示例均为通用描述，不绑定具体站点或服务器地址。
1. 为什么需要 CI/CD
手工发布典型步骤：拉代码、装依赖、编译、打包、登录服务器、拷贝文件、重启服务、祈祷没配错。
问题显而易见：
| 问题 | 后果 |
|---|---|
| 步骤靠记忆 | 新人无法发布，老人也会漏步骤 |
| 环境不一致 | 本地能跑，服务器报错 |
| 反馈慢 | 问题到上线才发现 |
| 难以回滚 | 不知道上一版产物在哪 |
CI/CD 把上述步骤固化成 流水线（Pipeline）：每次 push 或合并时自动执行同一套脚本，日志可查、失败可重跑、成功可复现。
2. CI 与 CD 分别指什么
2.1 CI：持续集成
目标：频繁把代码集成到主干/共享分支，并尽快验证「能不能正确构建、测试是否通过」。
常见动作：
- 安装依赖（
npm install/pnpm install） - 静态检查（Lint、类型检查）
- 单元测试
- 编译/打包（生成
dist、JAR、镜像等）
产出：通过验证的 构建制品（Artifact），例如静态站目录、可执行包、Docker 镜像。
2.2 CD：持续交付与持续部署
两者常被统称 CD，细微差别如下：
| 术语 | 含义 |
|---|---|
| 持续交付（Delivery） | 制品随时「可发布」，但上生产可能仍需人工点一下 |
| 持续部署（Deployment） | 通过流水线后 自动 部署到目标环境 |
个人站点、内部文档站多采用 持续部署：构建成功 → 自动同步到服务器。
2.3 一句话对照
CI 负责「把代码变成可靠的制品」
CD 负责「把制品放到用户能访问的环境」3. 流水线里有哪些概念
3.1 Pipeline（流水线）
一次完整的自动化流程，通常由 触发器 启动，包含一个或多个 阶段（Stage）。
3.2 Stage（阶段）
阶段之间常有顺序依赖：例如 先构建、后部署。某阶段失败则后续阶段可不执行（或标记为跳过）。
3.3 Step / Job（步骤 / 任务）
阶段内的具体执行单元，例如：
- 在 Node 镜像里执行
pnpm docs:build - 在目标主机上执行
rsync同步文件
3.4 Trigger（触发器）
| 类型 | 说明 |
|---|---|
| Push | 推送到指定分支时运行 |
| Pull Request | 合并请求时运行（常用于检查，不一定部署） |
| 定时 | Cron 表达式 |
| 手动 | 在平台点击「运行流水线」 |
3.5 Artifact（制品）
构建阶段输出的 可部署物，平台会打包上传供后续阶段下载。
示例：
- 静态站：
dist/目录 → 打成BUILD_ARTIFACT.tar.gz - 后端：
app.jar - 容器：
image:tag
要点：部署阶段引用的制品 名称、路径 必须与构建阶段声明一致，否则会出现「找不到制品」。
3.6 Agent / Runner（执行环境）
| 环境 | 运行位置 | 典型用途 |
|---|---|---|
| 云端构建机 | 平台提供的容器/虚拟机 | 编译、测试（无状态、可扩容） |
| 自托管 Agent | 你自己的服务器上安装的代理 | 部署到本机目录、访问内网资源 |
静态站场景常见组合：云端构建 + 服务器 Agent 部署（构建不占站点机器资源，部署在目标机执行 rsync）。
4. 用一张图串起来（静态站）
以「VuePress 文档站 + 主机 Agent 部署」为例（与具体厂商无关）：
对应到你在平台里看到的日志块：
- 构建日志：Node 版本、
pnpm install、docs:build、页面数。 - 制品上传：
BUILD_ARTIFACT成功/失败。 - 部署日志：下载 tar、
find index.html、rsync、是否 Permission denied。
5. CI/CD 与「只写 YAML」的关系
很多平台（含 Gitee Go、GitHub Actions、GitLab CI）用 YAML 描述流水线，但 YAML 只是 声明式配置，真正执行的是：
- 平台调度器（何时跑、用什么镜像）
- 你写的 shell 命令（构建、部署脚本）
常见误区：
| 误区 | 事实 |
|---|---|
| 有 YAML 就等于有 CI/CD | 若平台 UI 仍绑定旧模板，仓库里的 YAML 可能未生效 |
| 部署失败一定是代码问题 | 可能是目录权限、Nginx、制品名、Agent 离线 |
| 构建成功等于上线成功 | 部署阶段、运行时配置（Nginx、环境变量）仍可能失败 |
因此需要 两份文档：一份讲概念（本文），一份讲落地步骤（实践文）。
6. 环境分层：dev / staging / prod
成熟团队常区分环境：
| 环境 | 目的 | 触发方式 |
|---|---|---|
| 开发 | 快速验证 | 推 feature 分支 |
| 预发 | 接近生产的演练 | 推 develop / release 分支 |
| 生产 | 用户访问 | 合并 main + 手动批准或自动 |
个人知识库常见简化：单分支 push → 直接部署生产。扩展时可为 main 与 develop 各配一条流水线，或同一流水线内用变量切换 DEPLOY_DIR。
7. 与 DevOps、IaC 的边界
| 概念 | 关注点 |
|---|---|
| CI/CD | 代码变更后的构建与发布自动化 |
| DevOps | 开发、运维协作文化与工具链（CI/CD 是其中一环） |
| IaC（Infrastructure as Code） | 用 Terraform/Ansible 等声明服务器、网络、负载均衡 |
静态站个人项目往往 CI/CD + 手工 Nginx 配置 即可；业务变大再引入 IaC 管理多台机器。
8. 如何读懂一次失败的流水线
建议按阶段排查，而不是从头滚日志：
1. 触发是否成功？（分支规则、Webhook）
2. 构建：依赖安装 / 编译错误 / Node 版本
3. 制品：路径是否匹配、上传是否中断
4. 部署：Agent 是否在线、脚本语法、目标目录权限
5. 运行时：Nginx、端口、缓存、HTTPS 误用构建失败 → 改代码或构建脚本。
部署失败 → 改 Agent 脚本或服务器权限。
部署成功但访问不对 → 查 Web 服务器与浏览器缓存（已超出 CI/CD，属于运行时）。
9. 选型时看什么
| 维度 | 问题 |
|---|---|
| 托管位置 | 代码是否在 Gitee / GitHub / GitLab |
| 构建资源 | 是否提供 Node/Java/Docker 镜像，版本是否够新 |
| 部署模型 | 仅 SSH/rsync，还是 K8s、对象存储、CDN |
| 私有网络 | 是否需要 Agent 进内网机器 |
| 免费额度 | 构建分钟数、并发、制品保留天数 |
| 配置方式 | 仓库 YAML 与平台 UI 谁优先 |
个人静态站：代码托管平台自带的 Go / Actions + 单机 Agent 通常性价比最高。
10. 小结：概念对照表
| 术语 | 你可以这样记 |
|---|---|
| CI | 自动构建 + 测试，产出制品 |
| CD | 自动（或半自动）把制品发布出去 |
| Pipeline | 从触发到上线的整条流水线 |
| Stage | 构建 / 部署等大步骤 |
| Artifact | 构建结果压缩包，给部署用 |
| Agent | 跑在你服务器上的「部署执行器」 |
rsync | 把制品目录同步到站点根目录的常见方式 |
理解上述概念后，再阅读实践类文档（例如同目录下的部署记录），可以把「某一行日志为什么报错」对应回「哪一个环节」——这比死记命令更有用。
11. 延伸阅读（本站）
- Gitee Go + Agent 部署 VuePress 静态站实践：与本文配套的手把手落地记录
- 运维部署常见问题与 Linux 常用命令：权限、Nginx、MIME 等排错速查
- Nginx 入门：部署成功后的反向代理与静态资源配置
CI/CD 不是额外负担，而是把「你会重复做第三遍的事」交给机器。从单条流水线、单台服务器开始即可；等分支和环境变多，再在同一个概念框架上扩展。