在生产中使用 EF 迁移（或任何自动迁移框架）有什么危险？答案

【问题标题】：What are the dangers of using EF Migrations (or any auto-migration framework) in production?在生产中使用 EF 迁移（或任何自动迁移框架）有什么危险？
【发布时间】：2015-03-13 17:03:54
【问题描述】：

我正在考虑在生产站点中使用 Entity Framework 4.3 迁移。以下是我关心的问题：

如果迁移由于某种原因失败，我想要所有语句回滚并且站点处于关闭状态，因此没有用户可以使用网站，而我尝试解决问题。唯一的问题是我做不到回退到手动对数据库执行脚本，因为迁移文件在程序集中编译。我可以跟踪迁移文件和 sql 脚本文件都是分开的，但那时为什么要使用完全迁移。

在工作中，脚本文件存储在站点上的 SQL 文件夹（任何人都无法浏览）中。以前运行的脚本文件在数据库中注册。当新的脚本文件出现在文件夹中（并且不在数据库中）时，如果用户是管理员，他们将被重定向到数据库门户，否则会获得站点关闭以进行维护。如果我们尝试从门户执行任何脚本但失败，我们会获取新脚本并尝试在 express studio 内手动运行它们。这已经工作了十多年。我只是在探索迁移，看看是否有更好的方法出现。感觉不像。请让我知道是否有更好的方法，如果不是迁移，那是什么。

【问题讨论】：

有什么理由不先在生产数据库的副本上运行脚本？
感谢您的评论。我一直在研究开发和部署软件的更好方法。在我开始研究持续集成和持续部署之前，我问了这个问题。现在我知道我不知道我在说什么（可能仍然不知道）。你是对的，我会部署到测试数据库并确保脚本在部署到生产之前是正确的。在部署到生产环境时，脚本的正确性不应该是我关心的问题；那时一切都应该是“正确的”。

标签： entity-framework-4 database-migration entity-framework-migrations

【解决方案1】：

我绝对不会在生产环境中使用自动迁移。事实上，我是一个控制狂，根本无法使用自动迁移。我更喜欢基于代码的迁移，以确保所有数据库（开发人员自己的个人、测试环境、生产环境）都经过完全相同相同的更新顺序。

使用基于代码的迁移（每个迁移步骤都有一个名称），可以生成单独的迁移脚本以在提升测试和生产环境时使用。最好在实际生产环境中运行之前在数据库副本上运行以进行验证。

稍后添加

为了防止 EF 迁移完全自动执行任何操作，可以使用自定义初始化策略。请参阅 my blog 或 Deploying EF Code First Apps to Production Database Stack Overflow 问题。

【讨论】：