Just Deploy Something
Ok, so I need a better deployment story – for it to work well for me it needs to be driven from my Continuous Integration server – the very wonderful TeamCity from JetBrains. But before I get there (the reason for writing all these words) I need to think about the actual deployment process.
It turns out that Microsoft have made it very very easy to do one-click deplyoment from Visual Studio and in a better/nicer way than just FTP. If you set up (or have set up) MSDeploy/Webdeploy at both ends i.e. on your dev box and on your server then a very small amount of configuration goes a surprisingly long way…
I ought to have pictures here!
Running IIS7 with WebDeploy installed I can export a Publish Settings file which when splatted into the appropriate boxes in the Publish Profile dialog causes magic to happen. The magic in this case being to push the defined/required content for your web application to the server (and potentially to delete any spurious files that are still on the server so you may need to exercise caution).
This is great, load up visual studio, push a button and it compiles and builds and gets deployed to the server… great!
The are two problems here first is configuration – and that’s trivially dealt with – the second is that way before we got to “if you’re using xcopy you’re doing it wrong” I (and more than a few others) had worked out that if you’re deploying from Visual Studio you’re doing it wrong.
This bears a bit of review – what you’re aiming for is a high level of confidence that you can build and deploy your application to order. In practical terms this means you need to be able to do a build and your application from a clean checkout from source control ideally on a minimally configured box (i.e. not your dev box). Further you want to create from this build something you can deploy.
The first bit you do by having a proper CI server set up so that you know when you commit that what has been committed will build. (If you’re good you also know that it has passed a whole pile of unit type tests too and, if you’re really good, that a scheduled overnight build has run a pile or repeatable integration type tests.) The second bit I currently do (courtesy of former colleague) is post build to have all the needed files packaged into a zip file that I can copy to the server (which is interesting for reasons we’ll come to in a minute) and from which I can to do an xcopy to my site directories (test and live) meaning that I have the same thing in multiple places.
One of the nice things you can do is autmagically assign assembly version numbers as part of the build process – so mine are 1.0.{revision}.{build number} where the build number comes from team city (its simply a count of how many times a build configuration has been triggered). Given this I can know how to get to the source for a given deployment and have some confidence that I’m dealing with the same version of the code across the board if investigating discrepancies between Test and Live.
This brings up another reason why deploying from Visual Studio is a problem – you want nice incrementing version numbers to go with your (deployed) builds. Whilst there is support for this built in its a bit hairy with multiple developers building and committing – and doing it by hand it just another opportunity to forget a step. The version number for anything I build locally is 1.0.0.0 (or similar its the trailing .0.0 that’s significant). So deploy from Visual Studio is very nice… but it ain’t right!
A few paragraphs ago I said that configuration was trivially dealt with, well maybe not entirely trivial but Visual Studio 2010 (more accurately MS Build) introduced Config Transforms that let you vary your web.config (and other config files if you bing enough) according to your build configuration (e.g. Debug, Test, Release). Transforms are applied as part of the deployment process.
Ok, at this point I’ve meandered around a bit – lets try and get back on track…
I have a web application, I have a server upon which I wish to deploy that application, I can easily set up visual studio to publish to that server using Web Deploy in the process of that deployment I can make changes to my web.config to change application settings and connection settings by using config transformations. Nice, but not ideal – not least because you want to be certain that the code you deploy is the code that is safely committed to your version control system.
Fortunately Microsoft have you covered! Right about the publish option on the context menu for the application is another option:
Build Deployment Package – what this does is, erm, build a deployment package – a what? – A deployment allpackage is a zip file containing your site and some other things that you can copy to your server and with a right click in IIS you can import the contents into a website – its not unlike the .zip file that I mentioned earlier that I currently use excepting that its considerable smarter.
What gets even more interesting is that when this file is built Visual Studio doesn’t just output the package it also creates a few more fun things:
Packaging into C:\Dev\ComoStreet\StopMailSender\StopSaleMailer\obj\Test\Package\StopSaleMailer.zip.
Package "StopSaleMailer.zip" is successfully created as single file at the following location:
file:///C:/Dev/ComoStreet/StopMailSender/StopSaleMailer/obj/Test/Package
To get the instructions on how to deploy the web package please visit the following link:
http://go.microsoft.com/fwlink/?LinkId=124618
Sample script for deploying this package is generated at the following location:
C:\Dev\ComoStreet\StopMailSender\StopSaleMailer\obj\Test\Package\StopSaleMailer.deploy.cmd
For this sample script, you can change the deploy parameters by changing the following file:
C:\Dev\ComoStreet\StopMailSender\StopSaleMailer\obj\Test\Package\StopSaleMailer.SetParameters.xml
A .cmd that will allow you to deploy this thing automagically (outside of visual studio) and a parameters that will allow you to twiddle some things when you do.
At this point its important to remember that Visual Studio doesn’t actually build things itself, it uses MS Build or other things plugged in… so if I can build a package within Visual Studio it stands to reason that I can do so outside of visual studio…
At this point I need to actually work out the next step for myself so I shall publish this and start on the next post
Comments