Azure部署插槽和数据库迁移

在临时插槽中运行的应用程序如何知道它正在升级并连接到测试数据库上的测试数据库/运行迁移？
而且,临时插槽中的同一个应用程序如何自动意识到它已被交换到实时生产槽并且现在负责实时业务操作？ (因此它可以切换到使用实时数据库,迁移实时数据库等)

长版：

该问题部分涉及这个问题：Azure Web App deployment slots with database migration

但我没有真正得到我的答案..

我的应用程序使用FluentMigrator,在应用程序初始化时由事件/代码启动,以运行数据库迁移. MSBuild曾经这样做,但现在我很确定它是以编程方式调用的

这似乎是最明智的：

>生产具有基于插槽的应用程序设置,该设置指向生产数据库中的代码
>暂存以具有基于插槽的应用程序设置,该设置将代码指向登台数据库

如果登台具有破坏数据库以便生产理解的迁移,那么我无法看到任何其他方式让生产保持功能,同时正在证明分段;两个DB必须分开

因此,如果数据库是分开的,那么切换世界到使用暂存槽中的代码的唯一(几乎)零停机方式是,如果交换机导致应用程序重新初始化并更改它,那么它将指向生产数据库,然后fluentmigrator(也应该再次调用)可以将同一组迁移应用于生产,并且staging中的代码在生产数据库上运行一段时间的业务.

..production codebase已更新,并且发生了回调.生产代码永远不会迁移生产数据库,因为在生产中的新版本启动时,它已经由暂存代码更新

我预见到事情的唯一另一种方法是拥有两个DB,两个插槽,而且你永远不会执行交换;你刚刚部署到staging,它更新staging DB,你测试并证明是好的,你部署到生产,它更新produtcion数据库,你验证app工作..并且世界在prod建设时遭受了少量的停机时间(如果构建失败,则为主要数量)

前者有机制吗？当交换发生时,应用程序如何指向新数据库以及如何再次运行迁移？

如果后者是唯一的方法,那么部署插槽也可能只是另一个Web应用程序,对吧？一个用于登台的Web应用程序和用于prod的Web应用程序,以减轻任何混淆槽因为它们在门户中的表示方式而导致…

解决方法

为此,您需要确保所有迁移都向后兼容,以便Web应用程序的当前版本和新版本可以与同一数据库同时运行.这意味着您可以部署到暂存插槽,对生产数据库执行冒烟测试,然后交换生产槽的暂存插槽.

允许此工作的一些规则：

>新列应该可以为空或设置默认值
>列不能删除
>无法重命名列

当您确实需要进行破坏性更改(例如删除列)时,您需要有2个版本：

>从Web应用程序中删除依赖项的版本
>执行数据库架构更改的版本

这听起来像是一种痛苦,但在实践中,你可能不会发现自己经常发生破坏性的变化.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!