我们正在迈向这样一个世界：你可以完全在 Cloudflare 上存储、构建、测试和部署代码。我们通过 Artifacts 构建了第一块拼图，这是一种可扩展到数百万仓库的版本化代码存储。
我们通过构建在 Cloudflare Workflows 之上的 CI SDK，将存储、构建和部署步骤串联在一起，这样你就可以在 Cloudflare 上运行持续集成（CI）流水线。你可以通过 wrangler 配置文件中的新 events 字段，将 artifact 推送事件直接发送到你的 Workflow，从而触发其实例执行——本质上就是一个 CI 任务。
然后，在安装了 @cloudflare/ci 的 Workflow 中，你可以直接：
- 自动化构建：在安全、隔离的环境中编译来自 Artifacts 仓库的代码
- 运行 linter 和类型检查：强制执行代码风格、捕获类型错误，并标记任何潜在问题
- 缓存依赖：运行一次安装，并在 CI 任务的各个步骤之间缓存依赖
- 执行单元测试：验证代码的每个部分是否按预期工作
- 自我修复：集成一个 AI 审查智能体，用于捕获构建中出错的步骤，并推送提交进行修复
- 条件部署：仅当构建步骤成功时，才自动部署你的代码
如今，每个人都在构建平台，无论是内部的 vibe coding 平台，还是通过代码定制来扩展面向客户的产品。平台现在使用 Artifacts 上的数百万个仓库来存储他们的代码、客户的代码，以及对两者进行版本控制。但每个团队对持续集成和部署流水线都有自己的需求。对于平台而言，他们可能希望为自己的代码定义 CI 任务的方式与为客户定义的方式有所不同。
在这些平台上构建的许多终端客户，并不想再为管理自己的持续集成和持续部署（CI/CD）流水线而多费心神。相反，平台可以代为管理客户的构建流程：将 CI/CD 流水线编写一次，并在其客户所构建的所有应用程序之间共享。平台的部分客户可能希望定义自己的 CI；如果是这样，他们可以编写自己的 Workflow，并借助动态工作流，仅在自己的仓库上运行自定义 CI 任务。妙处在于，你无需二选一：平台托管的 CI 和自定义 CI 可以同时运行，且位于同一个命名空间中。
CI/CD 流水线本质上就是一个 Workflow
在今天之前，我们已经拥有了让平台在 Cloudflare 上串联其 CI/CD 流水线所需的全部组件。现在，我们带来了更出色的开发者体验，让这一切变得简单。
CI/CD 流水线——通常借助 GitHub Actions 进行编排——是一系列按特定顺序运行的步骤，其中任何一步失败，都会停止流水线运行并报告错误。从本质上讲，CI/CD 流水线就是一个 Workflow。当 CI/CD 由 YAML 文件定义时，鉴于那些常常导致 YAML 疲劳的各种限制，它很快就会变得复杂。但 CI/CD 流水线中的每一步都可以简单地转化为 Workflow 的 step.do()。你可以不用 YAML，而是用 TypeScript 来定义 CI/CD 流水线，以获得更强的定制性和可配置性。
我们正在 CI SDK 中推出新工具，让你能够在安全、隔离的环境中运行 CI 流水线中的每一步（例如构建、代码检查和类型检查），该环境直接通过 Workflows 和 Sandbox SDK 构建在 Cloudflare 的开发者平台上。此外，你现在可以直接在推送（push）时启动 CI 任务，而无需再配置事件订阅、队列和队列消费者。
此前，你必须直接调用 Sandbox API，并自行管理 CI 流水线中不同步骤之间的状态。现在，SDK 允许你在自己的 Workflow 步骤中运行每条沙箱命令，并利用 Cloudflare Workflows 内置的重试和超时机制。
你还可以通过缓存步骤结果（例如安装步骤）来加速 CI 流水线，这样后续所有操作都无需重新安装。依赖缓存能降低 CI/CD 流水线的延迟，因为每个 CI 步骤都不需要重新执行安装。
要定义你的 CI 任务，你只需要：
- 为任何依赖项（CI 任务所需的外部包或工具）定义安装步骤，例如打包器（如 esbuild）、代码检查器（如 eslint）或测试运行器（如 vitest）。
- 为 CI 任务中的每个步骤指定命令（例如 bun run build、bun run test、bun run lint）。依赖缓存后，每个 CI 步骤可以并行执行，从而降低整体运行的延迟。
- 在部署步骤中传入 wrangler deploy。当 CI 流水线通过时，你的 Worker 将自动部署。
在 Workflow 中编写自己的 CI 流水线，可以让你随心所欲地进行自定义。例如，你可以从 CI Workflow 中调用一个智能体，为 CI 任务赋予自愈能力：如果构建中的某个步骤出错，智能体可以自动修复，并推送一个提交供你审批。
试用 Project Think 中的自愈 CI Workflows 示例：https://github.com/cloudflare/ci/blob/main/examples/self-healing
编写你自己的 CI Workflow
要编写你自己的 CI Workflow，请从 import { CIWorkflow } from@cloudflare/ci 开始。先写一个安装步骤：
- 下载你的依赖项，包括 CI 步骤所需的任何外部工具或库（例如 vite、react）。
- 指定你的 lockfile，它用于跟踪依赖项是否发生变化。
- 通过沙箱快照缓存你的依赖项，以便所有后续步骤都能访问。该快照将存储在你账户的 R2 bucket 中。
然后为构建和检查定义步骤，每个步骤都在各自安全、隔离的沙箱环境中执行。
默认情况下，Workflow 中的每一步都是独立启动的，也就是说，除非另有指定，否则各步骤将并发执行。并行运行每一步可以降低 CI 运行的延迟。为了确保在 CI 流水线继续之前所有检查都已完成（例如，在部署步骤开始之前完成构建、lint、测试和类型检查），请将其包裹在 `Promise.all()` 中：
现在，要真正触发你的 CI Workflow，需要在 Worker 的 wrangler 配置中添加一个 `events` 字段，与你的 Workflow 和 Artifact 绑定放在一起。`events` 字段是 `triggers` 字段中新增的一个字段。
你之前已经可以通过事件订阅，借助 Cloudflare Queues 订阅 Artifacts，并在每次有 push 事件时启动构建流水线。但这需要设置事件订阅、Queue、消费者和队列处理器。现在，你可以直接用该事件来定位 Workflow——每次该事件触发时，都会启动一个 Workflow 实例。
将 CI Workflow 指定为 artifact push 触发器的目标，即可在每次 `cf.artifacts.repo.pushed` 事件发生时自动触发一个 Workflow 实例。每次 CI 运行都会以 Workflow 实例的形式呈现，这样你就可以直接在 Workflows 仪表盘中查看其逐步执行情况和可观测性。这是一项以 Artifacts 为先的集成；不久之后，这些类型将支持来自你 Cloudflare 账户中各种来源的事件，以便在整个产品套件中进行程序化消费。
如果你想在命名空间中的每个仓库上运行 CI Workflow——例如，如果你是一个为所有客户仓库运行 CI 的平台——可以省略 `repoName`，只在 `filter` 中指定命名空间。
要完整配置你的 CI Workflow，需要为驱动流水线的每一块基础设施添加绑定：artifacts、workflows、containers 和 durable_objects（+ exports 配置）绑定（用于访问你的沙箱），以及如果你使用缓存，还需要一个 r2 绑定。R2 绑定是必需的，因为你的安装步骤沙箱快照会存储在一个存储桶中。
自愈式 CI 运行
要让你的 CI 任务实现自我修复，你需要两个组件：大语言模型及其智能体框架。在上面的示例中，我们包含了一个使用 Workers AI 的 Think 智能体，用于捕获流水线中的错误并代表你运行修复。你的 CI 任务可以在远程运行和重新运行——无需一直开着笔记本电脑盯着，也不必每隔几分钟就回来查看一次。相反，Cloudflare 在云端处理这一切，在容器中让修复智能体与 CI 步骤并行运行。你不再需要盯着 CI 任务、手动修复错误并重新运行流水线，只需在智能体完成修复后合并提交即可。
要设置一个能自我修复 CI 流水线的智能体，请为你的 Think 智能体添加一个 Durable Object 绑定：
通过扩展 HealingAgent 类来创建你的 Think 智能体——Healer，该类包含一个 heal 方法供你在失败时调用。传入你希望使用的任何模型：
然后，将你的步骤包裹在 try/catch 块中，当失败时触发修复智能体：
这个示例演示了自我修复的 CI 流水线，但实际上，自带工作流（Bring Your Own Workflow）模式允许你随心所欲地定制 CI 任务。这可以成为添加安全规则、过滤器或条件性 CI 步骤的地方。使用 BYO-W 模式，平台可以根据每个具体用例，为不同团队、客户或应用配置其 CI/CD 流水线。
使用工作流的好处
通过在 Cloudflare Workflow 上运行你的 CI 流水线，你将自动获得：
- 弹性重试（持久化执行）：如果你的 CI 任务中任何步骤失败，它都会自动重试并保持状态持久化，这意味着不会丢失任何进度。每个步骤都支持自定义重试和超时行为，因此你可以为每个步骤定义不同的失败逻辑。此外，你可以从特定步骤重新开始，例如，如果只是 lint 失败，你就不必重新运行整个 CI 流水线。
- Workflows 可观测性：在 Workflows 仪表盘中逐步检查你的 CI 任务，每个实例都会展示各步骤的输入、输出以及墙钟时间和 CPU 时间。你可以通过仪表盘中的 Workflows 图表直观查看 CI 任务，轻松识别哪些步骤是并发运行、哪些是顺序执行的。你还可以通过 Workers Observability 和 GraphQL 检查 Workflows 日志，更深入地了解 CI 任务的运行情况。
- 代码的力量：通过在 Workflow 中运行 CI，你可以为任何需求编写步骤。例如，你可能希望在 CI/CD 流水线中运行一个 AI 代码审查器。你可以通过 Workflows 的 step.do() 调用你的代码审查智能体——或处理任何你能用代码实现的定制逻辑。其他示例可能包括将构建产物写入 R2，以及在 CI 失败、完成或合并到 main 分支时发送电子邮件。
下一步计划
CI/CD 流水线本质上就是一个 Workflow——借助 CI SDK，你可以用简洁的 TypeScript（而非僵化的 YAML）在代码中定义 CI，无论是你自己的代码还是客户的代码。基于 Cloudflare Workflows 原语，你可以定义任何你想要的逻辑，无论是像我们的 Think 示例那样的自愈智能体，还是将构建产物写入 R2。在 Workflows 上运行 CI 有助于弥合存储（通过 Artifacts）、构建和部署之间的鸿沟。作为一个平台，这让你能够轻松管理自己代码以及代表客户管理的每一步。
申请加入 Artifacts 私有测试版，并通过我们的 Workflows CI 指南开始使用。如果你有任何功能需求或发现任何 bug，欢迎加入 Discord 上的 Cloudflare Developers 社区，直接向 Cloudflare 团队分享你的反馈。
即将推出的功能：
- Workers 与 Workers for Platforms 的直接集成：build.preview() 和 build.deploy() 原语，可在推送到 main 分支时自动部署，并在推送到非默认分支时创建预览
- 渐进式部署：通过 Workflows 管理基于百分比的发布，自定义你的部署推进和回滚逻辑
- Monorepos：使用一条 CI 流水线简化多 Worker 部署的管理
- 触发器：从不同来源发送推送事件，以便在任何版本控制系统（而不仅仅是 Artifacts）上对仓库运行 CI 任务。