我正在考虑在生产站点中使用Entity Framework 4.3迁移。以下是我的担忧：
如果迁移因任何原因失败，我想要所有的陈述 回滚并且站点处于关闭状态，因此没有用户可以使用 我尝试解决问题时的网站。唯一的事情是我做不到 从那以后，回到手动对数据库执行脚本 迁移文件在程序集中编译。我可以跟踪 迁移文件和sql脚本文件分开但在那时为什么要使用 完全迁移。
在工作中，脚本文件存储在站点上的SQL文件夹（没有人可以浏览到）中。以前运行的脚本文件已在数据库中注册。当新脚本文件出现在文件夹中（并且不在数据库中）时，如果用户是管理员，他们将被重定向到数据库门户，否则将获得站点维护。如果我们尝试并且无法从门户网站执行任何脚本，我们会抓住新脚本并尝试在快递工作室内运行它们。这已经工作了十多年。我只是在探索迁移，看看是否有更好的方法。它不喜欢它。如果有更好的方法，请告诉我，如果不是迁移，那是什么。
答案 0 :(得分：3)
我绝对不会在生产环境中使用自动迁移。事实上，我完全不喜欢使用自动迁移。我更喜欢基于代码的迁移，以确保所有数据库（开发人员自己的个人，测试环境，生产）都完全 相同的更新序列。
使用基于代码的迁移，其中每个迁移步骤都有一个名称，可以生成单独的迁移脚本，以便在提升测试和生产环境时使用。优选地，它应该在数据库的副本上运行以在运行真实产品环境之前进行验证。
为防止EF迁移完全执行任何操作，可以使用自定义初始化策略。请参阅my blog或Deploying EF Code First Apps to Production Database Stack Overflow问题。