是否可以使用EF迁移更新生产数据库？

Question

根据这篇博客文章,大多数使用EF迁移的公司都不会使用EF迁移更新生产数据库的数据库模式.相反,博客文章的作者建议使用Schema更新脚本作为部署过程的一部分.

我已经使用Schema更新脚本几年了,当它们工作时,我计划将来使用EF迁移,原因如下:

• 部署更快,停机时间更短
• 一个更简单的部署过程
• 与使用T-SQL相比,现有数据的迁移更容易
• 等待应用的更改的更易于理解的语法(DbMigration类具有干净的C#语法与传统环境中的clunky T-SQL迁移脚本).
• 如果新软件版本的部署失败,则可以轻松快速地降级到旧数据库模式的路径

我可以想到的一个原因是,如果数据库模式只是由DBA而不是开发人员改变,那么禁止使用EF来迁移生产数据库.但是,我既是DBA又是开发人员,所以这在我的案例中并不重要.

那么,使用EF更新生产数据库有哪些风险？

编辑:我想补充一点,正如solomon8718已经建议的那样,我总是将生产数据库的新副本提取到我的登台服务器,并在将它们应用到生产服务器之前测试要在登台服务器上应用的EF迁移.对于生产系统的任何架构更新,IMO都是必不可少的,无论我是否使用EF迁移.

Answer 1

好吧,无论如何我都会试着回答.我会说不,没有理由不在生产中使用Code First Migrations.毕竟,如果你不能一直使用这个易于使用的系统有什么意义呢？

我看到的最大的问题是你可以在任何系统中遇到的所有问题,你已经注意到了这些问题.只要整个团队(如果适用,包括DBA)就可以使用它,我认为允许EF通过迁移来管理模式不那么复杂,因此比传统的基于脚本的管理更不容易出错.在生产系统上执行迁移之前,我仍然需要备份,但无论如何你都会这样做.

没有任何迹象表明DBA也无法从Visual Studio执行迁移.仍然可以使用数据库级别的权限锁定访问权限,并且-Script在执行实际操作之前,他/她可以使用(如果需要,使用有用的SQL导出格式)查看迁移.然后他们仍然可以控制,但您可以使用代码优先迁移.天啊,他们甚至可能最终喜欢它!

更新:由于SPROC和TVF已经启动,我们也处理迁移中的那些,尽管它们实际上是使用直接的SQL语句完成的,使用中的DbMigration.Sql()调用,Up()反之亦然Down()(你也可以使用CreateStoredProcedure和DropStoredProcedure简单) SPROC,但我认为你仍然需要在SQL中定义正文本身).我想你可以说这是一个警告; 还没有办法让整个数据库纯粹用C#编写.但是,您可以使用包含SQL脚本的迁移来管理整个架构.我们从这个过程中发现的一个好处是你可以使用C#配置文件作为模式对象名称(例如,生产与dev的不同服务器名称),简单String.Format,结合配置文件本身的XML转换.

Answer 2

是的,有充分的理由不使用Code First Migrations等自动化系统来更改生产数据库.但一如既往,规则有例外.

1. 提到的一个原因是访问权限,它与您组织的变更管理规则和安全策略直接相关.

2. 另一个原因是您对迁移工具本身的信任程度.我们确定该工具没有错误吗？如果工具在中途失败会发生什么？你确定你有最新的备份和一个回滚过程吗？如果需要的话？

3. 更改脚本可能会执行意外或低效的脚本.我遇到过这样的情况,即生成的sql将数据复制到临时表中,删除原始表,然后重新创建原始表,以便在意外(或有目的地)更改列的显示顺序时添加新列.或重命名表时.如果涉及数百万条记录,则可能会导致严重的性能问题.

我的推荐:

假设您有一个镜像生产模式的临时数据库,请使用迁移工具针对该系统生成其更改脚本.我们通常在运行之前从新的生产副本中恢复舞台数据库.然后,我们手动检查更改脚本以检查问题.之后,我们针对舞台数据库运行脚本,以确保它正确执行并且预期发生了所有更改.现在我们确信脚本在生产中运行安全并执行预期的更改.这个过程将解决我上面列出的所有三个问题.

Answer 3

另一个警告我发现:如果你有几个网站使用相同的数据上下文,你需要确保所有这些网站同时更新.否则,网站之间可能会有持续的数据库更新/降级争用.除此之外,它对我来说很好.

编辑:我开始在生产中使用EF迁移一年后的观点:

EF迁移实际上非常酷,即使是生产用途,只要你这样做

1. 测试登台系统上的迁移.我在运行集成测试之前,通过在CI服务器上向下和向上迁移来测试所有迁移.
2. 不要自动触发迁移,而是使用由管理员启动的批处理文件.这与在SSMS中手动迁移运行sql基本相同.