billchapman.net

Thoughts on deploying ruby apps without capistrano

I recently left the ruby deployment team for  large managed rails-based hosting provider. We used capistrano for our deployment needs. Once we had successfully configured an application and its dependencies we would hand over a very robust capistrano recipe to the end user and it turns out that almost all of our clients, regardless of skill level, tended to stick with the scripts we provided to manage their deployments. I mention this because I want to state that I think capistrano and solutions like it (Vlad deployment recipes etc..) are wonderful tools, they serve a very necessary purpose and I'd be hard pressed to argue against their value. With that said I can now say that I have not used capistrano or any other cap-like solution for any of my personal deployment needs  for a long time and I find that my deployments are simpler, faster and much less error prone than ever.

I wanted to subtitle this article "Why I removed my training wheels" but I thought better of mocking something that is really a very cool ruby tool written by folks that I really respect.  We often try to mold our framework or language of choice around our needs by writing domain specific languages and awkward helper methods to bridge disparate technologies. I've heard many people say things like "Why wouldn't you want to write everything in language x instead of languages y and z". This is more common than ever with the elegance that ruby brings to the table but I think it causes unnecessary abstraction and over reliance on a single platform.

And when it comes down to administration of a production application, how many hands do you really want in your cookie jar? Seriously, how many of the developers on your team can handle a proper production deployment and have the necessary skills that would be needed to recover from a deployment that goes horribly wrong? The person responsible for your deployments should be ready to jump in to your production box and fend off any gremlins that may have crept up during late night mogwai feedings. This person should have no real need for capistrano as they should have an open connection to the deployment location during the deployment for the sake of immediate response to disaster and active monitoring of your recent changes. If you are already connected to the server, why would you have a need to run tasks from your development environment to remotely effect your production application?  Taking this argument one step further I would say that providing a repository resident recipe that can potentially allow any of your developers to easily deploy new source code is at best a bad idea and at worst a security risk. Maybe you are on one of the few teams that use key based authentication and leave your recipe out of the source tree but a deployment method that requires you to run server resident scripts is much easier to secure and to ensure that only the proper people have access.

I realize that the reality of the matter is that most ruby teams are still very small and most of the early adopters have had no choice but to become savvy at the command line and in the nuances of deployment but as our community grows I am meeting more and more people with little or no experience in the types of skills needed to manage deployments ( I was once one of them). Teams made up of these folks will certainly want to start out with tools like capistrano but I feel that any project manager has a responsibility to bring a system administrator or deployment expert onto the team before it is too late or hire a company like my former employer to manage their hosting and administrative tasks for them.

This could easily become a longer post and I think I will revisit this topic very soon. In the mean time I will discuss my current deployment methods of choice.

Instead of spending a half hour configuring a new capistrano recipe I find that it is much more useful and flexible to create server resident bash functions that provide the necessary functionality.  Of course I will reuse previous scripts to speed up the process of bootstrapping a new enviornment but a typical solution would be a bash function called deploy that has in the best case scenario three lines in it.

1. Check out the latest revision from the source repository to a local cache
2. rsync this revision to the current application directory
3. symlink any shared assets and configurations
4. restart your mongrels/thins/passenger

Of course you may make the argument that this solution is not very scaleable across many application servers but it is simple enough to add the necessary lines to initiate deployments across many app servers. One option is a function  that will execute the deploy function on each remote server from any of servers in the environment ( ssh user@hostname "deploy" )  This is really what capistrano does anyways, the difference is that none of code that capistrano runs is actually resident on your server and there are some limitations to what can be done remotely.

Also note that while very few, if any,  of the applications we write in the ruby world will ever  be run on windows based servers there is a growing community of  Windows based developers out there who have to overcome the hurdles of getting capistrano or other remote administration tools to play nice on their development machines.  Server resident recipes whether they are in Bash, Ruby or a dsl like Capistrano eliminate the need for a cross platform tool assuming you are not worried about Windows server hosting and if you are then you have bigger problems then efficient ruby deployments. The bottom line is that server based solutions will scale better across a large development team, in my experience they run much faster and they put you where you need to be during a deployment, On the server, in the trenches, waiting for the  fit to hit the shan.

I'm hoping to detail the deployment process that I currently use (perfected in the trenches by my good friend Wayne Seguin) soon.

Tags: bash, best practices, capistrano, Web Application Deployment