mysql - 项目多版本开发,更新数据库结构时的优美方案?
迷茫
迷茫 2017-04-17 11:17:59
0
2
648

项目数据库分多个版本:

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 后一时又找不到好的解决方案.

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

迷茫
迷茫

业精于勤,荒于嬉;行成于思,毁于随。

reply all(2)
巴扎黑

It’s so confusing. If you want to perform database version control, you can check out Liquibase

阿神

1) Merge the changes in the release version into the lab branch.

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.

Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template