The maze book for programmers!
mazesforprogrammers.com

Algorithms, circle mazes, hex grids, masking, weaving, braiding, 3D and 4D grids, spheres, and more!

DRM-Free Ebook

The Buckblog

assorted ramblings by Jamis Buck

The Future of Capistrano

30 August 2006 — 2-minute read

I’ve been asked several times recently if I had any plans to implement in Capistrano the things that Dave Thomas mentioned in his RailsConf keynote address. Not having been there, I had no idea what they were talking about! However, I finally made some time and watched the keynote.

First off, Dave brings up some really good points. The split between developer and sysadmin is a real thing, even if it is one that I don’t wholly agree with. Prerequisites and such are good ideas.

That said, I’m not going to implement them. Or rather, I’m not in a position to implement them right now.

The environments that Dave describes are not the environments I live and work in. If I were to try and implement those things, I’d just be guessing, and I’ve got a pretty bad track record when it comes to guessing what other people need. I’ve learned the hard way to write what I need, and only what I need—and Capistrano, as it stands, is pretty darn close to what I need.

That’s not to say that Capistrano is perfect. It certainly isn’t, and I’ve got plans for further improving it. (In fact, stay tuned for an announcement of a new release, coming up.) However, my vision for Capistrano is not Dave’s vision.

If Dave’s vision happens to be your vision, or if your vision for deployment otherwise differs from mine, then I have a challenge for you: write a deployment system that does what you need it to do. If there’s one thing I’ve learned from Rails, it is that extraction is the only True Way to developing a truly useful system. Perhaps you could be the author of the next generation of Capistrano!

Reader Comments

Jamis, Great to finally get some closure :) This question has been lingering since I saw the keynote, and with your unfortunate blog experience I couldn't find an address to ask you. We use capistrano for most of our projects at "work":http://www.designbyfront.com/ and frequently want to deploy to an internal (QA), or external (Live) server but not both at the same time. Is there a good way to do this?... At present we're just maintaining two seperate deploy.rb files and doing the copy & paste shuffle. Looking forward to the update.
David, take a look at http://jamis.jamisbuck.org/articles/2006/01/03/using-switchtower-with-multiple-deployment-stages. It addresses multiple deployment targets.
Another (and IMHO, better) option for staging is to simply create new tasks that changes whatever you need to change and then calls the deploy action:
1
2
3
4
5
task :stage, :roles => [:app, :db, :web] do
  set :deploy_to, "/var/www/staging"
  
  deploy
end
It's not as flexible as the env var method, but it's hard to argue with cap stage :)
Ben, very nice! I like that, alot. You can even leave the :roles specification off of the task, since when you call deploy, it'll use the roles for that task anyway.
What about patches? I try not to guess what others need either, it's mostly pointless. But if other developers with those needs were to contribute the features that they need in my project in a way that didn't break it for me, then I'd accept them. That seems like a way capistrano itself could grow in those directions - not by your efforts (aside from the effort of accepting patches), but by the efforts of those who want those features.
Hans, certainly I'd consider patches. I've already accepted many that add functionality that I'll probably never use. What I'm responding to in this article are people asking if I, personally, have plans to implement these things. I do not, but if others do, great! Personally, I don't think some of the things Dave described can be done in the existing Capistrano code-base. I'd be happy to be proven wrong, though.
Interesting, this was indeed one of the things myself and some other ThoughtWorkers were talking about in our hotel bar last night. Some of the guys who weren't familiar with Rails were asking about what it would take to get it accepted into more 'enterprise' environments. Being able to split the deployment roles (which, like you I also disagree with) was one of the points. Coincidence is a funny thing :)