必须升级数据库模式才能使安装新版本的软件变得更加棘手.这样做最好的做法是什么？
我正在寻找一个行动项目的清单或时间表,如
> 8:30关闭应用程序
> 8:45修改模式
> 9:15安装新的应用程序
> 9:30 restart db
等等,显示如何最大限度地减少风险和停机时间.问题如：
如果出现问题,退出升级
尽量减少对现有应用的影响
>数据库运行时的“热”更新
从开发到测试到生产服务器的推广
特别感兴趣.
解决方法
我有很多经验.我的应用程序是高度迭代的,模式更改频繁发生.我大概每2到3周进行一次生产发布,每个产品从我的FogBugz清单中清除50-100个产品.过去几年我们所做的每一个版本都需要架构更改来支持新功能.
这样做的关键是在测试环境中进行多次修改,然后才能在实时服务器上实现.
我保留一个从模板复制的部署清单文件,然后对每个版本进行大量编辑,其中任何不符合规定的.
我有两个在数据库上运行的脚本,一个用于模式更改,一个用于可编程性(过程,视图等).更改脚本是手动编码的,具有procs的脚本通过Powershell脚本编写.更改脚本在关闭所有操作时运行(您必须选择一个使用最少量的用户的时间),并且手动运行命令,以防任何事情发生.我遇到的最常见的问题是添加一个由于重复的行而失败的唯一约束.
在准备集成测试周期时,我将在测试服务器上查看我的清单,就像该服务器是否生产一样.然后,除此之外,我得到一个生产数据库的实际副本(这是一个很好的时间去掉你的异地备份),并且我在一个恢复的本地版本上运行脚本(这也是很好的,因为它证明了我的最新的备份是声音).我在这里用一块石头杀死了很多鸟.
所以这是4个数据库总数：
> Dev：所有更改都必须在变更脚本中进行,从不与工作室进行.
>测试：集成测试发生在这里
>生产副本：最后一刻的部署实践
>生产
你真的真的需要在生产时做到正确.备份模式更改很难.
至于修补程序,我只会修复程序,而不是模式,除非它是一个非常孤立的变化,对于业务至关重要.
