Capistrano 1.4.1
Posted by jamis February 24, 2007 @ 08:39 PM
Here it is, another Capistrano release, and less than a month since the last one! Miracles truly never cease.
Capistrano, for those embarrassingly late to the party, is a utility for executing commands in parallel on multiple remote servers. It is useful for lots of things, including automating deployment of Rails applications.
Version 1.4.1, available just as soon as the mirrors get updated, is a pretty minor update, but has one new feature:
- You can now pass :env to ‘run’ (and friends), in order to specify environment variables that should be set for that command. For example:
run “some_batch_thang.rb”, :env => { “DEBUG” => “1” }
There is also one deprecation: if you are using UPPERCASE variables in your Capistrano recipes, you’ll being seeing warnings now. Support for variables that start with uppercase letters will be removed altogether in Capistrano 2.0. If you want uppercase identifiers, you should use Ruby constants.
The two fixes in this release:
- Actor#get will not close the SFTP channel when it finishes. This makes it possible to do multiple SFTP gets and puts in a single session.
- The subversion adapter now passes the “no-auth-cache” option, so that if you configure an explicit subversion username for deployment other than your dev username, those deployment auth tokens won’t clobber your development tokens.
So, go get it, “gem install capistrano.” Or download it directly from RubyForge. And at the risk of promising too much, too early: I expect this to be the last 1.x release of Capistrano, barring any critical problems that may arise with 1.4.1. Come on, cap2!

What’s planned for Cap2? Will you be able to just think “cap deploy”?
Hey—does Rails now do migrations in a transaction? The last time one failed, it didn’t seem to do so. That has made remoting a deployment with migrations a risky item for capistrano.
Is this all pieced-together now?
Joe, please do put together a patch for that. :)
Ryan, it isn’t Rails that is the limiting factor on that, it’s the DBMS itself. Most databases will not run schema-modifying statements within a transaction. If that concerns you, then you need to work around it manually, by dumping the DB before the migration and restoring it if the migrate failed.
I’d love to see documentation for using a gateway. It used to work with my setup but now, I just get authentication failures. It seems like remote connections can’t use keys…