Windows Azure VIP Swap, how to handle custom web.config values?

Question

It's easy to publish a new deployment to a Cloud Service's Staging or Production environment, but I'd like to use the VIP Swap (swapping Production and Staging deployments) more often. In my case, I have different web.config values for each environment. For instance, on staging my web.config may have:

<appSettings>
    <add key="ConnectionStringName" value="StagingConnectionString" />
    <add key="WCFServiceUrl" value="http://somelongGUID.cloudapp.net/" />
</appSettings>

...and on Production, I would have:

<appSettings>
    <add key="ConnectionStringName" value="ProductionConnectionString" />
    <add key="WCFServiceUrl" value="http://prodservice.cloudapp.net/" />
</appSettings>

When publishing to Staging or Production, the web.config gets transformed using the correct values based on either Debug or Release. But when it comes to VIP Swap on the Windows Azure portal, I would have to trigger the swap, then remote into each instance and manually change those values (which is definitely not the proper way to do it).

What could be done to better handle this situation? Or is there a better and more flexible solution to handle those custom config values than to have them in web.config (especially in this case)?

Thanks in advance.

Answer 1

Using VIP swap is considered the "standard" way to promote staging to production in web and worker roles. It's achieves this swap by changing the Azure routing to point the "production" URL to the "staging" role instance and pointing the "staging" URL to the "production" role instance.

Internally, the roles aren't aware of this change: it happens entirely externally to the hosting process.

If you want to use VIP swaps in this way, you should consider changing your application to either be unaware of its host environment, or that it reads the information from its host whenever it needs to know it.

---

The way Production and Staging are arranged up in Azure, the packages should both be the same: both live configurations. The feature is intended for high-availability deployment; it doesn't cater for the kind of testing that would be implied by having the role call out to a different service depending on whether it's a staging deployment or not.

You'd be better using a separate role to perform tests against; staging should only be used to test that your deployment is successful before you make the switch with the current production deployment.