我目前正在 Microsoft Azure 中实现一个 Web 应用程序。我关心的是如何将分段插槽与 ACS 一起使用。
我想将我的应用程序推送到暂存槽，验证它是否正常工作，然后进行 VIP 交换到生产。
该方法非常简单，除了 ACS 的配置。由于暂存槽在部署期间会获得一个随机 URL，因此之后需要进行 ACS 配置。ACS 中的 WebRole 的 web.config 和依赖方应用程序必须使用新的暂存槽 URL 进行配置。
Vittorio Bertocchi 在他的博客文章中描述了如何在不重新部署的情况下更新 web.config，我猜想在部署到登台后可以使用脚本更新 ACS。
这种方法看起来相当复杂和脆弱；我正在为我的部署过程寻找一个简单而可靠的解决方案。有什么我错过的吗？
由于 ACS 配置在生产槽中非常简单直接，我一直在考虑跳过暂存槽中的应用程序测试，只使用它来执行 VIP 交换到生产（应用程序将在自己的测试“QA”托管服务）。
您如何看待这种方法？Azure 中的托管服务之间是否存在任何差异？
我只是使用主机文件条目来测试登台实例。例如，假设您的服务托管在 myservice.cloudapp.net 中。您的登台槽通常会获得一个类似 [guid].cloudapp.net 的 url，但它也会获得一个公共 VIP（您可以从服务的仪表板或通过执行 nslookup [guid].cloudapp.net 获得）。您可以将主机文件条目添加为“[Public VIP] myservice.cloudapp.net”。完成此操作后，您只需使用 myservice.cloudapp.net 即可暂存实例，并且无需更改 ACS 配置。
也许您的应用程序可以在重定向到 ACS 时以编程方式设置返回 URL。这将在用户进行身份验证后将用户重定向到暂存槽或生产槽。
这个问题告诉你如何设置领域，但返回 URL 只是另一个参数：WIF cross-domain on one IIS site, dynamic setting of realm
我通过创建一个名为“test”的新云服务解决了这个问题。因此，当我将应用程序推送到暂存槽时，我还将另一个实例（具有不同的 web.config）推送到我的“测试”服务的生产槽。如果“测试”应用程序正常工作，那么我删除测试应用程序并交换我的生产暂存槽。
这不是理想的解决方案，但它可能会解决您的问题。