Azure部署插槽和数据库迁移

TLDR：

在暂存槽中运行的应用程序如何知道它正在暂存并连接到测试数据库/在测试数据库上运行迁移？ 而且，暂存槽中的同一个应用程序如何自动意识到它已被切换到实时生产槽，并且现在负责实时业务操作？（因此可以切换到使用live db、迁移live db等）

长版本：

这个问题部分涉及了这个主题：

但我并没有真正得到答案

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

似乎最明智的做法是：

• production具有基于插槽的应用程序设置，该设置将代码指向production db
• staging具有基于插槽的应用程序设置，该设置将代码指向staging db

我看不到任何其他方法可以让生产在登台验证期间保持功能，如果登台的迁移破坏了数据库以供生产理解；两个DBs必须分开

因此，如果DBs是分开的，那么切换到使用暂存槽中的代码的唯一（几乎）零停机时间方式肯定是，如果切换导致应用程序重新初始化自身并更改它，使其指向生产数据库，那么fluentmigrator（也应再次调用）可以将同一组迁移应用于生产，并且暂存中的代码会在生产数据库上运行业务一段时间

..生产代码库已更新，并发生回拨。生产代码从不迁移生产数据库，因为在生产中启动新版本时，暂存代码已经更新了生产数据库

我预见事情发展的唯一其他方式是拥有两个DBs、两个插槽，而您永远不会执行交换；您只需部署到staging，它更新staging DB，您测试并证明良好，您部署到生产环境，它更新produtcion DB，您验证应用程序是否正常工作。。在prod构建过程中，世界经历了少量的宕机（如果构建失败，则会经历大量宕机）

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

---

如果后者是唯一的方法，那么部署槽也可能只是另一个web应用，对吗？一个用于登台的web应用程序和一个用于prod的web应用程序，以减轻由于它们在门户中的表示方式而引起的任何混乱。

我最近解决了一个类似的问题。我的情况更简单，因为我只部署到内容存储数据库，而数据收集工作则搁置一旁，不受影响（一旦我们必须升级它们，这将是一个挑战）

然而，我们提出了一个似乎是对我们最好的办法的解决办法。我们在弹性池中有两组dbs时进行插槽部署（这几乎不会给它们带来额外成本），而每个插槽指向一组dbs。 当我们进行部署时，我们会更新代码和与插槽相关的数据库，进行测试以验证所有功能是否正常，然后进行交换—代码和数据库。这意味着在交换之后，部署槽中的代码开始运行，它指向我们测试的dbs，而之前的活动代码和db集没有脱机，准备进行另一次部署

我们可以提供这种舒适感，因为dbs中的数据完全在我们的控制之下，因此我们可以防止在部署和交换之间写入db

但是，如果您的DB正在从Live应用程序收集数据，您可能会考虑在升级时将应用程序关闭，将您的实时数据合并到您的分级数据库中，升级您的分级数据库（已经包含最新数据），然后进行交换。在我看来，这是防止数据丢失的最安全的方法。您还可以先迁移staging db，然后关闭应用程序，并将数据合并到新模式中，具体取决于应用程序的特性，而不知道您的具体情况。在这里，给出一般建议相当复杂

---

希望这些想法至少能对您有所帮助，如果您已经找到了更好的方法，我很想听听。

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

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

允许此操作的一些规则：

• 新列应为空或设置了默认值
• 不能删除列
• 无法重命名列

当确实需要进行破坏性更改（例如删除列）时，需要有两个版本：

从web应用程序中删除依赖项的版本

对数据库架构执行更改的版本

---

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

在一天结束时，槽只是另一个web应用程序。您可以使用应用程序设置将db粘贴到特定插槽。但这并不能真正回答问题-虽然我知道插槽只是另一个web应用程序，与生产应用程序一起享受“单击以交换责任”的角色，我想知道，在存在数据库迁移的环境中，有哪些机制可以使它执行其预期的功能，我可以看到这是可行的，尽管根据db升级/部署策略，它可能会在与以前版本不兼容的意外更改方面存在风险