Azure cloud service project configuration (.csdef and .cscfg) in multiple environments

Question

Currently we have a development cloud services (acme-dev-service) and a production cloud service (acme-prod-service). Our current setup in our solution has a cloud service project called acme.application that uses transformation of the .cscfg and .csdef files for deploying the project to the two environments (production and development). I don’t like the transformation method because it feels like a bit of a hack to me. So after doing some research it seems that you can have multiple configuration files which solves some of the issue but I am running into problems because you are only allowed one service definition. This doesn’t work for us because the production environment requires extra certificates as well as different hostHeader bindings than our dev environment does.

So it seems we cant really get away from using the transformations. So I guess my question boils down to am I looking at the Azure Service Project files in the wrong light? Should we really be mapping one Azure Project to one Azure cloud service? Should I have an Azure project for Production and a second Azure Project for Development? Is there a better way to do this? Or a best practice for working with multiple environments in Azure?

Sudden

Answer 1

The CSDefinition file is the real kicker here. If you have a value you need to be different between two environments (dev/test/stage/production, etc.) then you really have three options:

1) Manually modify the value before a deployment. Errr....Okay....you have two options.

1) Tap into the MS Build process and determine which cloud configuration you have selected (the one used to determine which version of the .cscfg file will be used) and then have the build modify the .csdef after the build and prior to packaging (there is a time when the file has been copied to a different directory just before packaging and this is where you want to make the change). This can be tricky, though I've seen it done and have even done so myself in the early SDK days. Here is a blog post explaining one example where he's using WebConfigTransformRunner to do just that: http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/. I don't really think this is your best option because it is opaque. It's not evident what is going on and someone who comes along after you to maintain the code will not know about this little gem and will spend forever trying to figure out why some value they put into the csdef somewhere is somehow getting overwritten after they publish to a different environment.

2) Use the two Azure Project approach you mentioned. You can set up build definitions in your Build tool of choice that determine which of the Azure projects you want to build and publish. Personally I think this is the best way to deal with different .csdef files. It's straight forward and doesn't require modifying the csproj files. I'm not opposed to csproj file changing, it's just not overly obvious it was done and, speaking as someone who has inherited things like that, it's not easy to find when people do that kind of thing and they aren't around to tell you about it.

Rodrick

I know I'm late to the party here, but are you saying that there is no concept of UAT built into azure cloud services? We're expected to push straight to prod without getting product owners to check everything?! That's ludicrous, isn't it? – Butyrin

No, I'm not saying that at all. In fact, I agree with you that it would be a bad idea to not have testing and multiple environments. I'm saying that without a little work the csdef file is the one you'll have issues with and will have to take additional steps in order to make it mutli-environment. But what's in the csdef may not even need to be modifier per environment. Most connection strings and such are in csconfig. Machine size is in csdef which is the most common I've seen that needs to be different. – Rodrick

Yeah I get that. It just feels like hard work to achieve something that should really be provided 'out of the box' by the azure team, imho. – Butyrin