Lakebase and Agentic SDLC: Branching Databases for Coding Agents

Lakebase 与 Agentic SDLC：面向编码代理的数据库分支 | Databricks 博客

跳至主要内容

Lakebase

2026年10月8日

Lakebase 与 Agentic SDLC：面向编码代理的数据库分支

作者：Thibaut Gourdel

摘要

• 为什么数据库是并行运行编码代理时被忽视的瓶颈，以及 Lakebase 的写时复制分支（亚秒级、可扩展至零）如何为每个代理提供独立的数据库。

• 端到端开发流程：Git worktrees + 自动为每个代理创建 Lakebase 分支的 Claude Code 钩子，然后通过 GitHub Actions 为每个 PR 创建临时分支，运行 Drizzle 迁移，在 Databricks Apps 上部署预览应用，并发布模式差异。

• 更多分支工作流：时间点缺陷复现、安全模式迁移测试，以及通过 Unity Catalog 遮蔽实现的生产衍生数据。

AI 改变了软件构建的方式。随着编码代理承担越来越多的开发工作，开发者正越来越多地转向协调这些代理。并行运行多个代理已成为常态，相关工具也随着发展，从技能和钩子到 MCP、子代理，所有设计都旨在使代理更安全、更高效。

然而，开发流程中一个关键的组成部分仍然经常被忽视：数据库。

每个并发代理都需要向数据库编写代码、应用模式变更并运行测试。在传统数据库设置中常见的共享环境（如单个开发或预发布数据库）会带来实际挑战。代理之间可能在模式变更上产生冲突、相互干扰，或退回到无法反映真实数据的模拟数据。这些本就是开发者的痛点，但编码代理的引入使问题更加严重。代理运行速度更快、并行操作，需要安全的环境来避免危及生产数据或暴露敏感数据。

Lakebase Postgres 架构通过数据库分支解决了这个问题。就像 Git 可以分支代码一样，Lakebase 可以在不到一秒内分支整个数据库，无论其规模大小。它采用写时复制技术，因此分支共享父分支的数据，只有在发生分歧时才会消耗额外存储空间。此外，它们可以扩展至零，意味着空闲分支不会产生计算成本。这在同时运行多个代理时非常重要。每个分支完全隔离，允许代理应用迁移、运行测试，并在完成后退役分支。

在本文中，我将通过围绕编码代理构建的 Lakebase 开发循环端到端工作流，展示这一过程的实际效果。示例仓库地址在此，包含 GitHub Actions 工作流示例，实现以下各节描述的功能。

更喜欢观看实际演示？请观看下方视频教程。

在深入之前，关于 Databricks 环境的说明。使用 Lakebase Postgres 时，常见设置是每个环境使用一个 Databricks 工作区，如开发、预发布和生产环境。大多数团队出于安全和合规等原因会使用多个工作区，但也可以使用单个工作区。同样，从种子数据库而非生产数据库进行分支也很常见，以避免暴露 PII 等敏感数据。为简化起见，本文将使用单个工作区，但相同的核心概念同样适用于多工作区设置，且实现方式同样简单。

图1：使用Lakebase分支的开发循环：每个代理和PR都会获得一个独立的临时数据库。

为并行编码代理提供安全、隔离的数据库

传统数据库的主要颠覆性变化来自于多个编码代理的并发工作。在开发新功能或修复问题时，每个代理通常需要读取数据库模式、应用更改、填充数据并运行测试。如果没有隔离，这些代理可能会相互干扰或破坏共享数据库。数据库分支为每个代理提供了一个独立的环境，使其能够独立工作而不会影响同时运行的其他代理。

避免本地代码冲突的一种实用方法是利用Git工作树。工作树为每个代理提供自己的目录和分支，因此它们之间不会有文件级冲突。Git工作树解决了并行代理的代码隔离问题。Lakebase分支解决了另一半问题：数据库隔离。通过在仓库中添加post-checkout钩子，每个新工作树会自动生成自己的数据库分支。开发完成后，代理将打开PR。可以通过仓库指令文件（如AGENTS.md或CLAUDE.md）指导代理行为。

