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