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