我很难找到关于如何在开发、测试和生产服务器之间管理数据库模式和数据的好例子。
这是我们的设置。每个开发人员都有一个运行我们的应用程序和 MySQL 数据库的虚拟机。这是他们的个人沙盒,可以为所欲为。目前,开发人员将对 SQL 模式进行更改,并将数据库转储到他们提交到 SVN 的文本文件中。
我们希望部署一个始终运行最新提交的代码的持续集成开发服务器。如果我们现在这样做,它将为每个构建从 SVN 重新加载数据库。
我们有一个运行“候选版本”的测试(虚拟)服务器。部署到测试服务器目前是一个非常手动的过程,通常需要我从 SVN 加载最新的 SQL 并对其进行调整。另外,测试服务器上的数据不一致。您最终会得到最后一个开发人员提交的沙盒服务器上的任何测试数据。
一切都崩溃的地方是部署到生产。由于我们无法用测试数据覆盖实时数据,因此这涉及手动重新创建所有架构更改。如果有大量的模式更改或转换脚本来操作数据,这可能会变得非常棘手。
如果问题只是模式,这将是一个更容易的问题,但是数据库中还有在开发过程中更新的“基础”数据,例如安全和权限表中的元数据。
这是我在迈向持续集成和一步构建方面看到的最大障碍。 你 如何解决它?
一个后续问题:如何跟踪数据库版本,以便知道要运行哪些脚本来升级给定的数据库实例?标准程序下方是否有像 Lance 提到的版本表?
感谢您提到塔伦蒂诺。我不在 .NET 环境中,但我发现他们的DataBaseChangeMangement wiki 页面非常有帮助。特别是这个PowerPoint演示文稿(.ppt)
我将编写一个 Python 脚本,*.sql根据数据库中的表检查给定目录中脚本的名称,并根据构成文件名第一部分的整数按顺序运行那些不存在的脚本。如果这是一个非常简单的解决方案,我怀疑它会是,那么我会在这里发布。
*.sql
我有一个工作脚本。如果数据库不存在,它会处理初始化数据库,并根据需要运行升级脚本。还有用于擦除现有数据库和从文件导入测试数据的开关。大约有 200 行,所以我不会发布它(尽管如果有兴趣我可能会将它放在 pastebin 上)。
有几个不错的选择。我不会使用“恢复备份”策略。
编写所有架构更改的脚本,并让 CI 服务器在数据库上运行这些脚本。有一个版本表来跟踪当前的数据库版本,并且只在脚本用于较新版本时才执行。
使用迁移解决方案。这些解决方案因语言而异,但对于 .NET,我使用 Migrator.NET。这允许您对数据库进行版本控制并在版本之间上下移动。您的架构是在 C# 代码中指定的。