项目数据库分多个版本:
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 后一时又找不到好的解决方案.
上面的问题只是部分想到的冲突的情况,估计还会有很多类似或者其它冲突.
所以希望各位大牛们能出点主意.或者有什么比较好的处理类似情况的方案.
It’s so confusing. If you want to perform database version control, you can check out Liquibase
This will go wrong because the db/schema.rb file will prompt a conflict. At this time, you will know that you need to manually modify the database structure.