数据库版本控制 - 分支交换如何工作？

Question

这是一个针对你们开发的开发团队的问题，你们所有人都有独立的数据库。您使用源代码控制和其他工具版本化数据库，这些工具会自动将开发数据库更新到最新版本的数据库（模式，数据，SP，函数等）。

好极了！可是等等！如果您正在开发软件的4.0版本，但是现在您需要将分支机构切换到3.2分支来修复错误？架构可以（现在几乎可以肯定）与现在非常不同...

我想如果您经过额外的努力来编写回滚脚本以及您的更改脚本，这可能会起作用。但是，这似乎很多工作 - 它真的值得吗？

Answer 1

更容易的是创建一个新的3.2分支数据库并在3.2分支代码上工作。我要求每个开发人员只有一个数据库可以工作，这似乎并不合理。

Answer 2

我正在做一个假设，并假设您将数据库版本化为二进制文件？如果您的所有数据库资产都是建设性代码的形式（例如SQL脚本和/或文本数据转储），那么解决方案将很简单，就像Mark建议的那样：将这些资产存储为开发分支的一部分。要在版本3.2上工作，请切换分支，重新运行创建脚本和3.2，数据库。合并将与常规代码一样简单（或根据您选择的版本控制系统一样痛苦）。

这里有一些建议，在此模式下工作：

• 如果创建从文本数据库实例太慢，做一个共享磁盘卷上的高速缓存，被所有的架构/数据的内容键控文件（或其MD5总和）。
• 编写预提交钩子以确保开发者实例中的模式和数据转储与版本控制下的模式和数据转储相同。这可以防止人们使用交互式工具更改开发数据库，​​然后忘记提交它们。
• 您提到更改脚本;将其视为一项责任。尽管您的部署方案可能需要它们（例如对于想要就地升级的客户），但它们会复制数据库版本历史记录中的信息，而墨菲的法律复制迟早会意味着不同步。尝试使用“diff”从版本化数据库资产中自动生成更改脚本;或者如果无法实现，请将一些严重的单元测试用于数据库升级。