EF Code First Migrations，在生产数据上测试开发代码时如何避免破坏生产站点？答案

【问题标题】：EF Code First Migrations, how to avoid breaking production site when testing dev code on production data?EF Code First Migrations，在生产数据上测试开发代码时如何避免破坏生产站点？
【发布时间】：2016-01-04 23:03:47
【问题描述】：

对于我的应用程序开发，当我想将某些东西推送到生产环境时，我的测试是这样的：在开发数据库上测试开发代码 --> 在生产数据库上测试开发代码 --> 将开发代码发布到生产站点 --> 开发代码现在是产品代码。

我一直在使用 EF Code First Migrations，它很棒，但它会导致此工作流程出现一些问题。如果您尝试针对生产数据库运行任何开发代码，并且它包含对 dbcontext 中模型的任何更改。通过自定义写入或自动迁移，它将应用这些更改并更改数据库。这会破坏生产站点，因为它的数据库突然与 DbContext 模型中的预期不匹配。

有没有办法避免这种情况？我可以禁用那个 EF 检查吗？还是有更流畅的方法？我似乎也可以向 DBInitializer 提供 null，但这不会创建 _MigrationHistory 表。仅在发布到生产时将其设置为 null 是否有影响，否则将其设置为迁移？

当然，如果我在上下文中删除对象的属性，那么对该属性或查询的任何引用我都希望这些页面在生产中中断（与使用普通的旧 SQL 连接没有什么不同），但不是整个生产站点。

我想我会想要一些可切换的选项，比如禁用模型检查，并且我只会在发布到生产环境时将其设置为 true。这可能吗？

【问题讨论】：

为什么不使用 SSIS 包将产品数据复制到测试数据库？
这会严重影响性能，我们是一家小商店，我们的硬件不是超级好，什么时候可以运行，需要多长时间？我也经常对刚刚放入的新数据进行更改，我们需要基于此进行修改，所以我迫不及待地在标准时间内运行或临时运行它。我只能复制我需要测试的内容，但现在我的工作范围正在扩大，我的流程开始变得更加复杂。禁用此 EF 功能似乎更容易。如果我只是使用 SQL 连接，它会正常工作。做所有这些工作来解决 EF 似乎很糟糕。
如果您不应用迁移，您的模型和数据库将会有所不同。如果您使用 EF 或其他任何东西都没有关系：如果您的代码期望数据库中有某些东西，但它不是应该失败。不要责怪英孚。例如，如果您的迁移添加了应用程序中的新功能所需的新列，您真的希望它与没有该列的数据库一起使用吗？请删除或改写您的问题。请原谅我的粗鲁，但这个问题很荒谬。
我完全了解 EF 迁移的工作原理，并且我完全承认它在我的原始帖子中不起作用，请仔细阅读。问题是我可以让任何使用更改后的实体的页面在生产中不起作用，我对整个站点不起作用，因为现在更改了一个页面上使用的一个实体。如果我使用的是 SQL 连接，我可以做到这一点，并且只有一个分页符。

标签： .net entity-framework ef-code-first entity-framework-migrations

【解决方案1】：

您必须拥有单独的开发和生产环境，以及单独的开发和生产数据库，但您的开发数据库必须始终与生产数据库数据保持最新。您在生产数据库上测试开发代码是没有意义的，因为您的应用程序需要您的数据库与您的模型完全相同。我建议您远程使用临时环境，对于诸如AppHarbor 之类的事情，您可以立即在云上部署和扩展 .NET 应用程序，托管在 IIS 中，并使用远程数据库进行测试，更像您的生产环境，我相信。

【讨论】：

@DOTang 你怎么看？
有人在 cmets 中说了同样的话，我概述了为什么它在我的环境中并不真正可行。主要问题是 1) 我们的资源不是那么重，将生产的完整副本复制到 db 真的会使我们的 db 服务器陷入困境，因为我们有很多数据。 2）这个副本，如果发生了，必须在一大早完成，但由于新数据，我经常需要在同一天实现一个新功能。所以这使事情变得更加复杂。 3) 解决这些问题会给我们的流程增加更多的复杂性和额外的要求。这似乎很愚蠢。
因为这些需求的增加只是为了解决 EF 的工作原理，如果我使用另一个 ORM 或 SQL 连接，它甚至不会发生。
@DOTang 老兄，如果你有大量的数据，你可以复制，只是这个的一部分，或者只是复制数据来代表一个场景。这里最重要的是不关心未来的实现，或者你是否会改变你的 ORM 等等，这只是可能发生的例子，这里最重要的是，你正在对生产数据库进行更改，这将影响您的用户，并且很有可能影响数据库中已有的数据