Automatic Deployment :: Choosing the magic tool

About a year ago I was asked to automate the deployment process. Actually it has some level of automation, but it should be significantly improved. When my boss says "significantly improve", he means "completely rewrite". In the beginning I was looking for that magic tool, that click-and-relax solutions that will do the work. Polling at StackOverflow and googling around resulted with a list of tools. This post will focus on advantages and disadvantages of these tools. In the next post I will try to explain what solution was chosen and why.

eyeShare by Ayehu http://www.ayehu.com/

eyeShare is a descent UI based tool for deployment automation and monitoring. I was interested only in the automation part. It provides and drag and drop user interface with different kinds of actions: Copy, Stop Service, Start Service etc. It has many cool features, such as email and SMS notifications and listeners. The listeners allow the user to respond to some failure in some action. For example, deployment of the database failed, eyeShare will send email/SMS with notification and will wait for reply: proceed or rollback database changes. This might be extremely useful. However it has some major drawbacks for our basic scenario:

1. deployment processes stored by eyeShare are not version controlled, they are stored in SQL Server database with no history tracking; 
2. it requires installation of the UI management on each machine and there is no web UI accessible from all the machines; 
3. something that took me sometime to understand and I had to talk to their support: let say I have action A and then action B. I assume that until action A is finished, action B does not start. Basic serial processing. However eyeShare executes action in parallel, even of they are organized serially in the deployment workflow. There are some workaround that need to be done using timers and timeout in order to overcome this behavior. 

Octopus Deploy http://octopusdeploy.com/

Octopus Deploy is a cool deployment project for ASP.NET and Windows Service projects. Actually I did not dive too much into it, since it requires any software component will be delivered as a nuget package. Since our product has many dependent components, it was decided that it would be too much work to package every component as nuget package.

Puppet http://puppetlabs.com/

Puppet, puppet, puppet! Everybody in the DevOps world talk about Puppet. If your want automatic deployment you have to use Puppet. 

I was curious when starting to learn about Puppet. I have to admit, that the learning curve was steep, but at the end we had automatic deployment POC using Puppet. After the POC was completed it was decided not to proceed with it. Here are some of the reasons. My feeling was that Puppet it more Linux/Unix oriented, that Windows. Since our main product is developed in .NET and should be deployed to Windows servers, the whole overhead with Linux style paths and Linux style commands is ridiculous. Some of the operations are not supported in Puppet agent on Windows and I had to write scripts in Powershell. At the end it resulted that most of the things are written in Powershell, so there was no reason to use Puppet as a manager of these scripts.

For the actual selected and working solution wait for the next post:
http://borismod.blogspot.co.il/2013/07/automatic-deployment-final-solution.html