我很难找到如何在开发、测试和生产服务器之间管理数据库模式和数据的好例子。
这是我们的设置。每个开发人员都有一个运行我们的应用程序和MySQL数据库的虚拟机。这是他们的个人沙盒,他们想做什么就做什么。目前,开发人员将对SQL模式进行更改,并将数据库转储到他们提交到SVN中的文本文件中。
我们希望部署一个持续集成开发服务器,该服务器将始终运行最新提交的代码。如果我们现在这样做,它将为每个构建从SVN重新加载数据库。
我们有一个运行"release candidates“的测试(虚拟)服务器。部署到测试服务器目前是一个非常手动的过程,通常需要我从SVN加载最新的SQL并对其进行调整。此外,测试服务器上的数据不一致。您最终得到了最后提交的开发人员在其沙箱服务器上拥有的任何测试数据。
在部署到生产的过程中,一切都会崩溃。由于我们不能用测试数据覆盖实时数据,这涉及到手动重新创建所有模式更改。如果有大量的模式更改或转换脚本来操作数据,这可能会变得非常麻烦。
如果问题仅仅出在模式上,那就更容易了,但是数据库中也有在开发过程中更新的“基础”数据,比如安全性和许可权表中的元数据。
这是我在迈向持续集成和一步构建的过程中看到的最大障碍。How do you solve it?
一个后续问题:如何跟踪数据库版本,以便知道要运行哪些脚本来升级给定的数据库实例?像Lance提及的版本表是否低于标准过程?
感谢您对Tarantino的引用。我不在.NET环境中,但我发现他们的DataBaseChangeMangement wiki page非常有帮助。尤其是这个Powerpoint Presentation (.ppt)
我将编写一个Python脚本,根据数据库中的表检查给定目录中*.sql
脚本的名称,并根据构成文件名第一部分的整数按顺序运行不在那里的脚本。如果它是一个非常简单的解决方案,正如我所怀疑的那样,那么我会在这里发布它。
我已经为此准备了一个有效的脚本。如果数据库不存在,它会处理数据库的初始化,并在必要时运行升级脚本。还有用于擦除现有数据库和从文件导入测试数据的开关。它大约有200行,所以我不会把它张贴出来(不过如果有兴趣的话,我可能会把它放在pastebin上)。
发布于 2008-08-08 21:01:09
有几个很好的选择。我不会使用“恢复备份”的策略。
发布于 2008-08-08 21:03:33
您的开发人员需要为他们处理的每个bug/特性编写更改脚本(模式和数据更改),而不是简单地将整个数据库转储到源代码控制中。这些脚本将把当前的生产数据库升级到开发中的新版本。
您的构建过程可以将生产数据库的副本恢复到适当的环境中,并在其上运行源代码管理中的所有脚本,从而将数据库更新为当前版本。我们每天都会这样做,以确保所有脚本都能正确运行。
发布于 2008-08-17 09:38:39
看看Ruby on Rails是如何做到这一点的。
首先是所谓的迁移文件,它基本上将数据库模式和数据从版本N转换到版本N+1 (或者在从版本N+1降级到N的情况下)。数据库有一个表,它告诉我们当前的版本。
测试数据库总是在单元测试之前被清除,并填充来自文件的固定数据。
https://stackoverflow.com/questions/6371
复制相似问题