Wednesday, December 15, 2010

You're deploying it wrong! TeamCity, Subversion & Web Deploy part 4: Continuous builds with TeamCity

Over the last three posts in this series, we got to the point where all the Microsoft bits are working really nicely together. Config transforms, packaging and Web Deploy are great stable mates in the world of web application deployment.

The bit that’s missing though is automation. Actually there are several bits missing but automation is the common solution. Deployment by developers directly from Visual Studio or command line with MSDeploy works fine most of the time but has a few flaws we’re simply not going to be able to overcome without a build and deployment server. In all likelihood, your existing release process looks something like this:

normal-dev-process2.png?imgmax=800

The problems with this are numerous:
  • Access rights – you’re giving the developer too much if they can directly invoke Web Deploy either with their own credentials or other credentials they know. They will bend to temptation and circumvent release procedures, even though it’s normally well intentioned (just had to turn off custom errors for a moment…).
  • Auditability – well, you’ve got none. You have no way of automatically capturing when, what and who. You could have a dozen releases in a day and be none the wiser because if it’s not automated, the information is inevitably not recorded or done so poorly.
  • Rollback – you know how rollback is most commonly done? Copy the target folder and rename it “old_MyWebApp”, publish the new app then if it breaks, copy the old files back over. I’d bet my bottom dollar that in lieu of a build and deploy environment, this is your rollback strategy. Either that or pulling a previous revision from VCS and repeating a manual deploy which can be both time consuming and error prone.
  • Version control – if you’re not deploying directly from your VCS, what confidence do you have that released source code is retrievable or reproducible? You’re (hopefully) not publishing all your source code to the target environment so short of some emergency reverse engineering, a developer could easily release code you’re never going to be able to reproduce.
I’m sure there are other good reasons but that’s a good kick-off for the moment.

Read more: Troy Hunt's Blog

Posted via email from .NET Info