Web.config transformations have been around for a while now, and a lot of developers use them in their staple day-to-day environment deployment strategies – hell, Scott Hanselman was spouting about them way back in the beginning on 2010 with his “Web Deployment Made Awesome: If you’re using XCOPY, you’re doing it wrong” post. As usual though, one size does not fit all – and in the case of Continuous Integration fans out there that may have specific build-configuration-based build and deployment scenarios (such as myself), there is the need to have finer grained control over the Web.config transformation process. If this sounds like you, then this post is aimed to deliver.

Last week i had the awesome honour of being at a tech talk on Continuous Delivery by “the great” Martin Fowler, Neal Ford and Evan Bottcher, put on by Thoughtworks here in Sydney. I have spent the last two years of my life evangelizing on the benefits of Continuous Integration and Continuous Deployment to anyone who would hear me all on my own terms and entirely self taught in the dark. I have selected snippets and ideas from other peoples documented ways on how they achieve Continuous Deployment, but the experience of listening to pioneers in this space was a truly awesome experience.

Test Driven Development, Behaviour Driven Development, Extreme Programming and many other new-age hippy development methodologies have spread through the development world like wild fire. I believe there is room for one more in the shape of Build Driven Deployment/Automated Deployment - A new source of confidence in the development world. Time to go out and spread the word.

Deploying in an automated fashion using Continuous Integration doesn’t happen instantly, and depending on the size of your application, your continuous integration deployment can get caught in a state of unknown/in-between if a user visits your application half way through deployment. This can be far from optimal, but ASP.Net has a trick up it’s sleave in the form of the App_offline.htm file.

Having a good Continuous Integration setup can be one of the highlights of any developers daily grind. Regardless, it can be seen as almost pointless if your automated deployment setup still needs a physical person to upload the files to your server if it is offsite. Adding FTP/SFTP to your CI process is the solution to this.

One of the continually high risk and sometimes fiddly operations in web deployment is a web application’s deployment, and yet a lot of people working in smaller teams seem to have become stuck in the land of cowboys because the task of automated deployments seems either too difficult, too time consuming to setup or is perceived as un-needed. I’m about to attempt to prove all of these things wrong, while at the same time allowing you to get back to doing what you do best: write code.