我们是一个由4名开发人员组成的团队,已经使用Code First Migrations开发了大约21个月的产品。在使用这种代码优先迁移时,我们遇到了无数的问题和令人头疼的问题(因为我们同时进行数据库更改和签入),目前正在考虑我们的替代方案。我们目前正在将TeamCity设置为构建服务器,这样当我们签入时,解决方案将自动构建,如果一切正常,代码将自动推送到预览服务器。
我们打算尝试这样一种情况:我们不签入迁移,只是模型更改,并且我们都在本地构建迁移,因此我们避免了合并/获得不同步的顺序的头疼问题。然后,当我们完成对某个工作包的开发时,我们将创建一个可以在实时环境中有效运行的迁移。我们想知道的是,
我目前有几个使用FluentMigrator的数据库,我很想知道实体框架迁移是如何比较的。
EF Migrations是否可以在迁移中播种数据,并基于FluentMigrator可以使用标签和配置文件等环境有选择地运行迁移脚本?
我已经在使用EF Database First作为我的应用程序的ORM,我想我在某处读到过EF迁移现在也支持非Code First EF,但我的团队一直在考虑重构到Code First方法,因为Database First方法的一些限制。那么,当使用代码优先的方法时,EF迁移是否会比使用另一个第三方迁移框架更有意义呢?