在临时插槽中运行的应用程序如何知道它正在升级并连接到测试数据库上的测试数据库/运行迁移？
而且,临时插槽中的同一个应用程序如何自动意识到它已被交换到实时生产槽并且现在负责实时业务操作？ (因此它可以切换到使用实时数据库,迁移实时数据库等)
长版：
该问题部分涉及这个问题：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应用程序,以减轻任何混淆槽因为它们在门户中的表示方式而导致…
