Enabling Evolutionary Database Development: Database branching with Lakebase, the conclusion

实现演进式数据库开发：使用 Lakebase 进行数据库分支，结论 | Databricks 博客

跳至主要内容

合作伙伴

2026年6月12日

实现演进式数据库开发：使用 Lakebase 进行数据库分支，结论

第3部分：Jen 的团队在规模上的应用

作者：Pramod Sadalage 和 Kevin Hartman

在《演进式数据库设计》中描述并在《重构数据库：演进式数据库设计》中实现的方法论已经清晰地存在了二十年。七个实践、70多个命名重构的目录、迁移机制——所有内容都被记录、同行评审并教授。

该方法论在2010年通过《持续交付》（第12章：管理数据）进入 CI/CD。迁移成为部署管道中的一等公民。数据库变更作为代码的实践达到了更广泛的 CI/CD 运动。CD 没有解决的是每个管道的隔离问题：管道可以运行迁移，但它们仍然需要一个目标数据库，而该目标是共享的。实践 #4 – 每个人都拥有自己的数据库实例 – 在大多数团队中仍然是一个理想，因为真正为每个开发人员提供生产环境形状的数据库需要时间、金钱和 DBA 周期。为了弥补这一差距而出现的补偿层（模拟对象、共享的预发布环境、内存数据库替代品、DBA 任务队列）默认成为了基础方法论，而不是设计的结果。

在2026年，基于写时复制的数据库分支在 Databricks Lakebase 中实现。一个以千兆字节规模的生产数据库为基准的分支，现在可以在一秒钟内创建，且初始存储为零，这是一个 O(1) 操作。使实践 #4 保持理想的约束已被解除。

本系列描述了当约束解除时会发生的变化：不是方法论——它依然有效——而是首次出现的实践、在团队规模上自动实现的治理、DBA 的角色演变，以及代理与人类同事共享的新底层结构。

认识 Jen

Jen 是《演进式数据库设计》中的开发人员角色。在那篇文章中，她作为常规用户故事实现了一个数据库重构——将 inventory_code 字段拆分为 location_code、batch_number 和 serial_number，说明了 DBA 和开发人员可以协作、模式可以以小步骤演进，迁移可以安全地将变更向前推进。

本系列在二十年后继续讲述 Jen 的故事。她遵循的方法论与2003年时相同。不同的是她工作流程下的底层结构：基于写时复制的数据库分支，使得她一直在阅读的实践在生产规模上变得实际可行。在本系列的三个部分中，Jen 在三个不同的范围内是同一个 Jen——她的日常（第1部分）、她的新操作手册（第2部分）和她的团队（第3部分）。

第3部分：Jen 的团队在规模上的应用

第1部分带领 Jen 完成了一个功能。第2部分列出了她在2026年遵循的十一项实践操作手册。第3部分将同样的操作手册扩展到一个由五十名开发人员组成的团队，代理与人类一起创建分支，并提出问题：在这样的规模下，什么会成为结构性的？

有三件事变得至关重要。

首先，层级拓扑结构，代表推广路径中每个环境的长期分支。在一名开发人员时，你有一个功能分支和生产环境。在五十名开发人员时，你有一个结构化的层次体系，稳定的通道和临时通道叠加在上面。

其次，权限模型，即定义谁可以对哪个分支执行什么操作的框架。在只有一个开发人员时，可以依靠惯例。但当有五十个开发人员，且有代理参与时，该框架必须一次性设计好，并自动执行。

第三，DBA（数据库管理员）的角色。在只有一个开发人员时，DBA 是 Jen 在 PR（拉取请求）中的设计合作伙伴。但在有五十个开发人员时，DBA 是平台工程师，负责设计 Jen 和她的团队所运行的框架。

本文将依次介绍以上内容，然后转向代理。具有相同能力的代理是实践 #11。代理就像初级开发人员：他们生成可以运行的代码、通过的测试、可应用的迁移，但如果没有指导，他们也会生成难以维护的系统。测试是团队保持他们诚实的方式。接下来的 TDD（测试驱动开发）手册就是团队如何让测试优先的方法。

