我们的公司网站很快将托管在Azure中的应用程序服务中。该网站与同样托管在Azure中的API层进行通信，并链接到我们的内部系统和数据库。该级别的架构目前无法更改，并且具有相当多的背景历史记录等。
我们正在考虑使用Azure中的App Service中的部署槽始终在部署上实施。该API层将对每个部署进行不间断的更改，并且将在所有版本的第一部分中部署API，并紧随其后的网站。
我们的环境之间存在明显的区别，该版本将在生产部署开始之前在Dev，Test和Pre-Prod环境中进行测试。总体而言，整个过程相当简单，直到进行实施后（PI）测试为止，目前这在我们公司中是必需的。
我们需要能够在客户使用站点之前测试生产部署。当前，除非从选择的IP地址列表访问网站，否则我们将网站切换为维护模式。现在，我们需要在客户继续使用旧版本的站点的同时，在新版本的站点上执行PI测试。我不确定实现这一目标的最佳方法。
我的一个想法是拥有一个子域，该子域可以直接链接到网站_staging部署槽，而绕过部署槽设置。反过来，这里的某些逻辑可以直接转到API _staging部署插槽。这样一来，您就可以选择在单击“交换”按钮交换部署插槽之前发布实施更改。
我知道整个过程并不理想，但是目前无法更改。是否有人对以上内容有任何想法或其他建议？
答案 0 :(得分：0)
Azure可以轻松为App Services创建部署插槽。在标准或高级应用服务计划模式下可用。部署槽实际上是具有自己的主机名的实时应用程序。应用程序内容和配置元素可以在两个部署槽（包括生产槽）之间交换。
Azure客户可以轻松执行以下步骤 -将Web应用程序部署到在线部署槽。 -在潜在测试人员将要使用的实时环境中的部署插槽上运行测试。测试环境与生产环境并存，并提供相似的环境。 -对两个插槽的IP地址进行内部交换（通过两个节点-插槽的负载平衡和流量管理） -零停机时间更新应用程序 -立即切换回您的应用的先前版本，用户的停机时间为零。
参考 https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots
启用部署插槽的总体原因是，它可以帮助您的团队在生产环境中运行实时测试，并且如果生产插槽中存在一些问题，它可以使您回滚交换而不必花费您的时间申请下来进行维护。