What is the recommended approach for deploying to multiple Azure environments (dev, test, production)?

Question

I have an C# web application using mvc5. It currently runs on Azure and I have a dev, test, and production instances. What do I need to do to ensure that the database connection strings will automatically change as the application is pushed to each environment? I know this is possible with web.config as you can define Web.Debug.Config, etc, but how would I go about this for different worker roles on Azure? I have been all over the internet looking for a solution. In a nutshell, I would like to do the same approach used for the multiple web.config files but for Azure.

As some additional background, for my solution I have my repositorybase broken out into a separate project and there I am trying to grab the connection string from the configuration files (let's say domain.dll is the name of the library that contains it). As first this worked when I was only using web.config but when I had to run my domain DLL files from another worker role the configuration began to return null; because this code would not run when run from a different worker process(non web). This seems to introduce an interesting problem, what if I need to use the domain.dll code outside the web and outside of Azure? How do I still maintain the connection string benefits that Azure and web.config provide?

Answer 1

You should make the distinction between 'building in release mode' and 'deploying to environment X'.

Building in Release mode should just transform your configuration files to be 'production-ready'. With MsDeploy you can parameterize your configuration files so upon deployment they will be filled with the parameters as supplied by you to your MsDeploy script.

There is no magic bullet which will automatically change your connectionstrings etc per environment. But this way you can standardize your process which will greatly help with the stability of your product.

One thing to note is that the parameterization of your deployments will break the easy workflow 'publish' from within visual studio due to the fact that you are not given an option to fill in your parameters during the publish wizard... :'(

Answer 2

You should manage the connection strings through the azure portal rather than through config file transformations. With the MVC app this will be easy, go to the configure tab and set your connection strings there

For items like web jobs use Microsoft.WindowsAzure.ConfigurationManager which

provides a unified API to load configuration settings regardless of where the application is hosted - whether on-premises or in a Cloud Service

Answer 3

Assumption: you are using Web-Services, not Web-Sites. There is a difference.

There are 2 ways to get what you need:

1. For worker role you can do app.config transformations almost in the same way you do in web.config . Only you'll need to do it with SlowCheetah . There is a nuget package for that, also there is VS extension to create transform files. There is too much faffing-about with this method. I never liked it, so move on to second option.

2. If you run Web-Services, you can specify connection strings as part of worker-role configuration. Go to your Azure project and open properties of your worker-role:

There you can add database connection string. And create a configuration for every environment you run (dev, test, prod). And place a different connection string for every environment.

To get your connection string you execute:

CloudConfigurationManager.GetSetting("DatabaseConnectionString")

Once your site is deployed you'll see these configuration values in Configure tab in Azure Portal.