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