在多个实例中迁移EF代码优先

Question

我有一个使用EF6 Code First的MVC应用程序。我想将此应用程序部署到多个数据中心。在具有迁移的部署中，我可以编写脚本以尽可能同时迁移它们，但如果一个数据中心速度较慢，则由于架构不再匹配，所有调用都可能被拒绝。试图协调的脚本也会使滚动升级变得不可能。

有没有办法让EF至少尝试运行查询，即使模式不匹配？我可以/应该采用不同的方式吗？

更新

让我们看看我能说得更好。我想在多个数据中心安装我的MVC应用程序。我们假设我将应用程序单独部署到每个数据中心。

选项1

1. 部署到DC A
2. 代码首次迁移在集中式数据库上运行
3. 对DC A的请求成功，但对DC B的请求失败

选项2

1. 部署到DC A
2. 不自动运行迁移
3. 对DC A的请求失败，对DC B的请求继续成功

如何开发一种部署策略，以便对DC的请求起作用？

顺便说一句：如果需要特定于平台的解决方案，我正在使用Azure网站。

Answer 1

在您的帖子中，您似乎关心的是在实际升级过程中它的行为方式。关于测试没什么。但是在评论中，您要求进行部分部署然后进行测试。因此，一方面，您希望尽快部署，以最大限度地减少停机时间。另一方面，听起来您想部署到一个站点，进行测试，并在验证第一次部署时让其他站点继续运行吗？
验证部署是合理的，但相当复杂。我不确定你会在这方面找到很多自动化方法。 我认为您应该在生产部署之前进行彻底测试，然后尽快在生产中进行部署。如果您在部署到生产时遇到问题，那么您将处于糟糕的状况，因为现在您的网站已关闭，直到您可以修复它。即使你可以让另一个实例使用新数据库，这也是有风险的，因为它将根据模式修改它不完全理解的东西。此外，如果您确实需要回滚DDL，那么几乎肯定会丢失自部署以来修改过的任何数据。因此，最好是旧模式的所有实例在升级之前都会失败，以防止它们修改有丢失风险的数据。

通常，您应该对尽可能接近生产的临时环境进行部署，以测试数据库迁移过程。这称为预生产测试，有时涉及将最新的备份从生产恢复到分段，以确保新约束/结构对现有数据有效。通过部署到此临时环境，您应该非常高度确信生产部署将成功运行。

您还可以通过在部署之前进行备份来安全地防范生产部署问题，以便您可以按需要进行回滚（尽管这是最糟糕的情况，因为它可能意味着丢弃备份/部署和实现之间的重要数据有一个问题）。我想EF迁移使用事务来运行DDL脚本，因此如果出现问题，它们应该全部或全部回滚。