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.

Heliozoan

I'd have to check but I think this only allows you to chose the configuration and not the service definition. So you might run into issues if you want different endpoints (http vs. https), different Vm sizes or others between environments. The solution in my answer side steps this. – Gilbertgilberta

@Eoin: Oh yes, good point regarding the service definition. This would be a problem. Last question: Are you able to version control your code without having a "Deployment Package". Publishing straight from Visual Studio is a little scary as you won't know for sure if code has changed or not. – Heliozoan

Well in our case, are our source code is stored on GitHub which we use for source control, so we have our own processes in place to take a branch, lock down the release content, and then move on with development on Master. When it comes time to do a Production release, we just deploy from the branch we signed off on. – Gilbertgilberta

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

Gilbertgilberta

Thanks for the post. Having separate projects is definitely one solution. Please check my post for an update (another possible solution). Also what do you now do with the Production/Staging environments built into cloud services? – Heliozoan

Production vs. Staging is Azure's internal pre-production node, so you can leverage the VIP swapping option. however if you have completely different environments for each, you can probably just always deploy to the "Production" holder of your relevant environment. – Gilbertgilberta