我们正在考虑使用 EF 4.3.1 基于代码的迁移，但不清楚如何将迁移与我们目前的开发/部署方法集成......
有问题的应用程序是一个桌面 WPF 应用程序，每个桌面都有自己的 SQL Server 实例(每个都有 4 个独立的数据库)。它被部署到本地 IT 支持为零的“现场”环境中。任何数据库迁移都必须使用安装程序(可能是 InstallShield)执行的 SQL 脚本来完成。当在现场部署/升级数据库时，没有任何人可以在 PMC 提示符下运行命令来升级数据库。因此，EF Migrations 的最终“输出”必须是一组 SQL 脚本，安装程序将有选择地应用这些脚本。
此外，我们有多个开发人员进行并发数据库更改.. 没有 DBA。每个开发人员只需将他们的代码(模型)更改 checkin TFS，下次他们更新时，对模型的更改会自动导致在他们的开发系统上创建一个新数据库。那么我们现在如何让每个开发人员执行他们自己的本地迁移(而不是删除/重新创建他们的本地数据库)，然后管理/整合/组合这些迁移？那么碰撞呢？
在开发和单元测试期间，每个开发人员都可以在一次 checkout / checkin 迭代期间多次删除他们的(整个)本地数据库。这对 Code First 非常有用，因为当应用程序重新启动时，数据库会自动重建。但这意味着数据库中的 _MigrationHistory 表也会被删除。我们如何处理这个？我们不需要每个开发系统的迁移历史吗？如果不是，那么我们在哪里/如何检测需要应用于交付系统的聚合更改？
我可以看到使用迁移来处理迁移数据库的机制的值(value)，但不清楚的是如何利用它而不在开发周期中引入集中式数据库“更改控制”瓶颈，从而失去一个Code First 的主要优势。
任何见解/建议将不胜感激!
爸爸猫
最佳答案
我知道这是一个老问题，但我想我会发布一些我在 EF Migrations (v6.1) 方面的经验。
每个开发人员都会好起来的。迁移被放入名称中带有时间戳的类中，因此不会发生冲突。在执行 get latest 并运行应用程序(或 update-database 命令)后，将更新开发人员机器上的数据库。
删除本地数据库并重新创建就可以了。只需确保开发人员在添加其他迁移之前运行更新数据库，否则事情将不同步。我对他们为什么需要删除本地数据库感到有些困惑，但这超出了范围。您可能会发现您的流程需要更改以适应 EF 迁移。
我无法帮助您解决安装程序问题，因为类似的问题将我带到了这里。 update-database 命令确实有一个 -script 选项，可以生成正确的更改脚本，但我不清楚如何在构建服务器上自动化。
关于entity-framework-migrations - EF 迁移 - 如何在开发和部署期间进行管理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10887457/