问题描述
我试图了解使用部署槽来使用Azure应用服务托管Web应用的方法。 我对执行交换时处理数据库的理想方法感到特别困惑。 虽然维护两个数据库版本似乎是一个解决方案，但它增加了维护多个数据库中的数据以使其一致的复杂性。 在使用蓝色/绿色部署（尤其是部署插槽）时，推荐的处理数据库架构和迁移的方法是什么？
解决方法
理想情况下，您将上演/制作将共享同一个数据库，因此这不是问题。
但是，如果您有更多的插槽，那么最好也使用其他数据库并在发布阶段处理迁移
,几年来，我们一直致力于通过各种解决方案来解决此问题。没有一个工具包可以为所有情况提供魔术。有几种解决方案：
数据库/重大更改
如果可以在一两秒钟内完成的数据库上执行迁移脚本，并且可以使用简单的后备脚本，则可以与交换并发执行脚本。这也可以是自动化的。但这是压力较大的情况，我不建议这样做。甚至可以使用EF迁移来完成。
仔细确保版本之间的数据库兼容性
由于我们要处理的数百GB数据无法中断，因此我们已将数据库必须同时适用于我们的两个版本的应用程序作为规则。它听起来并不可怕或不可能。例如，经常可以在执行交换之前添加净新表和字段。作为质量检查的一部分，我们测试版本之间的回滚。如果需要删除某些字段，请等待直到新版本已部署并导入后，再确定不需要回滚后，再运行另一个脚本来执行删除操作。当需要升级存储过程时，我们将创建新的存储过程，以便新版本具有自己的存储过程。例如：sp_foo和sp_foo2。
我们在此策略上取得了很多成功。
,插槽是专门用于App Services而非DB的功能，如果要使用具有特定插槽的特定DB，则可以这样设置插槽： https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots
现在，当使用插槽进行交换时，它还会交换App Configurations \ Settings，并且在App Settings中，您可以具有两个DB连接字符串，但是每个字符串都具有其自己的插槽名称和设置。您也可以在此示例中看到它：https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-two-slots