In years past building Visual Studio Extensions have often been considered the realm of the big boys. Staff working at Jetbrains or the Microsoft employees of the world. Last year I saw a talk given by Mads Kristensen aimed at taking away some of this stigma and showing how easy the guys at Microsoft have tried to make it for developers like you and me to just up and write extensions. I’ve been wanting to build one ever since, but haven’t had a good enough excuse to jump right in – until now. Here follows the creation of “OnCheckin Web.config Transformer”.

When configuring an Azure Virtual Network one of the most common things you'll want to do is setup a Point-to-Site VPN so that you can actually get to your servers to manage and maintain them. Azure Point-to-Site VPNs use client certificates to secure connections which can be quite complicated to configure so Microsoft has gone the extra mile to make it easy for you to configure and get setup – sadly at the cost of losing the ability to connect through the command line or through PowerShell – Let's change that.

Over the last few years we've seen a lot of blog posts floating around showing how to setup and deploy a website to Windows Azure. In my opinion they all cover the the "Azure 101" point of view and don't speak too much about migrating a website that already exists to Azure and some of the pains and gains experienced along the way. This post covers the migration of this very website to Azure websites and migration of my blogs database to SQL Azure.

New Relic's Deployment notes features have definitely been around for a while, but like a lot of things experienced by developers outside Microsoft's ecosystem, this is another service where we're a bit late to the party. The ability to track application performance against a certain release of your application is a great way to track the progress of any work your team has put in to improve your application's performance and visitor's overall experience. Implementing it is surprisingly simple which begs the question, if you're not doing it, why not?

Continuous Deployment is an time-saving, team-loving, kudos-earning, stress-reducing capability that any team is wise to implement. OnCheckin is definitely aiming to bring this awesome’ness to as many ASP.Net developers as possible by making it fast and easy to setup. Once you’ve started out automating deployment though iteration is the key. Deploying your website early and often is great but with OnCheckin this goes further – Add-ons. And where better to start than helping developers out than with an often overlooked part of web development: Application Security.

Constantly over the past few years I’ve thanked my lucky stars that I’ve had continuous integration and deployment setup for the web sites I’ve been working on. It is one of the few development opinions where I break the “religion and politics” laws of social etiquette. I feel incredibly strongly about the benefits that having a good Continuous Integration and Deployment story can bring to a project and it’s team. Sadly, not everyone has been able to experience the awesome sauce of CI/CD. I’ve been working hard to change that.

MS Deploy is such a powerful tool when used to keep your applications and services up to date. What is even more awesome is that the API for MS Deploy is available for you to write applications that utilise this power from within your own applications. As most people who’ve played with MS Deploy can report though, whether you’re using MSBUILD, PowerShell or the .Net API; The MS Deploy API sucks when it comes to simplicity. So after trial and error and much head banging I’ve created a wrapper for MS Deploy’s API to help you complete simple tasks with less friction.

Migrating to a Code-First or Model-First approach to database development can be very liberating. At the end of the day your database is just a way of storing state, so getting away from the implementation details can really help speed up development and allow you to focus your efforts. Code First’s awesomeness aside, when you try and implement this kind of paradigm shift within a team you unlock a different set of problems. Here are two potential ways to alleviate some of the headaches.

I’ve been a long time supporter of Visual Studio Web Deployment projects. Not because I built ASP.Net websites and wanted to compile them, but more because they held so much unadulterated power from the simplicity of just being an MSBUILD file inside your solution. With the launch of Visual Studio 2012 Microsoft has made the call to no longer support WDP moving forward. This made me sad; but I was just being naive. Visual Studio 2012’s Publishing profiles are even more powerful, and they bring all your old friends along for the ride.

Microsoft Web Deployment projects are an easy way to add a MSBUILD scripting to your Visual Studio web projects. I use them all the time for personal deployment projects and at work so do all my team members. With the upcoming release of Visual Studio 2012 there is currently no Web Deployment project type. Luckily there is something we can try and do about it – Let Microsoft know.

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.