标签: dbdeploy

描述有点复杂,但我会尽我所能.基本上我们正在使用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中完成的操作.

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

我正在使用Phing的dbdeploy任务来管理我的数据库模式.只要我的delta文件的查询中没有错误,这工作正常.

但是,如果出现错误,dbdeploy将直接运行增量文件到错误的查询,然后中止.这让我有些沮丧,因为我必须手动回滚changelog表中的条目.如果不这样做,dbdeploy将假定在后续尝试中迁移成功,因此任何重试都不会执行任何操作.

所以问题是,有没有办法让dbdeploy使用事务,还是可以建议任何其他方法在发生错误时自动进行phing回滚？

注意:我对Phing并不熟练,所以如果这涉及编写自定义任务,那么任何示例代码或带有更多信息的URL都会受到高度赞赏.谢谢