具有实施后测试的 Azure 部署槽

Question

我们公司的网站很快将托管在 Azure 的应用服务中。该网站与同样托管在 Azure 中的 API 层进行通信，并链接到我们的内部系统和数据库。这个级别的架构此时无法更改，并且有相当多的背景历史等。

我们正在考虑在 Azure 的应用服务中使用部署槽实现始终在部署上。 API 层将针对每个部署进行非重大更改，部署 API 将是任何版本的第一部分，随后是网站。

我们的环境之间有明确的区分，并且在生产部署开始之前，将在开发、测试和预生产环境中测试该版本。总体而言，整个过程相当简单，直到涉及实施后 (PI) 测试，目前这在我们公司是强制性的。

我们需要能够在客户使用网站之前测试生产部署。目前，我们将站点切换到维护模式，除非它是从选定的 IP 地址列表中访问的。我们现在需要在新版本的站点上执行 PI 测试，而客户继续使用旧版本的站点。我不确定实现这一目标的最佳方法。

我确实有一个想法是有一个子域直接链接到网站 _staging 部署槽绕过部署槽设置。反过来，这里的一些逻辑可以直接进入 API _staging 部署槽。这将提供在单击“交换”按钮以交换部署槽之前发布实施更改的选项。

我知道整个过程并不理想，但目前无法更改。请问有人对上述内容有任何想法或其他建议吗？

Answer 1

Azure 可以轻松地为应用服务创建部署槽。它在标准或高级应用服务计划模式下可用。部署槽实际上是具有自己主机名的实时应用程序。应用内容和配置元素可以在两个部署槽之间交换，包括生产槽。

Azure 客户可以轻松执行以下步骤 - 将 Web 应用程序部署到在线部署槽。 - 在潜在测试人员将要使用的实时环境中，在部署槽上运行测试。测试环境和生产环境并存，提供相似的环境。 - 执行两个插槽的 IP 地址的内部交换（通过两个节点的负载平衡和流量管理 - 插槽） - 以零停机时间更新应用程序 - 立即切换回应用程序的先前版本，用户停机时间为零。

参考资料 https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots

启用部署槽的总体原因是它可以帮助您的团队在生产环境中运行实时测试，并且如果生产槽出现一些问题，它可以让您回滚交换，而不必采取您的应用程序停止维护。