Automatic Deployment :: The final solution

In my previous post I lited tools used for automatic deployment. Although all of them have significant advantages, they did not fit for our needs. Or if they did, they seem to be too complex for such simple deployment process. So let's start with what we needed. We needed a script/tool that:

1. Downloads binaries 

2. Updates configuration files

3. Stops a windows service

4. Copies rellevant files 

5. Starts a windows service

6. Checks that the service is started and responding properly

7. Iterates the above steps for several servers in several data centers

One of the most important decisions we've made before and during the tools selection, was the following. Use the same deployment tool/script for deployment to test/staging environment as for production deployment. This rule seems to be pretty obvious and maybe irrelevant, but it saves a lot of times and script fixing during produciton debug. When the product is deployed to test machines on a frwquently basis it tested each time. If there is some new configuration parameter that needs to be updated. If we forget to update the deployment script it fails in deploy to test machine. Then we fix it in deploy to test machine and produciton deployment works smoothly.

So let's go back to tool seleciton: we use TeamCity as our continious integration system for builds automated tests etc. And it seemed so natural to use TeamCity for automatic deployment as well. We wrote, or actually, reused Powershell script previously written in order to extend Puppet. These scripts do the steps described above. 

So the winners are TeamCity and Powershell

Post-build assembly manipulation

We often think how to modify our code during writing, debugging, but rarely after assembly is built. Well, there are a few kinds of post-build manipulations we might want to perform on compiled assemblies:

Merge
This nice utility was developed by Mike Barnett from Microsoft Research and it enables merging multiple assemblies to a single one. This may be very useful, when one wants to deliver a single component or executable without exposing the internal structure of assemblies. It may be used as command-line utility (from post build action as well) and as a assembly reference and wrapped within another tool. It does not work on Silverlight assemblies, at least at the moment of writing these lines and I asked Mike to check this out.
http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx

Convert to Silverlight
This project developed by Suriel Bendahan enables converting assemblies compiled on server-side .NET to Silverlight compatible assemblies. It makes possible to reuse code written as "server-side" on Silverlight client. It might be useful for generic data structures, generic algorithms, input validations, sharing interfaces etc. The project is provided with it sources, so it can be modified/adopted for your needs.
http://www.codeproject.com/KB/silverlight/SLAssemblies.aspx

Compress
Silverlight assemblies are being downloaded to browser in a XAP file, which is a bunch of DLLs compressed using ZIP compression. This project developed by Rob Houweling uncompresses these assemblies and compresses them again with a higher compression rate. This is very useful when XAP size becomes an issue.
http://web-snippets.blogspot.com/2008/11/another-one-on-repacking-xaps-to-reduce.html

Obfuscate
Obfuscation is a process of changing the readability of the code without changing its functionality. The reason for doing this is preventing others from seeing implementation. Visual Studio comes with a Dotfuscator Community Edition and there are others providers of obfuscation utilities.