我们希望能够不断地将我们的应用程序交付到生产中。我们当前部署到azure并使用表/blob存储，并且有一个azure sql数据库，我们可以使用该实体访问该数据库。
随着数据库架构的更改，我们希望能够自动将架构更改应用到生产数据库，但由于这将在应用程序处于活动状态且代码更改同时部署到多个节点时发生，因此我们不确定正确的方法是什么。
经过一些阅读，似乎（这是有意义的）应用程序需要容忍两个不同的数据库模式版本，因此不管它是旧版本的代码还是看到数据库的新版本的代码，但是我不确定在应用程序中处理这个问题的最佳方法是使用实体框架。
我们是否应该在代码中对ef生成的类的实例进行版本控制，这些实例知道如何访问模式的特定版本？当架构被更新并且旧版本的代码正在数据库中运行时会发生什么？
我们的实体框架类映射到数据库中特定模式中的视图，而没有任何内容映射到底层表，因此这可能允许我们创建旧代码使用的v1视图和新代码使用的v2视图，但是维护它感觉就像是一场噩梦（仅仅维护到视图而不是表的ef映射已经够痛苦的了）
那么这方面的最佳实践是什么？其他人怎么解决这个问题？
最佳答案
无论您是否使用ef，在这里维护代码与数据库的两个连续版本一起工作的能力是一个很好的（也许是唯一可行的）方法。
以下是我们处理特定类型迁移的一些方法：
添加列时，我们通常只需添加列（如果不可为空，则使用默认约束），而不必担心代码。ef永远不会发出“select*”，因此它可以在忽略新列的同时继续正常工作。同样，添加表也很容易。
删除列或表时，只需将该列保持在1个版本左右，就可以比其他版本长。
对于更复杂的迁移（例如，完全更改数据模型的表或段的结构），将新模型与向后兼容视图（或带有触发器的表保持同步）一起部署，这将与引用它们的代码一样长。正如你所说的，这取决于迁移的复杂性，可以做很多工作，但是听起来你已经很好地完成了这一点，因为EF实体无论如何都指向了观点。另一方面，这项工作的好处是您有更多的时间进行代码迁移。如果您有一个大的代码库，这将非常有利于允许您迁移数据模型以满足新功能的需要，同时仍然支持旧功能，而不需要对代码进行重大更改。
顺便说一下，数据迁移的困难常常使我们在开发计划中尽可能早地推动最终数据模型的开发。使用ef，您可以在数据模型完成之前编写和测试大量代码（我们在单元测试中首先使用代码生成示例sqlexpress数据库，即使我们的生产数据库不是由代码首先维护的）。这样，一旦发布了新特性，我们就减少了对生产数据模型的增量更改。