将层级视为长期分支，而非独立实例

在分支之前的时代，环境是一个实例：一个专门用于预发布环境的 Postgres 部署，另一个用于用户验收测试，另一个用于性能测试，每个环境都分别进行配置、补丁、脱敏和同步。补偿层 Part 2 所提到的内容也存在于这里。环境之间的差异是结构性的。

在团队规模扩大后，层级模型会演变为从同一个 Lakebase 父分支分出的长期分支。

一个分支有两种可能：一种是层级（长期存在，是晋升层次结构中的父级），另一种是功能（临时存在，从层级分支出并最终被清理）。层级有一个父级。父级链就是晋升层次结构。

图 1：主分支及其分支的简单布局

在图 1 中，我们看到一个简单的层级结构，主分支是生产环境，功能分支在需要时创建。这种设置通常适用于早期原型设计或小型团队的早期阶段工作。对于开发人员较多或需要大量环境的成熟团队，通常会采用如下所示的设置。

图 2：主分支包含最新模式和参考数据及其各种分支的布局

在一些企业中，需要设置一个发布候选版本（RC），这个发布候选版本在开发一段时间后，经过成功测试后会被提升到生产环境。图 3 展示了一种允许发布候选版本进行开发并最终提升到生产环境的布局，之后可以清理发布候选分支。

图 3：使用发布候选版本进行开发和测试的布局

分支的名称是任意的，重要的是如何设置父级关系的惯例。可以实施一个策略，防止与父级链层次结构相矛盾的转换，从而避免直接的功能合并。

策略定义为流水线管理带来了许多好处：

• 一个流水线定义，分支感知。Part 2 中引入的 pr.yml 会针对每个 PR 运行；merge.yml 会针对每个晋升操作运行。相同的流程涵盖了功能分支、层级分支以及它们之间的转换。

• 晋升是合并，而非重新部署。从预发布环境到生产环境的发布是一个 Git 合并操作，其下游效果是 Lakebase 分支的晋升。迁移在每个层级上仅执行一次，并且在前一个层级上首先进行验证，就像在早期阶段验证代码一样。

• “测试环境”与生产环境之间没有漂移。每一层都源自同一个父级。任何两个层级之间的模式差异是一个真实且可计算的事物：模式是一条带有分歧标记的页面链，而不是两个数据库软件的安装。这使团队无需管理需要打补丁和升级的数据库服务器舰队。

• 通过重新指向进行回滚。一次糟糕的发布可以通过将应用程序指向发布前的快照来恢复。快照本身是另一个分支，使团队能够从有缺陷的部署中恢复。

• 通过 project_id、branch_id、endpoint_id 进行成本归因。Unity Catalog 自动捕获元数据。对审计和计费表进行一次 SQL 查询，即可回答哪个分支是由谁创建的、分支创建的时间以及维持该分支运行的成本。

数据库实例的数量也大幅减少。一个包含六个环境实例的世界（生产、预发布、UAT、QA、性能测试、演示）被缩减为一个 Lakebase 父级，其下是通过父级链接的长期运行分支的层级结构。用于部署、监控和打补丁的实例现在是一个逻辑分支，其数据形状与生产环境相同，受与生产环境相同的策略管理，并在需要时可在一秒内重置为生产状态。

不同的惯例允许你创建许多不同类型的父级分支，一个常见的惯例是维护一个包含数据库模式和任何参考数据的分支，以便任何人都可以从中分支并用测试数据填充，或运行自动生成真实数据的自动化测试，从而避免与预发布环境或其他分支发生冲突。

现在该做什么：权限模型

实践 #10 在第二部分的策略中，我们讨论了“一次性设计治理，按分支继承”的概念。现在我们来看看它是如何实现的。

设计工作不是运行时的限制。它是一种结构性设计，然后常见的任务可以据此执行。

在团队扩展或添加代理之前，现在需要做出的决策包括：

