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

Question

对于我的应用程序开发，当我想将某些东西投入生产时，我的测试是这样的：在dev db上测试开发代码 - ＆gt;生产db上的测试开发代码 - ＆gt;将dev代码发布到生产站点 - ＆gt; dev代码现在是prod代码。

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

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

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

我想我会想要一些可选择的选项，例如禁用模型检查，我只有在发布到生产时才会设置为true。这可能吗？

Answer 1

您必须拥有开发和生产的个别环境，以及开发和生产的各个数据库，但您的开发数据库必须始终是最新的生产数据库数据。您无法在生产数据库上测试Dev代码，因为您的应用程序需要您的数据库与模型完全相同。我建议您远程使用不稳定的环境，对于AppHarbor等类似的东西，您可以在云上即时部署和扩展.NET应用程序，在IIS中托管，也可以使用远程数据库进行测试，更像是我相信生产环境。