我目前在Microsoft Azure中实施了一个Web应用程序。我关心的是如何与ACS一起使用临时插槽。在Azure Staging插槽中使用ACS
我想推送我的应用程序到临时插槽，验证它正在工作，然后执行VIP交换到生产。
该方法非常简单，除了ACS的配置。由于临时插槽在部署过程中会获得一个随机URL，因此需要在之后完成ACS配置。 ACS中的WebRole的web.config和依赖方应用程序必须使用新的分段插槽URL进行配置。
维托里奥Bertocchi描述了他如何blog post不必重新部署更新的web.config和我想的是，ACS可以与部署到升级后的脚本进行更新。
这种方法看起来相当复杂和脆弱;我正在为我的部署过程寻找一个简单而稳固的解决方案。有什么我错过了吗？
由于ACS配置在生产槽中非常简单直接，我一直在考虑跳过应用程序在临时槽中的测试，只用它来执行VIP交换到生产（应用程序将是在自己的“质量保证”托管服务中进行测试）。
您对这种方法有什么看法？ Azure中的托管服务可以有任何区别吗？
也许您的应用程序可能会在重定向到ACS时以编程方式设置返回URL。这将在用户认证之后将其重定向到分段插槽或生产插槽。
这个问题向您介绍如何设置的境界，但返回URL只是另一个参数：WIF cross-domain on one IIS site, dynamically setting of realm
我解决了这个通过创建一个名为“测试”一个新的云服务。所以，当我将应用程序推送到临时插槽时，我还将另一个实例（使用不同的web.config）推送到“测试”服务的生产插槽。如果“测试”应用程序正常工作，那么我删除测试应用程序并交换我的生产临时插槽。
这不是理想的解决方案，但它可能会解决您的问题。
我只是使用主机文件条目来测试登台实例。例如，让我们说你的服务托管在myservice.cloudapp.net。你的staging插槽通常会得到像[guid] .cloudapp.net这样的URL，但它也会得到一个公共VIP（你可以从服务的仪表板或者通过执行nslookup [guid] .cloudapp.net获取这个URL）。您可以将主机文件条目添加为“[Public VIP] myservice.cloudapp.net”。一旦你这样做了，你可以通过使用myservice.cloudapp.net和ACS配置来改变你的登台实例。