• 从每一层创建分支。从生产环境分支与从预发布环境或功能分支相比，权限是不同的。默认情况下，功能分支应从入口（底部）层级分支，而不是从生产环境分支。生产环境的分支仅限于热修复和恢复流程。

• 层级之间的发布。从“功能到预发布”的发布是一个代码审查的问题。从“预发布到生产”的发布是一个发布协调的问题。这两个是分开的关卡，由不同的审查人员进行审核，使业务和开发团队保持独立。

• 读取与写入。对分支上生产环境形状数据的读取权限与对该分支的写入权限不同。许多工程角色只需要读取权限，很少需要写入权限。

• Unity Catalog 策略。如遮蔽、行过滤和列级权限等 Unity Catalog 策略在生产环境中保持有效。这些策略默认继承到所有后代分支；层级特定的例外（例如用于负载测试的带有合成 PII 的 QA 层级）只需声明一次。

• 审计记录捕获。每个分支的创建、每次发布、每次迁移应用、每次访问模式，都在一个可查询的地方进行记录。

在团队规模上使这一机制生效的核心原则是：角色声明，策略执行。平台工程师声明层级结构、权限模型、晋升路径以及 Unity Catalog 的策略姿态。策略会拒绝与声明内容相矛盾的转换。没有一个地方可以让人类或代理通过以不同形式重试操作来绕过已声明的边界。

这是今天必须完成的工作，因为在团队达到五十名开发人员之前，代理会比任何人类都能更快地创建分支。框架是通过共享的惯例和保护机制将团队凝聚在一起的。所有其他内容都在其内部运作。

新角色：从 DBA 到平台工程师

二十年前，《2003 年进化数据库设计》论文的结尾呼应了以下观点：

“使用我们在这里描述的技术听起来可能需要大量工作，但实际上并不需要大量人员。在许多项目中，我们有三十多个开发人员，团队规模（包括 QA、分析师和管理层）接近一百人。在任何一天，我们都会有大约一百个不同模式的副本在人们的电脑上。然而，所有这些活动只需要一名全职的 DBA，再加上几名了解流程和工作流的开发人员。”

这一论点在 2026 年得到了五个方面的加强。

1. 比例保持不变，但每个 DBA 的工作量更大。每 100 人配备一名全职 DBA，同时仍然有超过一百个分支在运行，每个分支的创建成本更低，因为分支创建现在只需一秒钟的元数据操作。比例不是关键问题。关键在于 DBA 如何利用这些时间。

1. 工作内容向上移动。2003 年用于基础设施配置、模式配置、访问控制和偶尔的人工干预的小时数，现在转移到分支策略设计、数据屏蔽策略、晋升工作流和审计跟踪的可观测性上。具体的成果包括：在每个 PR 上发布模式差异的机器人、每天夜间重置开发分支的计划任务、跟踪分支生命周期和 TTL 合规性的可观测性仪表板、基于模式验证的 CI 定义以控制合并。这是平台设计工作；比以前的高阶工作多得多。

1. 代理进入方程。2003 年的论文没有涉及代理编写代码的问题。Neon 每天报告有超过 50 万个分支，其中超过 80% 是由代理创建的。一名 DBA 无法处理如此庞大的工作量。该角色向平台架构师的演进是唯一能适应代理规模的角色。

1. 数字变得具体。在旧模式下，一个六人团队通常每冲刺周期会产生 30 多个操作工单（包括配置、模式审查、数据刷新和访问授权）。在分支原生模式下：每冲刺周期不到 5 个高价值策略审查。DBA 的工作时间从每周 20 多小时减少到不到 5 小时，MTTR（平均故障恢复时间）从 4 小时以上减少到不到 30 分钟。这种工作量的减少可以帮助 DBA 与开发人员配对，为正在开发的功能找到最佳解决方案。

1. 审计跟踪变成战略仪表板。过去需要跨三个服务和三种查询语言进行交叉引用，现在只需一个针对平台系统表的 SQL 查询即可完成。所有分支、所有操作、所有成本、所有治理事件都在一个地方。DBA 不是手动构建这个视图，而是平台本身。

