如何处理来自不同Git功能分支的多个db alter脚本？

Question

描述有点复杂,但我会尽我所能.基本上我们正在使用Git工作流程,这意味着我们有以下分支:

• 生产,这是现场分支.一切都是生产在实时网络环境中运行.
• 集成,其中集成了所有新功能.该分支每周合并到生产中.
• 一个或多个功能分支,开发人员或开发团队在其中开发新功能.完成此操作后,开发人员将其功能分支合并到集成.

所以,这里没什么复杂的.但是,由于我们的应用程序是针对MySQL数据库运行的Web应用程序,因此新功能通常需要更改数据库方案.为了自动执行此操作,我们使用dbdeploy,它允许我们在给定数字的情况下创建alter脚本.例如00001.sql,00002.sql等.在合并到集成分支时,dbdeploy将检查哪个更改脚本的编号高于该特定数据库上最新执行的脚本,并将执行这些脚本.

现在假设以下内容. - 集成已将脚本更改为00200.sql.所有这些都在集成数据库上执行. - 开发人员John有一个功能分支featureX,它是在集成仍然有00199.sql作为最高的alter脚本时创建的.

由于一些必需的数据库架构更改,John创建了00200.sql.

现在,在某些时候,John将他的修改合并回集成分支.John将发生合并冲突,并且会看到他的00200.sql已经存在于集成中.这意味着他需要打开冲突的文件,提取他的内容,重置文件恢复到"我的"(原来的状态,如集成),并把自己的内容在一个新的文件.

现在,由于我们与十位开发人员合作,我们每天都会遇到这种情况.虽然我们确实理解了背后的原因,但它有时非常麻烦.John重命名他的脚本,执行合并提交到集成,将更改推送到上游只是为了看到其他人已经创建了00201.sql,要求John再次执行该过程.

当然必须有更多的团队使用Git工作流并使用数据库变更管理工具来自动化数据库模式更改？

所以,简而言之,我的问题是:

• 在处理同一数据库的不同实例上的不同功能分支时,如何自动执行数据库模式更改？
• 如何一直防止合并冲突,同时仍然可以选择在执行的alter脚本中有一个固定的顺序？例如,00199.sql必须在00200.sql之前执行,因为00200.sql可能取决于在00199.sql中完成的操作.

任何其他提示都是最受欢迎的.

Answer 1

我过去使用过两种不同的方法来解决你的问题。

第一种是使用可以处理架构更新的ORM 。

另一种方法是创建一个脚本，以增量方式构建数据库架构。这样，如果开发人员需要在表中添加一行，他应该在创建表后添加适当的sql语句。同样，如果他需要一个新表，他应该为此添加 sql 语句。那么合并就变成了确保事情按正确顺序发生的问题。这基本上就是 ORM 中数据库更新过程的作用。这样的脚本需要进行非常防御性的编码，并且每个语句都应该检查其附加条件是否存在。