像代码一样分支数据库：Glaspoort生产环境中的Lakebase CI/CD模式
内容提要
Glaspoort利用Databricks Lakebase实现数据库变更与代码同等的严谨性：每个环境从生产分支，为每个PR创建临时数据库，并将迁移视为唯一事实来源。此方法避免环境漂移，简化刷新流程，提升迭代速度十倍，确保测试基于真实数据，同时保持架构灵活可靠。
延伸解读
分支拓扑的关键：从生产直接分支
文章指出，常见的环境层级（生产→开发→验收→功能）会导致环境漂移，且刷新成本高。Glaspoort的解决方案是让所有长期环境（开发、验收）都直接从生产分支，而非彼此嵌套。这样刷新任一环境时无需删除子分支，简化了操作，使团队更愿意定期刷新，保持环境与生产一致。
迁移作为唯一事实来源
Glaspoort不通过合并数据库分支来提升变更，而是在每个提升阶段重放迁移脚本。这意味着数据库的可复制性依赖于有序的迁移集合，而非任何长期存在的数据库实例。即使刷新遗漏了某些变更，后续的迁移重放也会补上，从而保证环境可随时重建，降低了环境管理的风险。
合并策略的权衡：堆叠 vs 独立提升
文章对比了两种PR合并模型：堆叠（Option 1）优化开发速度，适合小团队处理重叠变更；独立提升（Option 2）提供独立性和清晰的热修复路径。Glaspoort选择了堆叠，因为团队小且变更重叠，但保留了危机管道以应对紧急情况。每个提升门都会在全新生产分支上重放迁移，确保堆叠变更作为整体验证。
安全与权限的实践细节
数据库认证使用短期令牌（60分钟TTL），通过异步密码函数自动轮换，避免长期密钥。对象级授权目前手动在生产环境应用，子分支通过从生产重新分支自动继承，减少了重复工作。应用使用单一数据库用户，用户级授权在应用层实现，简化了配置，但将访问控制从数据库移到了应用层。
Q&A
Glaspoort如何实现数据库变更与代码变更同等严谨？
Glaspoort采用Databricks Lakebase的数据库分支功能，将每个环境从生产分支，为每个PR创建临时数据库，并将迁移视为唯一事实来源。这样确保数据库变更与代码变更具有同等的严谨性。
Lakebase分支是什么？它如何工作？
Lakebase分支是Postgres的写时复制分支，创建时不会复制数据，而是快速分叉状态，只有写入时才与父分支分离。每个分支完全隔离，有自己的端点和数据，可以秒级创建和丢弃。
为什么Glaspoort选择从生产分支而不是从开发环境分支？
从生产分支可以避免环境漂移，因为开发、验收等长期环境直接从生产分支，刷新时无需删除子分支，简化了刷新流程，确保测试基于真实数据。
Glaspoort如何处理数据库迁移？
Glaspoort将迁移视为唯一事实来源，通过重新运行迁移来提升变更，而不是合并数据库。每次提升都会在目标分支上重放迁移，确保模式正确。
Glaspoort的PR测试环境是如何创建的？
每个PR都会获得一个临时的数据库分支，该分支从生产分支创建，因此包含生产数据。测试在临时分支上进行，完成后可快速丢弃。
Glaspoort如何管理数据库凭据和访问权限？
应用使用短期数据库凭据（60分钟TTL），通过Azure Key Vault中的静态密码生成，客户端异步刷新。数据库访问使用单一应用用户，用户级授权在应用层实现。对象级授权目前手动应用，但子分支从生产继承。
Glaspoort在PR合并策略上选择了哪种模型？为什么？
Glaspoort选择了Option 1（堆叠式合并），即PR可以基于其他未合并的PR分支。因为团队小且变更重叠，等待验收通过会降低速度，而堆叠风险偶尔出现且可通过预检控制。
Glaspoort的CI/CD流程如何确保数据库变更安全？
每次提升都会在目标分支上重放迁移，并在暂存槽上运行完整测试套件，确保变更在到达生产前经过验证。紧急修复也走相同流程，只是更快。