在《重构数据库》（2006）一书的前言中，Martin Fowler 希望这本书代表了“仅仅是一个开始”，朝着能够像 IDE 自动化代码重构那样自动化数据库重构的工具前进。分支就是下一步。Fowler 在 2006 年所期望的，即以代码的速度进行有纪律的数据库变更，现在平台已经提供了。DBA 设计这种纪律，平台则加以实施。

新的角色名称各不相同（平台工程师、数据库平台负责人、仍称为 DBA 的人）。实质是相同的：设计其他人所运作框架的人。

具有相同能力的代理

在第二部分中我们描述了实践 #11，即编码代理——具有相同分支能力的代理。现在我们来讨论。

代理可以访问分支，但不能访问生产环境。适用于 Jen 的相同工作流程规则也适用于代理。在分支上运行的测试是针对真实数据库，而不是代理可以修改或删除的模拟数据。无论迁移脚本的作者是谁，所有 PR 上都会出现模式差异。保护 Jen 的政策同样保护代理。

但仅靠这些政策是不够的。如果代理没有明确的指导，他们就像初级开发人员一样。

如果给一个初级开发人员一个功能需求票，并没有进一步的指导，他们可能会编写出能编译的代码、通过的测试和一个能干净应用的迁移脚本。代码也可能复制了代码库中其他地方的逻辑，导致重复。迁移可能添加了一个名称正确但类型错误的列。测试可能通过，因为它只测试了理想路径。这些失败不会在绿色的 CI 运行中显示出来；六周后，当其他人需要扩展这项工作时，这些问题才会显现出来。

代理会做同样的事情，但速度更快，数量更大。

如果没有明确的指导，代理可能会：

• 重新发明代码库中已经存在的模式。

• 编写一个看起来正确但跳过了命名重构转换机制的模式变更（例如，删除列之前没有先移动数据，或者添加一个 NOT NULL 列但没有更新现有行）。

• 编写测试，这些测试通过的是他们想象的数据结构，而不是生产环境中实际存在的数据结构。

• 编写迁移脚本，这些脚本虽然可以应用，但在回滚时会产生不一致的状态。

• 在抽象之上再添加抽象，以满足一个微小的变更。

基质使绿色条变得诚实（没有模拟；分支上的真实数据库）。但它并没有使代码易于维护。

团队通过以下四个强化措施使代码易于维护：

• 保护机制：权限模型。代理不能从生产环境创建分支，不能在层级之间进行提升，不能对不属于自己的层级应用迁移。基质会拒绝这些操作。

• 模式：命名重构。2006 年 databaserefactoring.com 上的目录列出了 70 多种重构，每种都有明确的转换机制。被引导去“应用拆分列重构”的代理，会生成与被引导去“拆分此列”的代理不同的迁移。

• 工作流程：源代码管理（SCM）状态机。代理遵循一系列状态，并在它们之间有阻塞的门。基质会拒绝不满足声明合同的转换。

• 审查：PR 循环中的人类。每个 PR 上都能看到模式差异，DBA 在审查路径上。第二部分中重新定义的实践 #1 使这一过程异步；在团队规模上，当代理参与其中时，这种异步审查是捕捉测试未能发现的遗漏的关键。

SCM 工作流程是核心支撑部分。在 Lakebase App Dev Kit 中，源代码控制管理不仅涵盖代码分支，还涵盖成对分支（代码分支与 Lakebase 分支作为一个单元进行管理，如第 1 部分所介绍），这种成对分支作为 Lakebase App Dev Kit 公共基底中的一个特性，强制实施了诸如与层级矛盾的合并、与分支一同迁移、CI 门限以及将迁移应用于父层级的合并等通用限制。Dev Kit 将这种 SCM 工作流程作为可执行的状态机进行交付。

图 4：SCM 工作流程中的各种状态。

