处理代码分支之间共享的数据库模式的有效方法是什么？

Question

处理具有多个分支的项目，其中每个分支最终会合并回主分支，并且本质上是孤立的，以便开发新功能。

数据库，即 MS SQL Server，有一个共享架构，但是每个分支都会随着它的进展对架构进行更改。

我的主要问题是什么是处理从主分支到派生分支共享架构的好方法，以便对主分支所做的更改可以轻松合并到派生分支中，而无需在派生分支中进行新更改分支？

Answer 1

我已经成功地使用了以下方法，在版本控制和您的数据库中详细说明：

• 在元数据中维护版本号（我使用数据库扩展属性）
• 任何架构更改都被编码为从当前版本更新到下一个版本的脚本
• 应用程序随附了从版本 0（初始部署）一直升级到当前版本的所有脚本
• 每次更改都是通过脚本完成的。包括“系统”数据更改，如字典和查找表条目。
• 部署时，应用程序检查磁盘架构版本，然后运行所有升级步骤以将架构升级到当前所需的版本

我经常听到这样的意见：“这与将对象定义脚本置于源代码管理之下有何不同？”。差异是巨大的，因为当您部署应用程序的新版本时，您不会简单地创建一个新数据库。大多数情况下，您的应用程序必须升级现有数据库，包括现有数据。这是一个至关重要的区别，您的升级步骤需要确保升级期间现有数据的完整性和一致性。一些操作在代码中是微不足道的（在表对象定义脚本中添加一个具有默认值的不可空列，完成），但实际上在实际部署时非常痛苦（表有 15 亿行，添加列会用完如果以“简单”的方式完成日志空间）。

这如何与分支一起工作：

• 创建分支时，它会捕捉当前模式版本，比如版本 1.6
• 当团队开始在分支上工作时，它添加了一个新版本 1.7，然后开始编写从 1.6 到 1.7 的升级步骤
• 随着在分支中完成修改，升级步骤会发生变化。它总是运行从 v 1.6 升级到 1.7 的脚本，但这些脚本究竟做什么，取决于正常的代码迭代和分支中的签入
• 分支完成开发，准备反向集成（合并回基线）
  • 它从基线到分支进行了新的前向集成。如果集成没有给模式版本带来任何变化，一切都很好，分支可以按原样反向集成。1.7 版成为新的基线版本。
  • 有趣的是，同时另一个分支反向集成到 base 中，现在 base schema 版本已更改为 1.7。在这种情况下，我们的分支必须将它的部署目标架构版本提升到 1.8，并对之前从 1.6 升级到 1.7 的升级步骤进行审查，以了解它在从 1.7 升级到 1.8 的新环境中如何运行。必须解决逻辑模式冲突，脚本可能需要更改，必须进行测试。完成后，分支可以反向集成到基础中。产品的部署目标版本现在变为 1.8。
  • 当另一个在架构版本 1.6 上分叉的分支想要反向集成时，它需要将它的架构版本提升到 1.9，测试从 1.8 到 1.9 的升级脚本，然后它可以集成回基础。

请注意，这里没有涉及任何工具，没有魔法模式差异脚本，没有向导，也没有涉及右键单击生成脚本。这是一个 100% 开发人员驱动的过程，基于源代码（脚本）。许多人发现整个过程很复杂，但它确实有效。事实上，作为 SQL Server 用户，您已经在日常使用 SQL Server 中利用了这个过程的结果：SQL Server 本身使用了一个非常相似的数据库升级过程，而且正如您可能期望的那样，产品开发过程广泛使用分支和你提到的问题是一个非常现实的问题，必须解决。

顺便说一句，分支/集成实际发生的方式在源代码控制产品之间有所不同，我使用的是 perforce集成操作模式中熟悉的术语。

Answer 2

如果您通过生成脚本并将这些脚本置于源代码控制下来处理架构更改，那么您应该能够像对待任何其他代码合并一样对待这些更改。您可以选择自动合并或采取更多手动干预。