我正在尝试了解使用Azure应用程序服务托管我的web应用程序时使用部署槽的情况。我特别困惑于在执行交换时处理数据库的理想方法。虽然维护两个数据库版本似乎是一种解决方案，但它增加了跨多个数据库维护数据的复杂性，以使它们保持一致。在使用蓝色/绿色部署(尤其是部署槽(时，建议使用哪些方法来处理数据库架构和迁移？
理想情况下，您将暂存/生产共享相同的数据库，因此这不会成为问题。
但是，如果您有更多的插槽，那么您最好也使用不同的数据库，并在发布阶段处理迁移
几年来，我们一直在研究这个问题的各种解决方案。没有一个工具集能为所有情况提供神奇的子弹头。有几个解决方案：
较小的数据库/琐碎的更改
如果可以在一两秒钟内完成的数据库上执行迁移脚本，并且可以有一个简单的回退脚本，则可以在交换的同时执行该脚本。这也可以是自动化的。但这是一种压力更大的情况，我不建议这样做。这甚至可以通过EF迁移来完成。
小心确保版本之间的数据库兼容性
由于我们要处理的是几百GB的数据，这些数据无法下降，所以我们只是制定了一条规则，即数据库必须与两个版本的应用程序一起使用。这并不像听起来那么可怕或不可能。例如，经常可以在执行交换之前添加净新表和字段。作为QA的一部分，我们测试版本之间的回滚。如果需要删除某些字段，我们会等到新版本部署并烧录后，然后在确定不需要回滚后运行另一个脚本来执行删除。当需要升级存储过程时，我们将创建新的存储过程，以便新版本拥有自己的存储过程。示例：sp_foo和sp_foo2。
我们在这个策略上取得了很大成功。
插槽是专门为应用程序服务而非数据库提供的功能，如果您想将特定的数据库与特定的插槽一起使用，则可以这样设置插槽：https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
现在，当使用插槽和交换时，它还交换应用程序配置\设置，在应用程序设置中，您可以有两个DB连接字符串，但每个字符串都启用了自己的插槽名称和设置。您可以在这里的示例中看到它：https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-两个插槽