Using TeamCity for Website Deployment
After a hardware upgrade I decided to switch from CruiseControl.NET to TeamCity for my personal continuous integration server to see for myself how they compare. Since I don't have all that many active projects, the free Professional Server License is a great option to try out all of the features without paying for it. At the same time it should give me enough insight to see whether it has enough advantages over free alternative(s) for the investment to make sense in a larger environment.
It's no surprise that TeamCity beats CruiseControl.NET in its overall polish and basic user experience. Nevertheless, I stumbled upon a supposedly missing feature in TeamCity already with my first build configuration. Admittedly, it wasn't a real build I was trying to configure; instead I was trying to recreate the automatic deployment of a couple of web sites, I'm maintaining.
Reading the documentation I soon learned more about artifacts as final results of a build configuration, ready for deployment. Unfortunately they can only be published within TeamCity, available for later deployment, while my only requirement was to have these files deployed to the server via FTP or (in one case) over a file share. Since artifacts of one build configuration can be used from another build configuration, I guess I could chain two build configurations, having the first one prepare the artifacts and the second one deploy them to the server, but it seemed too complicated a solution for my simple scenario. Also, I don't really need these artifacts available from TeamCity for older builds, nor did I like the idea of spending two build configurations for a simple auto deployment of a single website.
I was already considering writing a deployment script and running it from TeamCity when I finally found the Deployer plugin. Although it's still in alpha, I decided to give it a try. Being used to CruiseControl.NET I was pleasantly surprised by the quick and simple plugin installation process in TeamCity. It couldn't get much better than that.
Configuring the build runners from the plugin soon showed why they are still in alpha. Using the artifact syntax to define the files for deployment was a nice touch taking advantage of what I already learned, but there were still a couple of limitations I noticed:
- SMB Deployer for some reason doesn't like dots in the UNC path set for the target URL, forcing me to rename the folder on the web server and reconfigure IIS accordingly.
- A bigger issue is the complete lack of support for incremental deployment, copying or uploading only files that are newer than the ones already deployed. For larger sites on a remote server this unnecessarily prolongs the build time.
Anyway, the solution is still good enough for me and I'm sticking with TeamCity for the time being, continuing my quest to learn more about it and convince myself it really is superior to CruiseControl.NET.
