项目数据库分多个版本:

dev 用于开发环境

lab 用于外网测试环境

release 用于外网正式生产环境

因为开发的需要会对数据库进行表结构的修改(例如: 加表,删表,添加表字段,重命名表名名,重命名表字段名) ,于时很自然的就想到 Migration 机制 .

在实际运行的过程中会遇到如下的情况:

1: dev 的数据库结构发生变化后,此时需要更新到lab测试环境中.但要求不影响现有的release版本.
于是新建一个migration 文件,需要把表table1中的字段filed1重命名为filed2.此文件的命名类似 201405060512_xxxx.rb. 执行此migration 并让其在 lab 版本的数据库中生效,到此lab的数据库结构已经更新到最新版本并可交由外网测试.

2: 这个时候release 版本发现一个重大bug,需要把表table1中的filed1的值设置成一固定值300.这个必须fix它. 于是开发人员都切到 release 版本中进行修改.最后生成一个migrate文件类似201405080512_xxxx.rb用于对release版本的数据库进行升级.但是这个时候并不需要升级lab版本的数据库.

3:最后到了一个开发周期,需要发布一个全新版本到外网测试.这个时候的流程大概会是这样的:

1) 把release版本的修改合并到lab分支上.

2) 把lab分支合并到dev分支上.

3) 本地测试dev分支 直到ok

4) dev 分支合并到 lab 分支并把lab发布到外网进行测试.

5) 执行数据库升级脚本(Migration)

看似这一切都很通畅,但是这里面就会有一个问题. release 分支的 migrate 文件 201405080512_xxxx.rb 的生成时间后于 lab 分支的 migrate 文件 201405060512_xxxx.rb 一天. 在合并分支的时候虽然没有冲突,但是在下一次执行顺序上就会出现问题,回到刚在的bug中:

release 后于lab 如果按 Migration 的机制会先执行 lab 分支建的 migration 文件即是:将table1中的filed1重新命名为filed2

然后执行release分支的 Migration 即是:将table1中的filed1的数值设置成固定的数300

问题就在当执行release分支的时候找不到table1中的filed1字段,因为被前一个migration给修改成了filed2
程序抛出一个异常.

当然以上情况可以手动人为解决冲突,并可保证其运行.但是总感觉还有比较好的方案来处理这种情况.google 后一时又找不到好的解决方案.

上面的问题只是部分想到的冲突的情况,估计还会有很多类似或者其它冲突.
所以希望各位大牛们能出点主意.或者有什么比较好的处理类似情况的方案.