Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Azure Web Role configuration settings across environments

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):

enter image description here

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:

enter image description here

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.

like image 698
Dave New Avatar asked Jul 03 '13 13:07

Dave New


1 Answers

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.

Solution Organisation

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

like image 58
Eoin Campbell Avatar answered Oct 14 '22 09:10

Eoin Campbell