我们公司的网站将很快托管在Azure的应用程序服务中。该网站与同样托管在Azure中的API层通信，并链接到我们的内部系统和数据库。这个级别的架构此时无法更改，并且有相当多的背景历史等。
我们正在考虑使用Azure中的应用程序服务中的部署槽来实现始终在线部署。API层将对每个部署进行不间断的更改，部署API将是任何版本的第一部分，网站如下。
Is在我们的环境之间有明确的分离，在生产部署开始之前，该版本将在开发、测试和预生产环境中进行测试。总的来说，整个过程相当简单，直到实现后(PI(测试，这在我们公司是强制性的。
我们需要能够在客户使用该网站之前测试生产部署。目前，我们的功能是将网站切换到维护模式，除非从选定的IP地址列表中访问。我们现在需要在新版本的网站上执行PI测试，同时客户继续使用旧版本的网站。我不确定实现这一目标的最佳方式。
我有一个想法，那就是创建一个子域，绕过部署槽设置，直接链接到网站_stage部署槽。反过来，这里的一些逻辑可以直接进入API _stage部署槽。这将使您可以在单击"交换"按钮交换部署插槽之前选择后实施更改。
我知道整个过程并不理想，但目前这一点无法改变。有人对以上内容有什么想法或其他建议吗？
Azure使为应用服务创建部署槽变得容易。它可在标准或高级应用程序服务计划模式下使用。部署槽实际上是具有自己主机名的实时应用程序。应用程序内容和配置元素可以在两个部署槽(包括生产槽(之间交换。
Azure客户可以轻松执行以下步骤-将web应用程序部署到联机部署槽。-在潜在测试人员将要使用的实时环境中，在部署槽上运行测试。测试环境和生产环境并行存在，提供了相似的环境。-执行两个插槽的IP地址的内部交换(通过两个节点的负载平衡和流量管理--插槽(-在零停机的情况下更新应用程序-立即切换回以前版本的应用程序，用户无需停机。
参考文献https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
启用部署插槽的总体原因是，它可以帮助您的团队在生产环境上运行实时测试，如果生产插槽出现一些问题，它可以让您回滚交换，而无需将应用程序停机进行维护。