首先使用实体​​框架代码处理多个数据库及其演变

Question

我们正在开发一个Web应用程序（asp.net webapi 2）。 对于数据库，我们在SQL Server中使用Entity Framework 6代码优先。 该应用程序不是多租户，因此只要我们有新的潜在客户或客户端，我们就会使用新的新数据库（SQL Azure）部署该应用程序（在专用的Azure网站上）。 一切都通过Powershell脚本实现了自动化，因此创建Web应用程序和全新的数据库便毫不费力。 在源代码管理上标记了稳定版本后，Integration Server会更新所有客户端环境。

问题出在数据库上。 我使用的是Entity Framework提供的代码优先迁移，但它看起来不适合我们的情况。 通过与“现有数据库”进行比较来生成迁移。 如果所有数据库都是同时创建的，并且从一开始就应用了相同的迁移，那将是可行的，但事实并非如此。 创建最初的几对迁移时，我们的客户和潜在客户并不存在。 此外，我们过去一直将迁移文件保留在版本控制中，并且我们使用MigrateDatabaseToLatestVersion ，它们阻止创建新数据库，例如，看到此错误 。

处理这种情况的适当方法是什么？ 也许迁移不是使所有数据库架构“等于” .NET程序集确定的代码优先架构的正确方法。 我正在寻找的东西将为每个数据库生成“适当的”迁移并应用它们。 该过程可以与我们的集成服务器构建步骤集成。

注意：将我们的逻辑迁移到多租户Web应用程序是不可行的，我们的客户将拒绝...

Answer 1

我找到了解决此问题的方法。 我在博客文章中创建了专门的答案。

TLDR; 确定“稳定的生产模式”：这是与Web应用程序代码相对应的数据库模式，用于源代码控件中的稳定分支/标记。 避免使用所谓的AutomaticMigration，并始终对所有已应用现有迁移后已更新为“稳定生产模式”的空数据库使用Add-Migration创建基于新代码的迁移。 不要使用Update-Database命令来更新生产环境中的数据库，而让框架在启动时使用MigrateDatabaseToLatestVersion初始值设定项为您完成更新。 然后，当您发布新环境时，将使用空数据库启动应用程序。 使用功能分支时，还必须注意版本控制。