Extending MSDeploy beyond the Web

A few months ago I mentioned a bug we found in MSDeploy v3 around the CommandTimeout attribute and a workaround to avoid it.  I honestly think we may have been the first developers to find it because very few know how powerful MSDeploy.exe really is and use it beyond its more popular wrapper WebDeploy.

It was a dark time …

Several years ago we were struggling with our mostly-manual deployment process. We rarely had a smooth deployment because there were simply too many opportunities for people to make mistakes.  The development teams would write deployment scripts in Word and our ALM team would follow the pages of scripts to execute the deployment.  As you can imagine this was VERY painful!  As a result we would defer deployments as long as possible which as CD (rightly) tells us, just makes it worse.  We had to bring this pain forward and alleviate it to be successful.

A little better.

We finally decided to start using WebDeploy for web site/application deployments.  The technology was the logical choice as it was built into Visual Studio, there were many examples on how to use it and it was supported in TFS as well.  This probably accounted for 40% of our deployments and worked great.  The other 60% were a bunch of Windows Services, scheduled tasks and SQL database deployments.  WebDeploy did support adding database deployments but it had limited functionality.

I found some posts that explained a little about WebDeploy and how most of the guts were really in MSDeploy.  So we started digging in to learn more.  We found that WebDeploy is really just a set of MSBuild scripts (Microsoft.Web.Publishing.targets) and a few UI extensions in Visual Studio but behind the scenes MSDeploy was doing the heavy lifting.

 

 

We can do that too!

Given this information we started questioning whether we could create a similar approach for all our other types of deployments.  In the end we created our own MSBuild scripts to mimic WebDeploy by wrapping MSDeploy for SQL deployments and everything else.  We packaged the scripts into two Nuget packages: SqlDeploy and AppDeploy.  Nuget offered a distribution mechanism and versioning.

 

 

MSDeploy provided some key benefits that make it the ideal deployment solution if your on the Microsoft stack (maybe even if your not):

• Deployment Packages – The ability to combine multiple  components together into a single zipped deployment package. 
• Many providers – Support for all kinds of changes in Windows (IIS, certificates, COM, GAC, Registry, to name a few).  Full list at Web Deploy Providers.
• Command line tool – Command line tools can be used in all deployment orchestration tools.
• Extensibility – You can even build your own providers if your so inclined.  We haven’t had the need yet but its nice to know its there.
• Parameterization – Performs transformation of files within the deployment package and the package itself at deploy time.  This means you can build once and deploy the same binaries to any environment.  It replace config transforms and does so much more! See Web Deploy Parameterization.

We can achieve CD in .NET too!

Too many .NET developers think the implementation of deployment automation is unachievable with the tools available.  Most of the blog posts out there use a for pay product or open source solution outside of the Microsoft stack.  I’m sure those work well but paying additional licensing fees and getting approval to use Ruby can be an uphill battles.  I think MSDeploy is the key to introducing a better deployment process for a Microsoft shop.

We have been using/improving these Nuget packages for 2+ years with great success.  We even have them plugged into our GO! deployment pipelines now and have achieved continuous delivery for most of our active products.

 

What do you think?  Leave a comment to start the discussion.