Vibe Vibe

主题

12.3 CI/CD 与自动化 ​

本节目标：理解 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 → 自动构建并生成预览链接

image-20260302013311084

预览链接是 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 流水线。先用平台内置的"推送即部署"，等项目复杂了、有了协作者、有了测试，再逐步加上 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 自动验证和合并。你的个人项目不需要这么复杂，但当项目成长到需要多环境时，这就是一个可参考的模板。

下一步

CI/CD 配好了，代码推送即上线。接下来了解 12.4 运维基础与成本优化，学会监控应用状态和控制成本。