部署 项目多版本开发,更新数据库结构时的优美方案.

lb563 · 2014年01月08日 · 最后由 lb563 回复于 2014年01月12日 · 3128 次阅读

项目数据库分多个版本:

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 后一时又找不到好的解决方案。于是准备向ruby-china 求助。

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

你的问题是环境的混合使用。每套环境应该保持一致。你既然已经产生多版本,但环境上只提供 3 个,当然就出来问题。

#1 楼 @xds2000 是的现在的情况是使用了多环境。同时还想支持可在不同环境上做小修改后,等开发周期结束后把所有的分支合并到主分支。这样确实会产生这种冲突.因为开发测试在不同分支上。等开发了很多功能后,发现生产环境有个不能不 fix 的 Bug 这个时候就会有这种需求。

善用版本控制系统 善用分支 如果在用 git,善用 git flow 你会发现,你所说的烦恼原来根本不是烦恼

数据库迁移是有顺序依赖的,不能并行。

这个有点无解,因为 Migration 是有顺序依赖的。

@lb563 我给你讲一下一个流程

  1. release-> production 环境,你需要提供对应的 staging,production 环境,有 hotfix 直接在 staging 上 spin 出一个 test 环境,打 patch,测试没问题了上 staging,staging 上跑一个集成测试,没问题,直接上 production. 2.每一个 feature 都开一个 testing 环境,等开发完了,把 testing 环境同步到最新的 staging 环境,然后再应用 feature 代码,在 testing 上跑测试,不过就修。跑过后到 staging 环境

以上所有操作都可以 automation,直接考虑 jenkins+capistrano,主机这一块直接哪云主机当测试机,开 image 很快。

你这种情况必须人工合并,解决不了。开发分支已经重构了,不能自动合并。

#7 楼 @jimrokliu 好像现在也只能这样。先试试等再把需求稳定一下再想一个方案了。

#6 楼 @xds2000 多谢,可能我的需求没有描述清楚。比较还特殊.多环境,多修补,还得自动合并。这个目前只能手动解决冲突.等需求再稳定一下看有没有比较好的处理方案。

#4 楼 @hooopo 嗯,这个现在就是项目中现遇到的问题。可能会出现新版本的 migrate 需要在旧版本的 migrate 之后执行。

#3 楼 @leopku 版本控制也有在用。但还没有研究出来处理我的所需要需求方案。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号