0

我正在尝试了解使用 Azure 应用服务托管我的 Web 应用的部署槽的使用。我对执行交换时处理数据库的理想方法感到特别困惑。虽然维护两个数据库版本似乎是一种解决方案，但它增加了跨多个数据库维护数据以使它们保持一致的复杂性。在使用蓝/绿部署，特别是部署槽时，处理数据库架构和迁移的推荐方法是什么？

4

3 回答 3

1

几年来，我们已经通过各种解决方案来解决这个问题。没有一个工具集可以为所有情况提供灵丹妙药。有几个解决方案：

较小的数据库/琐碎的更改

如果可以在一两秒内完成的数据库上执行迁移脚本，并且您可以拥有一个简单的回退脚本，那么您可以与交换同时执行该脚本。这也可以自动化。但这是一种压力较大的情况，我不建议这样做。这甚至可以通过 EF 迁移来完成。

小心确保版本之间的数据库兼容性

由于我们正在处理数百 GB 的数据，这些数据不能下降，我们刚刚制定了一个规则，即数据库必须与我们的应用程序的两个版本一起工作。这并不像听起来那么可怕或不可能。例如，通常可以在执行交换之前添加净新表和字段。作为 QA 的一部分，我们测试版本之间的回滚。如果需要删除某些字段，我们会等到新版本部署并烧入后，然后在确定不需要回滚后运行另一个脚本来执行删除。当需要升级时，我们将创建新的存储过程，以便新版本拥有自己的存储过程。示例：sp_foo 和 sp_foo2。

我们在这个策略上取得了很大的成功。

于 2020-08-20T15:31:38.763 回答
1

理想情况下，您将分阶段/生产将共享相同的数据库，因此这不是问题。

但是如果你有更多的插槽，那么你最好也使用不同的数据库并在发布阶段处理迁移

于 2020-08-20T12:53:00.757 回答
0

插槽是专门针对应用服务而不是数据库的功能，如果您想使用具有特定插槽的特定数据库，那么您可以像这样设置插槽： https ://docs.microsoft.com/en-us/azure/app -service/deploy-staging-slots

现在，当使用 Slots 并交换它时，它还会交换 App Configurations\Settings，并且在 App Settings 中，您可以有两个 DB 连接字符串，但每个字符串都有自己的插槽名称和启用设置。您也可以在此示例中看到它：https ://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-two-slots

于 2020-08-20T14:33:41.683 回答