图 4 上方描述了开发过程中五个状态：scaffold-complete（结构搭建完成）、feature-claimed（功能被声明）、pr-ready（PR 准备就绪）、ci-green（CI 通过）、merged（已合并）。不同状态之间的每次转换均由一个 CLI 命令驱动（lakebase-scm-claim-feature-branch、lakebase-scm-prepare-pr、lakebase-scm-wait-ci、lakebase-scm-merge）。每个 CLI 命令在执行操作前都会验证前置条件，执行状态转换，并将新状态写入 .lakebase/workflow-state.json（一个经过模式验证的门限表面）。如果某个门限失败，状态机会恢复到之前的状态。这些门限是强制性的，而非建议性的。

代理程序调用这些 CLI，它们不能发明并行路径。当前置条件失败时，基底会拒绝推进状态机：错误层级的父分支会被拒绝；在 CI 未通过前尝试合并会被拒绝；状态文件不一致会阻止下一步的门限。交接合同由 Scrum Master 角色拥有；基底强制执行这些合同。结构决策（层级结构、功能的源层级、提升路径）由架构师或 Scrum Master 做出，记录下来，并由基底遵守。基底从不发明层级或父级；它遵守已声明的内容，并拒绝与之矛盾的转换。

这就是打破团队目前使用代理程序方式的框架。传统的集成方式将代理程序视为聊天窗口中的高级工程师：转储上下文，请求输出，迭代。这在单人开发规模下有效，但在团队规模下会失效，因为代理程序的“上下文”无法被审查、治理或重放。相反，应将代理程序视为初级开发人员：在可执行的状态机中赋予其狭窄且有文档说明的任务，根据模式验证其输出，推进门限，重复操作。基底强制执行；工作流状态文件就是 API。

团队规模实践的 Playbook 条目

第 2 部分介绍了 2026 年新兴实践中的第 10 和第 11 项实践。

实践 #10：一次设计治理，按分支继承

规则。权限模型、Unity Catalog 策略用于管理访问控制和审计跟踪，仅在主干上设计一次，并由每个子分支自动继承。

为什么现在这种习惯是持久的？在团队规模下，治理必须是 DBA 或平台工程师的职责，而不是开发人员需要记住的纪律。分支的创建和销毁只需几秒钟；按分支手动配置治理会消耗分支带来的节省时间。

机制：

• 声明层级结构：哪些长期分支存在，它们的父链接是什么，每个层级的治理姿态是什么。

• 声明权限边界：谁可以基于每个层级创建分支，谁可以在层级之间进行提升，谁可以读取与写入。

• 声明 Unity Catalog 的策略继承：遮蔽、行过滤，以及哪些列级权限默认从父级继承；特定层级的例外情况只需声明一次。Unity Catalog 所有策略类型的自动传播功能即将完成；设计目标状态的框架。

• 声明审计追踪的捕获：每个分支的创建、每次晋升、每次迁移应用、每次访问模式都会自动记录在可查询的系统表中。

• 数据库管理员或平台工程师通过策略进行强制执行。任何与已声明模型相矛盾的转换都会被拒绝。

反模式。在运行时按分支配置治理。声明一次的目的是，即使分支创建的速度快于人类审查的速度，框架依然有效。手动按分支进行配置会重新创建刚刚消除的瓶颈分支。

Jen 的团队扩展之处。Jen 的平台工程师或数据库管理员在项目创建时声明了层级结构。Jen、她的队友或团队代理创建的每个分支都会继承已声明的遮蔽、权限和审计配置。当团队添加一个新层级时，框架会记录新的父级链接；正在进行的功能保留其原始父级（无追溯性重新父级）；新功能从新的层级条目分支出来。

实践 #11：以代理作为实践者，具备相同的分支能力

规则。代理在 SCM 工作流的可执行状态机中运行：五个状态，状态之间有阻塞门；状态文件经过模式验证。Jen 和代理受相同的流程规则约束；无论谁在操作，通用的底层结构都会强制执行这些规则。

