3

我们正在考虑使用 EF 4.3.1 基于代码的迁移，但不清楚如何将迁移与我们目前的开发/部署方法集成......

有问题的应用程序是一个桌面 WPF 应用程序，每个桌面都有自己的 SQL Server 实例（每个都有 4 个独立的数据库）。它被部署到本地 IT 支持为零的“现场”环境中。任何数据库迁移都必须使用安装程序（可能是 InstallShield）执行的 SQL 脚本来完成。在现场部署/升级数据库时，没有任何人可以在 PMC 提示符下运行命令来升级数据库。因此，EF Migrations 的最终“输出”必须是一组 SQL 脚本，安装程序将有选择地应用这些脚本。

此外，我们有多个开发人员进行并发数据库更改.. 没有 DBA。每个开发人员只需将他们的代码（模型）更改签入到 TFS，并且下次他们更新时，对模型的更改会自动导致在他们的开发系统上创建一个新数据库。那么我们现在如何让每个开发人员执行他们自己的本地迁移（而不是删除/重新创建他们的本地数据库），然后管理/合并/组合这些迁移？那么碰撞呢？

在开发和单元测试期间，每个开发人员都可以在一次签出/签入迭代期间多次删除他们的（整个）本地数据库。这对 Code First 非常有用，因为当应用程序重新启动时，数据库会自动重建。但这意味着数据库中的 _MigrationHistory 表也会被删除。我们如何处理这个？我们不需要每个开发系统的迁移历史吗？如果不是，那么我们在哪里/如何检测需要应用于交付系统的聚合更改？

我可以看到使用迁移来处理迁移数据库的机制的价值，但不清楚的是如何利用它而不在开发周期中引入集中式数据库“更改控制”瓶颈，从而失去一个Code First 的主要优势。

任何见解/建议将不胜感激！

爸爸猫

4

1 回答 1

1

我知道这是一个老问题，但我想我会发布一些我在 EF Migrations (v6.1) 方面的经验。

每个开发人员都会好起来的。迁移被放入名称中带有时间戳的类中，因此不会发生冲突。在执行获取最新并运行应用程序（或 update-database 命令）后，将更新开发人员机器上的数据库。

删除本地数据库并重新创建就可以了。只需确保开发人员在添加其他迁移之前运行更新数据库，否则事情将不同步。我对他们为什么需要删除本地数据库感到有些困惑，但这超出了范围。您可能会发现您的流程需要更改以适应 EF 迁移。

我无法帮助您解决安装程序问题，因为类似的问题将我带到了这里。update-database 命令确实有一个 -script 选项，可以生成正确的更改脚本，但我不清楚如何在构建服务器上自动化。

于 2015-06-10T19:13:21.333 回答