Azure 部署槽和数据库迁移

Question

TLDR:

在暂存槽中运行的应用程序如何知道它处于暂存状态并连接到测试数据库/在测试数据库上运行迁移？而且，暂存槽中的同一个应用程序如何自动意识到它已切换到实时生产槽并现在负责实时业务运营？ (因此它可以切换到使用实时数据库，迁移实时数据库等)

长版:

此问题部分涵盖了该主题:Azure Web App deployment slots with database migration

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

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

这似乎最明智:

• 生产具有基于插槽的应用程序设置，将代码指向生产数据库
• 暂存以具有基于插槽的应用程序设置，将代码指向暂存数据库

如果登台的迁移会破坏数据库对生产的理解，我看不出有任何其他方法可以在登台得到验证的同时让生产保持功能；两个数据库必须分开

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

..生产代码库已更新并且交换回发生。生产代码永远不会迁移生产数据库，因为当生产中的新版本启动时，它已经被暂存代码更新了

我预见到的唯一可行的方法是拥有两个数据库、两个插槽，并且永远不执行交换；您只需部署到登台，它会更新登台数据库，您进行测试并证明良好，您部署到生产，它会更新生产数据库，您验证应用程序是否正常工作..并且在构建生产时，世界遭受了少量的停机(或者如果构建失败则为大量)

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

如果后者是唯一的方法，那么部署槽也可能只是另一个 Web 应用程序，对吗？用于登台的 Web 应用程序和用于生产的 Web 应用程序，以减轻由于它们在门户中的表示方式而导致的任何困惑。

Answer 1

可以通过暂存和生产 Azure 应用服务插槽共享单个生产数据库，并且仍然实现零停机部署。

为此，您需要确保所有迁移向后兼容，以便网络应用的当前版本和新版本可以使用同一数据库同时运行。这意味着您可以部署到暂存槽，对生产数据库执行冒烟测试，然后将暂存槽替换为生产槽。

允许此操作的一些规则:

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

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

1. 从网络应用中删除依赖项的版本
2. 对数据库架构进行更改的版本

这听起来很痛苦，但实际上您可能不会发现自己经常做出破坏性的改变。