我的团队正在评估用于管理数据库迁移/数据库重构的工具和流程，如Martin Fowler，Pramod Sadalage等人所述。人。我们对自动化，可重复，可测试的流程感兴趣，因此我们对像手动运行SQL这样的技术不感兴趣每次部署时都会比较一下。我们目前正在使用CruiseControl.NET进行持续集成。管理更新多个数据库的迁移的最佳实践？
我们的生产环境中有多个SQL Server 2000数据库服务器，它们之间有复制。因此，我们的迁移将更改源数据库服务器和目标数据库服务器上的模式。
要使用诸如dbdeploy之类的工具执行这种迁移，看起来我们需要针对其中一台服务器运行迁移，并且我们必须将其他服务器添加为链接服务器。针对主服务器运行的单个脚本可以针对任何链接的服务器执行DDL。
我的问题是这样的：这种方法会被认为是最佳实践，还是有更好的技术来应用与多个数据库服务器接触的迁移？
这种方法我没有发现任何内在的错误，但是在设置它的时候一定要测试一个链接服务器关闭时会发生什么。如果某个服务器出现故障，并且您确实希望知道这些更改未应用于该服务器，则您不希望回滚所有其他服务器。
当然，对于任何迁移来说，第一个最重要的最佳实践是确保在开始迁移更改之前，您已经有了一个可靠的备份过程。
的Visual Studio 2008（团队版，具体GDR）能够处理的自动化对定义的模式/元数据文件架构，您可以部署到服务器的部署。这可以包含在您的构建/部署过程中。但是，我认为复制和模式更改仍然存在问题 - 没有可以理解/知道您的复制设置的软件包。
举例来说，我们使用的用户自定义的复制过程，虽然架构更改从发布者传播我们有时不得不手动脚本的变化取决于我们在任何地方自定义复制。如果您不使用自定义复制特效，我会说这是要走的路。
您可以试用Chinchillin和Wizardby的组合：在DB服务器上安装Chinchillin代理，并在部署过程中执行Wizardby迁移脚本。
这种整合是在作品中，虽然:)
这里红门我们现在已经得到了使用SQL比较和SQL源控制的可重复迁移的解决方案。 SQL Compare命令行因此可用于支持持续集成过程。
http://www.red-gate.com/MessageBoard/viewtopic.php?t=14107
这是目前早期进入编译，所以我们渴望得到尽可能多的反馈越好。