数据库模式升级清单

必须升级数据库架构使得安装新版本的软件变得更加棘手.这样做的最佳做法是什么？

我正在寻找行动项目的清单或时间表,例如

8:30关闭应用程序

8:45修改架构

9:15安装新应用

9:30重启db

等,展示如何最大限度地降低风险和停机时间.诸如此类的问题

如果出现问题,退出升级

最小化对现有应用的影响

数据库运行时"热"更新

从开发到测试再到生产服务器

特别感兴趣.

我对此有很多经验.我的应用程序是高度迭代的,并且模式更改经常发生.我大约每2到3周进行一次生产发布,每个FogBugz列表中有50-100项清除.我们在过去几年中完成的每个版本都需要更改架构以支持新功能.

关键是在实际服务器上实际更改之前,在测试环境中多次练习更改.

我保留了一个部署清单文件,该文件从模板中复制,然后针对每个版本进行大量编辑,包含任何与众不同的内容.

我有两个脚本,我在数据库上运行,一个用于架构更改,一个用于可编程性(过程,视图等).更改脚本是手动编码的,带有procs的脚本是通过Powershell编写的.更改脚本在所有内容都关闭时运行(您必须为此选择惹恼最少量用户的时间),并且它是手动命令运行,以防万一有什么奇怪的事情.我遇到的最常见问题是添加由于重复行而失败的唯一约束.

在准备集成测试周期时,我会在测试服务器上查看我的清单,就像该服务器是生产一样.然后,除此之外,我得到一个生产数据库的实际副本(这是交换你的异地备份的好时机),我在恢复的本地版本上运行脚本(这也很好,因为它证明了我的最新的备份是健全的).我在这里用一块石头杀了很多鸟.

总共有4个数据库:

开发:所有更改必须在更改脚本中进行,而不是在工作室中进行.

测试:集成测试在这里进行

生产副本:最后一刻部署实践

生产

当你在生产中做到这一点时,你真的需要做对.支持架构更改很难.

至于修补程序,我将只修改程序,从不构建程序,除非它是一个非常孤立的变化,对业务至关重要.