来源：https://github.com/datawhalechina/vibe-vibe

本节目标：理解 CI/CD 的核心概念，让代码推送后自动完成构建、测试和部署。

小明部署成功后的第二天，他修了一个 bug，推送到 GitHub。过了几分钟，他打开网站一看——bug 已经修好了。

"我没点部署啊？"小明有点懵。

其实，从 12.1 连接 GitHub 的那一刻起，小明就已经在用 CI/CD 了——只是他不知道。

你已经在用 CI/CD 了

CI/CD 听起来很高级，但用大白话说就是两件事：

• CI（持续集成）：每次推送代码，自动运行检查和构建，确保代码没问题
• CD（持续部署）：检查通过后，自动发布到线上

你写代码 → git push → 自动检查 → 自动构建 → 自动部署 → 用户看到新版本

你只负责写代码和推送，中间的一切都是自动的。

当你在 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 就生效了。

实战案例：本教程的 CI/CD 配置

本教程仓库使用的是 CNB 平台的 CI/CD，配置文件是 .cnb.yml。虽然平台不同，但核心思路和 GitHub Actions 完全一样——都是"在什么时候、做什么事"。

分支策略：

• master 分支推送 → 自动部署到生产环境（vibe-vibe-production）
• develop 分支推送 → 自动部署到开发环境（vibe-vibe-develop）
• PR 创建 → 自动构建验证
• PR 可合并 → 自动 squash merge 并删除源分支

部署流程（和你的项目一样）：

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 自动验证和合并。你的个人项目不需要这么复杂，但当项目成长到需要多环境时，这就是一个可参考的模板。