为什么现在这种习惯是可持续的？分支创建是元数据操作，因此代理驱动的高吞吐量是可行的。为代理开发的底层结构可以拒绝与声明的层级结构或记录的门状态相矛盾的转换。没有聊天窗口的上下文可以回退；只有磁盘上的工件（workflow-state.json）在门转换之间跨越边界。

• SCM 状态机有五个状态：scaffold-complete（结构完成）、feature-claimed（功能声明）、pr-ready（PR 准备就绪）、ci-green（CI 绿色）、merged（已合并）。每个转换由 CLI 驱动；每个 CLI 在执行操作前验证前提条件。

• 门的表面是 .lakebase/workflow-state.json，它会与 scm-workflow-state.schema.json 进行验证。每次转换都会写入新的状态和下一个门所需的不变量。

• 结构性决策（层级结构、每个功能的源层级、晋升路径、交接合同）属于角色（架构师或 Scrum 主管），会被记录，并由底层结构强制执行。

• 代理调用 CLI。底层结构强制执行；代理无法绕过。门失败后，状态机可以恢复到之前的状态；代理不会“以不同形式重试”。

• 在 pr-ready 到 ci-green 阶段运行的 CI 门会在分支上执行真正的 Postgres，并在 PR 上发布模式差异。真正的数据库状态是代理工作的衡量标准。

反模式。将代理视为聊天窗口中的高级工程师，使用“转储上下文并请求输出”在单个开发人员的规模上可行，但在团队规模上会失效，因为“上下文”无法被审查、治理或重放。请改用工件作为 API 的模型：代理读取 workflow-state.json 和其阶段的文档输入；他们写入文档输出；验证器进行检查；只有当合同成立时，下一个门才会触发。

Jen 的团队所扩展的范围。Jen 团队的每个代理人都在同一个五状态机中运行，这与 Jen 和她的队友一样。Scrum Master 角色负责交接合同；底层框架会拒绝不满足这些合同的状态转换。一个代理不能发布从错误层级分叉出来的功能；一个代理在 CI 不通过之前不能合并；一个代理不能绕过 schema-diff 工件。无论谁或什么触发了这个动作，框架都会保持有效。

TDD 作为一层可选的叠加层

第 11 项实践将 SCM 工作流程确立为基准：每个套件使用者都遵循它，无论是代理还是人类。TDD 是一个额外的考虑，它叠加在基准之上，适用于希望采用以测试为先的纪律的团队。它是可选的；无论路径如何，SCM 的关卡都是强制性的。

为什么测试在 TDD 之前就很重要：当代理编写代码时，测试是唯一能扩展的强制措施。Kent Beck 在 2026 年的《务实工程师》采访中公开提到了这种失败模式：他难以阻止 AI 代理删除测试以使它们通过。当循环中没有任何东西迫使代理面对系统的真实形状时，绿色条很容易满足。模拟测试使这变得微不足道。内存替代品也是如此。

分支在数据层上让绿色条变得诚实。代理测试的是真实数据库在真实分支上的表现；模式约束会拒绝不匹配的行插入，外键会拒绝孤儿记录，真实数据结构会暴露模拟测试中会静默吸收的假设，代理无法删除表。这些保护措施使伪造合规的成本增加。

但底层框架是必要的，而不是充分的。测试必须来自某个地方。如果代理编写它们，代理也可以删除它们。这就是 TDD 所填补的空白。

TDD 工作流程叠加在 SCM 工作流程之上。它在 SCM 状态 feature-claimed 和 pr-ready 之间触发；它调用 SCM 进行分支操作（循环实验分支使用 SCM 底层原语）；它不会调用 SCM。依赖关系是单向的。不想使用 TDD 层的团队仍可以通过在功能分支上直接编辑来发布功能，并满足所有 SCM 关卡。

Lakebase App Dev Kit 将 TDD 工作流程作为第二个状态机提供，每个角色都有自己的代理和关卡验证器：

• Spec-author 将请求者叙述转化为结构化的功能工件，并进行模式验证。

