我们公司的网站将很快被托管在 Azure 的 App 服务中。 网站与同样托管在Azure中的API层进行通信，并链接到我们的内部系统和数据库。 这个层面的架构目前还不能改变，而且有不少背景历史等。
我们正在考虑使用Azure中的App服务中的部署槽来实现始终在部署。 API层将对每个部署有非突破性的变化，部署API将是任何版本的第一部分，网站将跟随。
是在我们的环境之间有一个明确的分离，在生产部署开始之前，该版本将在Dev、Test和Pre-Prod环境中进行测试。 总的来说，整个过程是相当简单的，直到它涉及到实施后（PI）测试，目前这是我们公司的强制性。
我们需要能够在客户使用网站之前测试生产部署。 目前，我们的功能是将网站切换到维护模式，除非它是从一个选定的IP地址列表中访问。我们现在需要在新版本的网站上进行PI测试，同时客户继续使用旧版本的网站。 我不确定实现这一目标的最佳方式。
我有一个想法是有一个子域名，直接链接到网站_staging部署槽绕过部署槽设置。 反过来这里的一些逻辑可以直接进入API_staging部署槽。 这样就可以在点击'交换'按钮换过部署槽之前，就可以选择发布实现改变。
我知道整体流程并不理想，但目前这个无法改变。 请问大家对以上问题有什么想法或其他建议吗？
Azure 使得为 App 服务创建部署槽变得容易。它在标准或高级 App 服务计划模式下可用。部署槽实际上是具有自己主机名的实时应用程序。App 内容和配置元素可以在两个部署槽之间进行交换，包括生产槽。
Azure 客户可以轻松执行以下步骤-将 Web 应用程序部署到在线部署槽.-在部署槽上运行测试，在潜在测试人员将要使用的实时环境中。测试环境和生产环境并排存在，并提供类似的环境.-对两个插槽的IP地址进行内部交换（通过对两个节点-插槽的负载均衡和流量管理）-以零停机时间更新应用程序-即时交换回应用程序的以前版本，用户的停机时间为零。
参考文献https:/docs.microsoft.comen-usazureapp-servicedeploy-staging-slots。
总的来说，启用部署槽的原因是，它可以帮助你的团队在生产环境上运行实时测试，万一生产槽上出现一些问题，它可以让你回滚交换，而不必将你的应用程序关闭维护。