---
title: "12.3 CI/CD 与自动化"
---
# 12.3 CI/CD 与自动化
> **本节目标**：理解 CI/CD 的核心概念，让代码推送后自动完成构建、测试和部署。
小明部署成功后的第二天，他修了一个 bug，推送到 GitHub。过了几分钟，他打开网站一看——bug 已经修好了。
"我没点部署啊？"小明有点懵。
其实，从 12.1 连接 GitHub 的那一刻起，小明就已经在用 CI/CD 了——只是他不知道。
## 你已经在用 CI/CD 了
CI/CD 听起来很高级，但用大白话说就是两件事：
- **CI（持续集成）**：每次推送代码，自动运行检查和构建，确保代码没问题
- **CD（持续部署）**：检查通过后，自动发布到线上
你只负责写代码和推送，中间的一切都是自动的。
当你在 12.1 把 GitHub 仓库连接到 EdgeOne Pages 时，平台在 GitHub 上注册了一个 **webhook**。就像你在淘宝下单后物流系统主动给你发短信"已发货"——你不需要每隔五分钟刷一次物流页面。webhook 就是这种"有事主动通知"的机制：每次你 `git push`，GitHub 会主动通知 EdgeOne："嘿，有新代码了。" EdgeOne 收到通知后，自动拉取代码、安装依赖、执行构建、发布上线。
这就是"推送即部署"，也是最简单的 CI/CD。
## 平台内置的 CI/CD
如果你用的是 EdgeOne Pages、Vercel、Cloudflare Pages 这类平台，CI/CD 已经内置了，不需要额外配置。连接 GitHub 后，平台会自动响应三种事件：
- **推送到 `main` 分支** → 自动部署到生产环境（用户访问的正式版本）
- **创建 Pull Request** → 自动构建并生成预览链接
**预览链接是 CI/CD 最直观的产物。**
## 什么时候需要自定义流水线
平台内置的"推送即部署"对个人项目已经够用了。但随着项目变复杂，你可能想在部署之前多做一些事情：
- 自动运行测试，确保新代码没有破坏已有功能
- 自动检查代码风格，保持代码整洁
- 自动检查类型错误，避免低级 bug 上线
小明的朋友提了一个建议："我们加个自动测试吧，免得合并了有 bug 的代码。"这正是第九章测试那一节的延续——你写了测试，但每次都要手动跑，容易忘。如果能在每次推送时自动跑测试，就不会有遗漏了。
这时候就需要 **GitHub Actions**——GitHub 自带的 CI/CD 工具。
## GitHub Actions：自动化菜谱
GitHub Actions 通过 `.github/workflows/` 目录下的 YAML 文件来配置。你可以把它理解成一份"菜谱"：告诉 GitHub 在什么时候、按什么步骤、做什么事。
典型的配置包含三个部分：
**触发条件（`on`）**：定义什么时候运行。比如推送到 `main` 分支时，或者创建 PR 时。
**运行环境（`runs-on`）**：指定在什么系统上运行（通常是 `ubuntu-latest`）。GitHub 会启动一台临时虚拟机来执行任务——用完就销毁，确保每次运行环境都是干净的。
**执行步骤（`steps`）**：具体要做的事情，按顺序执行：
1. 拉取代码
2. 安装依赖（pnpm/npm）
3. 检查代码风格（lint）
4. 构建项目（build）
5. 运行测试（test）
**GitHub Actions 就是一份菜谱：拉代码、装依赖、检查格式、构建、测试。** 和你在本地开发时做的事一模一样，只不过每次推送都会自动执行一遍。
如果某一步失败了（比如测试没通过），整个流水线会停下来，GitHub 会在 PR 页面上显示一个红色的 ✗。这意味着这个 PR 的代码有问题，不应该合并。
## 分支与部署环境
在第十一章你学了分支的概念。在 CI/CD 的语境下，不同的分支通常对应不同的部署环境：
- **`main` 分支**对应生产环境——所有用户访问的正式版本。代码合并到 `main` 就意味着上线。
- **`feature/*` 分支**对应预览环境——每个 PR 自动生成的预览链接，只有 PR 参与者能看到。
个人项目通常只需要这两层就够了。如果团队协作需要更多环境（比如 `develop` 分支对应开发环境），部署平台都支持配置，让 Claude Code 帮你设置即可。
## 个人项目需要 GitHub Actions 吗
说实话，大部分个人项目不需要。部署平台内置的"推送即部署"已经覆盖了最核心的需求。
**什么时候该加 GitHub Actions？** 当你有了协作者，或者项目的测试覆盖率上来了。如果你在第九章写了一套测试，希望每次 PR 都自动跑一遍，那就值得加一个 GitHub Actions 配置。
**怎么加？** 直接告诉 Claude Code：
> "帮我配置 GitHub Actions，在每次 PR 时自动运行 lint、build 和 test"
Claude Code 会帮你生成 `.github/workflows/` 下的配置文件，你只需要提交到 GitHub 就生效了。
::: tip 渐进式自动化
不要一开始就追求完美的 CI/CD 流水线。先用平台内置的"推送即部署"，等项目复杂了、有了协作者、有了测试，再逐步加上 GitHub Actions。自动化是为了省事，不是为了折腾。
:::
### 实战案例：本教程的 CI/CD 配置
本教程仓库使用的是 CNB 平台的 CI/CD，配置文件是 `.cnb.yml`。虽然平台不同，但核心思路和 GitHub Actions 完全一样——都是"在什么时候、做什么事"。
**分支策略：**
- `master` 分支推送 → 自动部署到生产环境（`vibe-vibe-production`）
- `develop` 分支推送 → 自动部署到开发环境（`vibe-vibe-develop`）
- PR 创建 → 自动构建验证
- PR 可合并 → 自动 squash merge 并删除源分支
**部署流程（和你的项目一样）：**
```bash
pnpm install --frozen-lockfile # 安装依赖
pnpm build # 构建站点
edgeone pages deploy # 部署到 EdgeOne Pages
```
**环境变量管理：**
通过 `imports` 引入私密配置文件（类似 GitHub Secrets），避免把 API Token 写在配置里。
**YAML 锚点复用：**
用 `&docs_deploy_pipeline` 定义一次部署流程，然后用 `<<: *docs_deploy_pipeline` 在多个地方复用，避免重复配置。
这个配置展示了一个完整的多环境 CI/CD 流程：开发分支自动部署到测试环境、主分支自动部署到生产环境、PR 自动验证和合并。你的个人项目不需要这么复杂，但当项目成长到需要多环境时，这就是一个可参考的模板。
---
::: info 下一步
CI/CD 配好了，代码推送即上线。接下来了解 [12.4 运维基础与成本优化](./04-operations-cost.md)，学会监控应用状态和控制成本。
:::