Using MSBuild to Automate One Click Publish

Why Automate Something so Simple?

Before we start, I suppose the first question someone would ask is “Why would I automate something that’s supposed to be just one click and done?”.  That’s a pretty good question and the answer is simple – rarely in “Real life” is a deployment to Production/Staging/wherever as simple as just one click – that is, unless it is automated.  Below I will document how One Click Publishing is most often used in a commercial environment.

  • Identify a bunch of projects that are to be published (possibly there will be lots of projects such as API’s, Web Projects, Scheduler service, Emailer Service, Conversion Tools, Migration Runners – the list goes on..)
  • Right click on every project you want to publish and click the publish button, then click the “Finish” button to start the publish process – This process might have to be repeated for each environment you wish to deploy to, e.g “Staging” might be published seperately from “Live” to handle things like Connection Strings.
  • Usually after that you will zip up the published project files and prefix them with a release version
  • Then when you’re ready to start the deployment process you might begin the process of transferring these files to your servers and installing them/getting them up and running.

Now, Ideally it would never be this time consuming and manual.  Ideally this would all be hooked up to some kind of release automation processes so all you would have to worry about is hitting a “Release” button.  But for a lot of smaller businesses out there they either don’t have the time or money to set up something like TeamCity or Visual Studio Team Services.  These people are stuck with using things like One Click Publish.

TLDR

Things to Note

So if you look at the package.bat you’ll see that we do the following:

  1. Nuget Restore so that the Build will pass
  2. Fully clean the Solution so that nothing can possibly go wrong during the publish.  There’s no need to rebuild here because when you publish each project in the below step it will do that for you.
  3. Package anything that needs to be packaged (like web files that go to IIS)
  4. Publish anything that is going to a setup file to be installed and started as a service
  5. Zip everything up using the PowerShell Script
  6. Lastly and very importantly, Increment the Publish version for everything that has been published.

These Scripts aren’t perfect – they can be improved a lot – but they work.  Running package-all.bat will package the two project I’ve got set in the script for Staging and Live (a total of 4 publishes), zip up the files and put them in a directory of my choosing.   In real life I have a total of 15 projects I would have to publish for 3 environments (totalling 45 unique “One Click” Publishes).  From this you start to understand the reason for automating and the time/effort that could be saved.

Leave a Reply