在生产中使用 EF 迁移（或任何自动迁移框架）有哪些危险？
我正在考虑在生产站点中使用 Entity Framework 4.3 迁移。以下是我的担忧：
如果迁移由于某种原因失败，我想要所有语句 回滚并将站点置于关闭状态，因此没有用户可以使用 当我尝试解决问题时，该网站。唯一的是我不能 回退到手动对数据库执行脚本，因为 迁移文件在程序集中编译。我可以追踪 迁移文件和 sql 脚本文件都是分开的，但为什么要使用 完全迁移。
在工作中，脚本文件存储在站点上的 SQL 文件夹（任何人都无法浏览到）中。先前运行的脚本文件已注册在数据库中。当新的脚本文件出现在文件夹中（并且不在数据库中）时，如果用户是管理员，他们将被重定向到数据库门户，否则将获得站点关闭以进行维护。如果我们尝试从门户执行任何脚本但失败，我们会获取新脚本并尝试在 Express Studio 内手动运行它们。这已经有效了十多年。我只是在探索迁移，看看是否有更好的方法出现。感觉不像。请让我知道是否有更好的方法，如果不是迁移，那是什么。
I'm considering using Entity Framework 4.3 migrations in a production site. The following is my concern:
If the migration fails for whatever reason, I want all statements
rolled back and the site placed in a down state so no users can use
the site while I try to fix the problem. The only thing is I can't
fall back to executing the scripts by hand against the database since
migration files are compiled in the assembly. I could keep track of
both migration files and sql script files separately but at that point why use
migrations at all.
At work, script files are stored in a SQL folder (that no one can browse to) on the site. Previously run script files are registered in the database. When new script files appear in the folder (and aren't in the database), if a user is an admin, they'll be redirected to a DB portal, else get a site-down-for-maintenance. If we try and fail to execute any scripts from the portal, we grab the new scripts and try to run them manual inside of express studio. This has worked for over a decade. I'm only exploring migrations to see if a better way has arrived. It doesn't feel like it. Please let me know if there's a better way and if it's not Migrations, what is it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我绝对不会在生产环境中使用自动迁移。事实上，我是一个控制狂，根本不会使用自动迁移。我更喜欢基于代码的迁移，以确保所有数据库（开发人员自己的个人数据库、测试环境、生产数据库）都经历完全相同相同的更新顺序。
使用基于代码的迁移（其中每个迁移步骤都有一个名称），可以生成单独的迁移脚本以供提升测试和生产环境时使用。最好在数据库的副本上运行以进行验证，然后再在真实的产品环境中运行。
稍后添加
为了防止 EF 迁移自动执行任何操作，可以使用自定义初始化程序策略。请参阅我的博客 或 将 EF Code First 应用程序部署到生产数据库 堆栈内存溢出问题。
I would definitely not use automatic migrations in a production environment. In fact, I'm too much of a control freak to use automatic migrations at all. I prefer code based migrations to ensure that all databases (developers' own personal, test environment, production) have gone through exactly the same update sequence.
Using code-based migrations where each migration step gets a name, a separate migration script can be generated for use when lifting test and prod environments. Preferably it should be run on a copy of the database to validate before running on the real prod environment.
Added Later
To prevent EF Migrations from doing anything automatic at all, a custom initializer strategy can be used. See my blog or the Deploying EF Code First Apps to Production Database Stack Overflow question.