• Architect-reviewer 将功能的非功能性需求和架构原则映射到架构决策，输出为 architecture.json 加上文本。

• Test-strategist 生成测试列表和每个验收标准的场景，输出为 test-list.json 加上渲染的 Markdown。每个 NFR 至少有一个验收标准（AC）；每个 AC 都有一个场景。

• Scrum-master 协调构建周期。每个周期都会分叉一个实验分支（使用 SCM 底层框架），运行一个驱动代理以实现下一个 AC，运行一个导航代理以审查并验证结果。

• Driver 和 navigator 是内环测试编写者和代码编写者，配对进行 RED-GREEN-REFACTOR。

每个角色都有明确的输入和输出，并且这些输入和输出会根据一个模式进行验证。每个代理只能接收到其文档中定义的输入；在下一个角色运行之前，输出会先被验证。该工件是角色之间的 API；模式是类型检查。缺少的工件会被视为一个失败的关卡。格式错误的工件则被视为缺失的工件。TDD 层借鉴了 Practice #11 为 SCM 建立的相同工件作为 API 的模型。

TDD 层的完整操作手册位于 Companion: Lakebase App Dev Kit（开源，附有人类实践者的配套电子书）。SCM 和 TDD 的状态机、每个角色的代理合同、工件一致性检查以及关卡验证器都以 CLI 的形式提供，任何编排器（工具包、IDE 插件、CI 任务、人类 shell 会话）都可以调用这些 CLI。

简而言之：SCM 是基准（Practice #11）。TDD 是一层叠加在其上的内容。分支使测试变得诚实；TDD 使测试优先；工具包使这两种工作流程都可以执行。

Jen 的团队展示了什么

第一部分带领 Jen 完成了一个功能：她将一个代码分支与 Lakebase 分支配对，几秒钟内就运行了一个真实的迁移，针对生产环境的数据进行处理，无需使用模拟，测试时直接打开 PR，将模式差异内联发布以供审查，并在迁移应用后合并，同时清理了临时分支。数据库变更成为开发过程中的常规部分。

第二部分命名了操作手册：2003 年的七项实践，由于限制，其中五项直到 2026 年才成为实际可行的实践，当分支功能落地后，这七项实践被重新定义，再加上两项新技术为个人开发者提供的新实践。日常工作中有九项实践，团队规模下还有两项正在出现的实践。

第三部分将操作手册扩展到团队层面。定义了层级拓扑结构，描述了长期分支如何驻留在一个 Lakebase 父分支中，权限模型如何成为平台工程师的设计工件，由底层（Practice #10）声明一次并强制执行。DBA 的角色完成了其向平台架构师的演变，对 2003 年的人员配置论点进行了五次强化。代理在相同的能力上进入工作流程，位于 SCM 工作流程的可执行状态机中，无论谁或什么在执行，底层都会强制执行关卡（Practice #11）。TDD 是一个可选的层，叠加在顶部：对希望采用它的团队，提供以测试优先的纪律、专门的角色、关卡和工件合同。

Companion: Plugin Walkthrough 覆盖了 Lakebase SCM Extension 在 VS Code 和 Cursor 中的端到端使用。

Companion: Lakebase App Dev Kit（附有人类实践者的配套电子书）涵盖了上述的 TDD 工作流程：SCM 和 TDD 的状态机、每个角色的代理、关卡验证器以及使代理可以安全地加入团队的工件合同。

这一方法论在二十年来一直清晰明确。技术能力在 2026 年实现。对于人类和代理实践者，操作手册现在已投入运行。Jen 的团队有 50 名开发人员和一支代理团队；工作流程是相同的。

结论：现在可以对数据库进行分支，这为开发团队提供了极大的灵活性，可以配置数据库、使用真实模式构建测试、针对每个 PR 创建运行 CI，并允许代理以这种方式工作，同时 Unity Catalog 的治理框架强制执行策略。

订阅以获取最新文章

订阅我们的博客，将最新文章直接发送到您的邮箱。

注册

查看所有博客

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

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