数据库模式升级清单

Question

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

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

• 8:30关闭应用
• 8:45修改架构
• 9:15安装新应用
• 9:30重启db

等，展示如何最大限度地降低风险和停机时间。

等问题

如果出现问题，
• 退出升级
• 尽量减少对现有应用的影响
数据库正在运行时
• “热”更新
• 从dev升级到测试到生产服务器

特别感兴趣。

Answer 1

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

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

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

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

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

总共有4个数据库：

1. 开发：所有更改都必须在更改脚本中进行，而不是在工作室中进行。
2. 测试：此处进行集成测试
3. 制作副本：最后一刻部署练习
4. 生产

你真的，真的需要在生产时做到这一点。支持架构更改很难。

就修补程序而言，我只会修改程序，而不是架构，除非它是一个非常孤立的变化，对业务至关重要。

Answer 2

我猜你考虑过Scott Ambler的读物？ http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

这是我刚刚在工作中谈论的话题。主要问题是，除非您的框架很好地为您处理数据库迁移，例如rails和它们的迁移脚本，否则它由您自己决定。

我们目前的做法有明显的缺陷，我对其他建议持开放态度。

1. 使用静态数据进行架构转储，这些数据必须保持最新并且在版本控制中。
2. 每次执行架构更改操作时，ALTER，CREATE等将其转储到文件中并将其丢弃到版本控制中。
3. 确保更新原始sql db转储。
4. 在进行实时推送时，请确保您或您的脚本将sql文件应用于数据库。
5. 清理旧版本控制的旧sql文件。

这绝不是最佳选择，实际上并不打算作为“备份”数据库。它只是简单地推动生活，并使开发人员保持在同一页面上。就自动将sql文件应用到数据库而言，你可以用capistrano设置一些很酷的东西。

Db特定版本控制将非常棒。可能有一些东西可以做到这一点，如果没有，可能应该有。

Answer 4

如果Scott Ambler的文章激起你的胃口，我可以推荐他的书Pramod J Sadolage称为“重构数据库” - http://www.ambysoft.com/books/refactoringDatabases.html

雅虎的敏捷数据库小组还提供了许多有用的建议和信息 - http://tech.groups.yahoo.com/group/agileDatabases/

Answer 5

两个快速说明：

1. 不言而喻......所以我会说两次 确认您有有效的备份 确认您有有效的备份。

2. @mk。查看数据库版本控制的Jeff's blog post（如果您还没有）