什么是 CI/CD？持续集成与持续交付简单解读
CI/CD 是一种软件交付方式：每一次代码变更都会被自动构建、测试，如果通过测试，就会被准备好发布，或直接发布。**CI（持续集成）**意味着变更会被频繁合并，并且每次都由自动化测试进行检查。**CD（持续交付或持续部署）**意味着通过检查的变更会被打包，并在很少甚至无需人工操作的情况下推送给用户。
核心理念很简单：在错误产生几分钟内就将其发现，而不是等几周后由客户找出来。
用 AI 构建应用时为什么 CI/CD 很重要
AI 构建工具的代码修改速度很快。一个提示词就可能涉及十几个文件。速度固然很好，但如果对结账页面的一处修改悄无声息地破坏了登录页面，而直到用户给你发邮件时才有人发现，那就糟糕了。
CI/CD 正是为此类问题准备的安全网。流水线不是盲目相信每次修改都没问题，而是每次都运行同样的检查：
- 应用是否仍能无错误地构建？
- 自动化测试是否仍然通过？
- 代码是否遵守项目规则（类型、格式、安全检查）？
如果任何一项检查失败，该变更就会在到达用户之前被拦截。代码修改得越快，一个永不疲倦、从不跳过步骤的检查机制就越有价值。
一个日常类比
想象一家每天早上向各家商店供应面包的面包房。
- 没有 CI/CD 时，每位烘焙师都会独自调整一周的配方，然后在周五晚上把所有改动合在一起，并祈祷面包仍然能发起来。一旦失败，没人知道是谁的改动导致的。
- 有了 CI 时，每一处小的配方改动都会立即烤一个试验面包，并进行检查——口感、重量、形状。糟糕的改动当天就会被发现，而且你能准确知道是哪一处改动造成的。
- 有了 CD 时，通过检验的面包会直接装上配送车，每次都以同样的方式打包和贴标签，而不是有人在凌晨五点手工装箱。
检验并不会让烘焙师变得更好，而是让他们的错误代价变得很低。
CI/CD 流水线如何运作
**流水线（pipeline）**是一系列步骤，当某件事情发生时——通常是有人把代码推送到 GitHub 等代码仓库时——CI/CD 服务会自动运行这些步骤。典型的流水线如下所示：
| 步骤 | 发生的事情 | 能发现的问题 |
|---|---|---|
| 1. 触发 | 代码被推送或拉取请求（pull request）被发起 | — |
| 2. 安装 | 一台全新的机器下载代码及其依赖项 | 缺失或损坏的软件包 |
| 3. 构建 | 应用被编译或打包 | 语法和类型错误、损坏的导入 |
| 4. 测试 | 运行自动化测试 | 不再正常工作的功能 |
| 5. 检查 | 代码检查（linting）、格式检查、安全扫描 | 风格问题、已知存在漏洞的软件包、泄露的密钥 |
| 6. 部署到预发布环境 | 应用被部署到生产环境的测试副本 | 只有在真实环境中才会暴露的问题 |
| 7. 部署到生产环境 | 应用正式上线——自动进行，或在审批后进行 | — |
每个步骤都在一台干净的机器上运行，而不是某人的笔记本电脑上，因此“在我的电脑上是好的”不再能作为借口。如果某个步骤失败，流水线就会停止，并通知进行修改的人。
这些步骤由一个与代码放在一起的配置文件定义。例如，在 GitHub Actions 中，它是代码仓库 .github/workflows 文件夹中的一个 YAML 文件。
持续交付与持续部署
“CD”这个词含义模糊，人们对它的理解有两种：
| 持续交付 | 持续部署 | |
|---|---|---|
| 自动运行测试 | 是 | 是 |
| 自动打包发布版本 | 是 | 是 |
| 自动上线 | 否——由人点击“发布” | 是——每一个通过测试的变更都会上线 |
| 适用于 | 大多数小型团队、拥有付费用户的应用 | 拥有完善测试覆盖和监控的团队 |
只有在测试质量良好的情况下，持续部署才能很好地发挥作用。如果你的测试没有覆盖结账流程，持续部署就会毫不犹豫地把一个有问题的结账功能发布出去。
实例演示：带流水线的预约应用
假设你有一个美发沙龙预约应用，代码存放在一个 GitHub 仓库中。你请 AI 构建工具“为首次到店的客户添加 10% 折扣”。
- 变更被推送到一个新分支，并发起一个拉取请求。
- 流水线启动，安装软件包并构建应用——这一步通过了。
- 流水线运行测试。其中一项测试“老客户按原价付款”失败了：折扣被应用到了所有人身上。
- 拉取请求显示一个红色叉号，该变更无法被合并。
- 你让 AI 修复问题。它推送了修正版本；流水线再次运行，所有测试都通过。
- 变更被合并。流水线将其部署到**预发布环境**，你可以在那里尝试一次测试预约。
- 你批准后，它被部署到生产环境。
如果没有这条流水线，第 3 步的问题就会直接出现在客户的账单上。
关键术语
| 术语 | 含义 |
|---|---|
| 流水线（Pipeline） | 在每次变更时自动运行的一系列步骤。 |
| 构建（Build） | 将源代码转换为可运行的形式。 |
| 自动化测试（Automated test） | 检查其他代码是否按预期工作的代码。 |
| 拉取请求（Pull request，PR） | 一个待合并的变更提案，合并前由其他人（以及流水线）审查。参见什么是 GitHub。 |
| 分支（Branch） | 一条独立的修改线，使进行中的工作不会影响主代码。 |
| 预发布（Staging） | 与生产环境保持一致的应用私有副本，用于在用户看到变更之前进行检查。 |
| 生产环境（Production） | 用户正在使用的线上应用。 |
| 回滚（Rollback） | 当发布出现问题时，恢复到之前可正常工作的版本。 |
| 绿色 / 红色构建（Green / red build） | 流水线运行通过 / 失败。 |
常见误解
- **“有了 CI/CD，我的应用就经过测试了。”**流水线只会运行你已经编写的测试。如果没有任何测试，CI 只能证明应用可以构建，仅此而已。请让 AI 为最重要的流程编写测试。
- **“CI/CD 只适用于大公司。”**像 GitHub Actions 这样的托管工具只需一个简短的配置文件即可设置，小型团队也经常使用。真正费力的是编写测试，而不是工具本身。
- **“自动部署意味着没有人检查任何东西。”**好的流水线是在增加检查，而不是减少检查。许多团队仍会在上线生产环境之前保留人工审批步骤。
- **“只要流水线是绿色的，应用就能正常工作。”**这只说明自动化检查已通过。你仍然应该亲自尝试这次变更，最好是在预览环境或预发布环境中进行。
- **“CI/CD 可以替代备份。”**并非如此。一次通过测试的糟糕数据库迁移仍然可能损坏真实数据。请保留备份，并准备好回滚的方法。
向你的 AI 构建工具提出的要求
- “为注册、登录和结账编写自动化测试，并向我展示如何运行它们。”
- “设置一个 GitHub Actions 工作流，在每个拉取请求上安装依赖、构建应用并运行测试。”
- “在流水线中添加类型检查和代码检查工具，并让出现错误时流水线失败。”
- “用通俗的语言解释流水线的每个步骤分别做什么。”
- “如果部署中途失败会怎样？我该如何回滚？”
- “检查代码仓库中是否硬编码了任何机密信息，或是否在流水线日志中打印了机密信息。”
如果你的应用使用 API 密钥，流水线同样需要它们——应作为加密机密存储在 CI 工具中，绝不能写入配置文件。参见环境变量与机密信息。
CI/CD 与 Mythex
Mythex 不会为你运行 CI 流水线，但它以自己的方式满足了其中的若干需求：
- 检查点。 每次智能体成功完成一轮操作后，Mythex 都会保存一个 git 检查点；如果某次修改出了问题，**恢复到此节点（Revert to this point）**即可将项目回滚。参见聊天。
- 应用测试。 输入
/test，智能体会像用户一样在你的实时预览中逐步操作，并报告损坏的流程——在每次发布前都很有用。参见应用测试。 - 发布是一个有意识的步骤。 变更首先出现在私有预览中；只有再次发布后，公开的应用才会更新——这更接近持续交付，而非持续部署。
- GitHub 同步（Pro）。 将项目同步到 GitHub 仓库后，你可以添加自己的 GitHub Actions 工作流，在每次推送时运行测试。参见GitHub 与导出。
如果需要在正式上线前手动测试的清单，请参阅如何在上线前测试你的应用；如果需要了解版本控制的使用方法，请参阅如何在 AI 构建的应用中使用 Git。
常见问题
CI/CD 是什么的缩写？
CI 代表持续集成：代码变更会频繁地合并，并自动构建和测试。CD 代表持续交付或持续部署：通过测试的变更会被自动准备好以供发布（交付），或者无需人工操作就直接发布给用户（部署）。
持续交付和持续部署有什么区别？
在持续交付模式下，每一个通过流水线的变更都已准备好发布，但仍由人来决定何时正式上线。在持续部署模式下，每一个通过测试的变更都会自动上线，无需人工审批。
用 AI 构建的小型应用需要 CI/CD 吗？
第一天不需要。拥有少量用户的小型应用可以通过预览环境测试、手动发布来应付。当多人同时修改代码、真实客户依赖这个应用，或者你不断破坏原本正常的功能时，CI/CD 才会真正体现价值。
CI/CD 使用哪些工具？
常见的工具包括 GitHub Actions、GitLab CI/CD、CircleCI 和 Jenkins，以及托管平台内置的部署流水线。它们做的都是同一件基本工作：每当代码变化时，自动运行一系列步骤。