宏哥 关于数据库 开发, 测试, QA到生产环境的问题.

宏哥 发布于 2014/05/28 21:02
阅读 856
收藏 0

在开发当中, 代码版本控制以及同步都是比较容易的, 但是对于数据库, 由于版本更新, 往往涉及到数据库的大幅修改, 这种情况, 如何保证生产环境升级的过程, 数据不丢失, 以及数据关系的完整性等.....

想听听大家的意见

加载中
0
乌龟壳
乌龟壳

对比差异人工编写升级脚本,人工保证ACID

0
宏哥
宏哥

引用来自“乌龟壳”的评论

对比差异人工编写升级脚本,人工保证ACID

对新的DDL建立的数据表, 如何重新导入

还是在原来的表上做修正?

0
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

对比差异人工编写升级脚本,人工保证ACID

引用来自“宏哥”的评论

对新的DDL建立的数据表, 如何重新导入

还是在原来的表上做修正?

不懂,哈哈,菜鸟一个。
0
Inside
Inside

我是这样做的:

1、复制生产系统的数据和环境,在该环境中模拟升级过程,测试新的业务逻辑。

2、不断迭代第1点,直到新版本所有改动都被迭代过程覆盖到。

另外,所有数据库变动,都用sql脚本自动进行,当然,也是在模拟环境中反复测试过的。

我有过一次政府部门的业务系统堪称面目全非升级的经历,从代码到数据结构,都大大变化,采用以上方法,十分顺利,没有任何意外。

如果想确保万无一失,那就需要dba拿出从新结构返回旧结构的方案,并且新系统上写入的数据也要正确退化到旧结构上,只是这点很难而且实际情况一般也不会允许这种系统退化的事情出现,只能靠升级前的反复测试。

最后,你需要像我这么强大的程序员,哈哈哈

0
宏哥
宏哥

引用来自“Inside”的评论

我是这样做的:

1、复制生产系统的数据和环境,在该环境中模拟升级过程,测试新的业务逻辑。

2、不断迭代第1点,直到新版本所有改动都被迭代过程覆盖到。

另外,所有数据库变动,都用sql脚本自动进行,当然,也是在模拟环境中反复测试过的。

我有过一次政府部门的业务系统堪称面目全非升级的经历,从代码到数据结构,都大大变化,采用以上方法,十分顺利,没有任何意外。

如果想确保万无一失,那就需要dba拿出从新结构返回旧结构的方案,并且新系统上写入的数据也要正确退化到旧结构上,只是这点很难而且实际情况一般也不会允许这种系统退化的事情出现,只能靠升级前的反复测试。

最后,你需要像我这么强大的程序员,哈哈哈

所以这件事的到底还是需要很多人工的努力

其实是一个ETL的过程. 非常繁复

非常辛苦的工作. 

一般来说, 升级不会选择回退的

返回顶部
顶部