Seven Reasons I Hate Capistrano
This weekend I set up Capistrano 2 for the first time. I was very eager to try it, especially given all the glowing blog posts about it. Everyone seems to think it’s the best thing since sliced bread. Capistrano has clearly become the standard for Rails application deployment. But after two days of wrestling with deploy.rb recipes, I have a few issues to share.
#1: Too Much Hype
I come most recently from the world of Java, where the de facto standard for application deployment is Ant. When I first started working with Ant, I was quickly impressed with it’s power, flexibility, excellent documentation, and tremendous community support.
Perhaps Ant set my expectations too high, because I was immediately disappointed with Capistrano by comparison. Capistrano does one hard thing well: automated simultaneous deployment to multiple servers (and yes, built-in transactions and rollbacks are very nice). However, the power and flexibility I expected just wasn’t there. Admittedly, Capistrano is still very new compared to Ant, but it certainly doesn’t deserve the hype… yet.
#2: Poor Documentation
No docs are provided with the Capistrano gem. Don’t believe me? Check out how many files are installed in /usr/local/lib/ruby/gems/1.8/doc/capistrano-2.0.0/ (that’s right: zero). There are no man entries for cap or capify. Online docs are either incomplete or out of date.
This was especially frustrating for me when I had to diagnose a problem with a subversion checkout in my Capistrano recipe. For some reason the checkout consistently failed during “cap deploy” but worked fine when started manually. No problem, I thought, I’ll just turn off the svn “-q” (quiet) flag to see where it’s failing. Easier said than done. I could find no documentation about how to accomplish this. I finally had to dig through the source code until I stumbled on the :scm_verbose variable.
Why was this not clearly documented somewhere? A 2.0 app simply should not be released without good documentation.
#3: Backward Incompatibilities
Should I use “capify .” or “cap –apply-to .”? Do I need a deploy.rb file or a Capfile or both? Will 1.x tasks work with 2.0? Capistrano is not that old, yet we’re already dealing with incompatibilities or confusion about the previous version.
With version 2.0.0, many of the how-to blogs and tutorials are now unhelpful or misleading. Yes, I realize out-of-date blogs are inevitable with any new software release, but the issue is much worse due to lack of good documentation.
#4: Poorly Formatted, Hard to Read Output
Capistrano output is dense, cryptic, and hard to read. Even for simple recipes, error messages are very easy to miss in the badly formatted text dump. This makes debugging complex recipes an exercise in frustration. I would like to see a clear visual distinction between tasks, errors, and transactions in the output. Even better would be a summary at the end of what worked and what didn’t.
#5: Opinionated Software = Huge Assumptions
I love this line from the Capistrano 2.0.0 README file:
Capistrano is “opinionated software”, which means it has very firm ideas about how things ought to be done, and tries to force those ideas on you.
As a Rails developer, I’m comfortable with the concept of opinionated software. But Capistrano takes it a step too far, in my opinion. It makes big assumptions about the way a Rails app should be deployed: ssh and subversion must be set up, usernames must be consistent, servers always restart the same way, a spin script must exist (why wasn’t it created by capify?), and so on. All these assumptions mean a struggle if you want Capistrano to do anything different.
#6: Only One Way to Deploy
If you want to use Capistrano, you will connect via SSH and pull files from a code repository from the remote server. Want to use FTP or rsync? Maybe if you roll your own. Want to package up your app locally and send it to the server to deploy? Sorry, no can do.
Both Java and .NET provide multiple standardized deployment options, which provide a great deal of flexibility in different environments. Does that flexibility mean automated deployments are more difficult in Java or .NET? Not at all.
#7: No Built-ins for Common Tasks
Pop quiz: What are the two things that need to be done when deploying almost every Rails app?
- Switch to production mode in environment.rb
- Switch to fcgi dispatcher in .htaccess
Why doesn’t Capistrano do these automatically in the deploy task, or at least provide some built-in tasks I can call myself? Instead of making these common things easy to automate, Capistrano forces me to roll my own custom sed scripts. Yuck.
Living With Capistrano
Okay, I may not be Capistrano’s biggest fan, but I will continue to use it — in the Rails world it’s still better than the alternatives. I hope the developer continues to improve it. I look forward to future enhancements (and documentation).
For my next post, I’ll detail my own Capistrano deploy.rb file for your enjoyment.
Posted on September 30th, 2007 in the Rails category | PermalinkYou can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Leave a Reply
You must be logged in to post a comment.