图2：使用Git工作树、Lakebase分支和Claude代码钩子及GitHub Actions为每个代理设置的分支。

以下是使用Claude代码、工作树和Lakebase分支进行安全AI开发的示例工作流程：

• 代理运行 claude -worktree feature-123
• Git为feature-123分支创建工作树
• post-checkout钩子自动触发，创建数据库分支
• 代理现在拥有自己的代码目录和完全隔离的数据库

图3：使用Git工作树和Lakebase分支进行隔离的并行Claude会话。

当代理完成工作后，它将创建PR。这种行为在仓库指令文件中提供。PR创建后，工作树和数据库分支都可以退役。与Git的一个重要区别是Lakebase分支不会合并回主分支。由于父分支和子分支可以独立更改，协调它们的数据很快会变得不切实际。相反，模式更改会与应用程序逻辑一起在代码中进行跟踪，然后通过迁移工具（如Drizzle、Flyway、Liquibase或Alembic）提升到父分支。

在我们的示例中，我们使用Drizzle。当需要模式更改时，代理将相应的迁移添加到代码库。部署自动化在部署预览应用时会应用该迁移，并在更改合并到主分支时再次应用。

为每个拉取请求提供临时数据库

一旦打开拉取请求（PR），我们希望在任何代码进入生产环境之前，自动使用真实数据库验证和测试代码。

使用持续集成工具（在此示例中为GitHub Actions），为每个PR创建一个临时的Lakebase分支，作为生产分支的子分支。该分支成为PR的数据库环境。可以针对它运行自动化测试，部署预览应用，审阅者可以使用真实数据库验证更改。

由于该分支从生产分支派生，更改在到达生产环境之前也可以应用和测试模式迁移。

一旦PR获得批准并合并，功能代码和迁移指令将被提升，临时的Lakebase分支将被删除。

一个常见的 GitHub Actions 工作流如下：

• 针对 main 分支创建 PR
• CI 调用 Lakebase CLI 创建类似 pr-123 的分支
• 迁移工具（Drizzle、Alembic 等）在新的专用数据库分支上运行
• 部署预览应用，指向该分支的连接字符串
• 生成模式差异并作为 PR 评论发布，精确显示哪些表、列或索引发生了变化
• 审核人验证代码和数据库变更
• 当 PR 被关闭或合并时，CI 删除该分支

图 4：在 Pull-Request 中生成的模式差异评论

在仓库示例中，我们使用 Databricks Apps 部署应用，但该概念同样适用于其他托管平台，如 Vercel、Netlify、Cloudflare 等。

使用数据库分支进行错误复现、迁移和测试

除了开发任务，数据库分支还可以支持其他有用的流程。这些功能在示例仓库中尚未实现，但可以作为 Lakebase 开发流程的宝贵补充。例如，通过数据库分支，你可以从生产环境在某个时间点（通常是在错误出现之前）创建一个隔离分支，使用真实数据调查问题，在安全环境中复现错误，并在修复验证后删除该分支。

分支还可以使模式迁移更加安全。在向生产环境部署变更之前，可以自动创建数据库分支，应用迁移，运行测试，并验证应用是否仍按预期工作。一旦迁移验证通过，相同的变更可以提升到生产环境。

这些工作流之所以强大，是因为它们允许开发者使用 Unity Catalog 掩码等功能，与生产环境或衍生自生产环境的数据进行交互，而不会危及实时数据库。每个分支都是隔离且短暂的，使其成为调试、测试和验证的安全环境。

结论

这些模式共同构成了 Lakebase 开发循环：每个代理一个分支，每个 PR 一个分支，以及用于生产验证的隔离分支。

对于 Agentic SDLC，数据库分支为与代码代理协作的开发团队提供了安全且灵活的基础。尝试自己进行分支操作吧。

订阅最新文章

订阅我们的博客，获取最新文章发送到你的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"