blog

At Avatar New York, we've always implemented some form of version control system.  From Microsoft’s Visual Source Safe (shutter…) to CVS, SVN, and finally Git (although we still use SVN for some projects).  Not using some form of VC was a non-option and all our developers were required to learn it if they didn't already.  Deployment, however, was another issue.  With the exception of VSS, we’ve typically “deployed” our code by simply updating the live site to the latest stable code in the repo (i.e. trunk, master, etc). If there was ever a problem, we could always rollback to the previous version. There are couple problems with this strategy:

• there is no easily automated way to deploy other config files outside the repo
• there is no easily automated way to execute other tasks that may need to be run in conjunction with a deploy (maybe a shell script, soft-linking files, changing/ensure correct perms, etc).
• it becomes a tedious process, prone to human error, past 1 server if not under a network file system
• allowing multiple admins to “deploy” the sites becomes problematic when it comes to file permissions
• there is a lack of visibility when it comes to testing, logging, and viewing deployments

It was obvious we had to change our strategy. We looked into a few popular solutions including Capistrano, Jenkins, Vlad the Deployer, and Drush Deploy, but none of them satisfied all my requirements. Enter DeployHQ.com. Some of the features that led us to conclude this was the right solution for us were:

• deployment options for both SVN and Git
• technology agnostic (I can deploy any site using the same setup from Wordpress to Drupal to CakePHP)
• key-based server authentication and IP address restriction
• email and webhook Integration (which enables us to log to our Loggly account, giving us an overall view if/when problems occur)
• cached repo
• testing a deploy
• muliple Users
• ability to add config files and/or ignore repo files
• ability to run shell scripts or commands
• ease of use - I can setup a new deployment in a matter of minutes
• ability to implement Continuous Deployment (down the road if/when needed)

So far, we’ve been successfully deploying a handful of sites with this new strategy on our Cloud Servers and haven’t looked back.  Now if we can only figure out how to automate deployment of those legacy VSS sites.  Hmm...