Capistrano 2.0 Preview 1 has been released. The first time I used Capistrano I was blown away by the ease with which you could deploy an application to a production network with multiple application servers.

New features include:

  • Namespaces for Capistrano Tasks
  • Deployment strategies - You don’t have to deploy via a Subersion checkout, now you can export, or you can export locally and copy a tgz or zip to the target server.
  • Environment Variables via the Comand Line

I’m not doing it justice, for more information see www.capify.org.

Namespaces should make it easier to build atop Capistrano…

Namespaces should help projects like Mike Bailey’s deprec which extends Capistrano to automate not just the deployment of a rails application but the installation of a full rails stack.

Cap on Other Platforms

…And, this is the part that interests me, how Ruby, RoR, and the technologies built around them are infecting the broader community. From Ian Sefferman’s blog entry, Capistrano and Java:

Capistrano is definitely Rails tailored. It makes a lot of assumptions (in true Rails philosophy fashion) that make it dead simple to use for your new Rails app. However, there’s nothing really constricting about Cap itself that forces it to be Rails only. Recently, Maurice and I did our first Java project for Openomy. We knew we’d be deploying to more than one box, so we decided we’d try out Cap for deploying a Java service to multiple boxes. I figured I’d write up some of what we learned and what we’d like to change in the future.

Also, see Automated PHP Deployment with Capistrano.

Capistrano is only for crazy Rails apps right? Nope. Its simply a platform for automation. It just so happens that deployment usually requires quite a bit of steps. Hmmm…lots of steps…automation… a match made in heaven. So sure, Capistrano was thought up with Rails in mind, but created openly so you’re able to use it any way you’d like.