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