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