Azure Web Role configuration settings across environments

Question

Releasing before Azure:

Before using Azure, we would just have read-only config files sitting in the different environments (test, staging and production, etc.). During a release, all application files (no config files) would be deployed to the environment in question. The application files would then read the environment's config file for connection strings and other environment-specific details. I assume that this is a pretty standard setup?

Releasing after Azure:

Now we are moving our web applications to Azure Web Roles. Web Roles use ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg files.

When publishing to a cloud service, the connection strings need to be known. If we want to publish to a Test cloud service, then ServiceConfiguration.Cloud.cscfg needs to be edited accordingly. If we want to publish to a Staging or Production cloud service, then ServiceConfiguration.Cloud.cscfg needs to be changed further.

I would much prefer to abstract the developers AWAY from connection strings when they do their deployments. This prevents the mistake of pointing to incorrect environments (which could have huge implications). How can this be done?

I understand that these config settings can be changed in the Azure Management Portal, but to include this step into the release process would mean that developers would need to have access to the Management Portal, which is not an ideal situation as there is still margin for error (plus 'open' access to Management Portal).

Update:

I found that you can manage your service configuration files by adding more (and renaming):

And then by choosing the correct cloud service (black) and the correct service configuration (red arrow) together, developers wont need to be aware of config details:

There is still the problem of a developer choosing the wrong service configuration when deploying to a cloud service (but perhaps this could be automated into a script to prevent this?)

My main irk is the Environment type (blue arrow). This is of no use to me now.

Answer 1

You're best bet is to create multiple Cloud Deployment Projects, one for each environment so that each of them has a different ServiceConfiguration.

In my application, I have 3 application projects (1 WebRole and 2 Worker Role)

We then have 6 Cloud Deployment projects, one for each target environment. Each deployment project contains the same Web Role & Worker Roles, but has a different cscfg & csdef file.

At an application level, app.config & web.config files are handled through Configuration Transforms using SlowCheetah. Basically you have a different build configuration in the configuration manager for each deployment. so instead of just Debug and Release, I have Debug, QA, Uat, Test, SAndbox, Production