项目数据库分多个版本:
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 后一时又找不到好的解决方案.
上面的问题只是部分想到的冲突的情况,估计还会有很多类似或者其它冲突.
所以希望各位大牛们能出点主意.或者有什么比较好的处理类似情况的方案.
看的好晕，如果是要进行数据库版本控制的话，可以去看看Liquibase
1) 把release版本的修改合并到lab分支上.
这是会出错的，因为 db/schema.rb 文件会提示冲突，这时候你就知道需要手动去修改数据库结构。