Capistrano 2.0 Preview 2

The upcoming Capistrano 2.0 release continues to evolve! Remote administration of single servers and server clusters has never been easier. With Capistrano, you can:

  • Deploy web applications with a single command
  • Keep software in sync across multiple machines
  • Install entire servers with just a few keystrokes
  • Impress the ladies with your leet sysadmin skills

Ok, well, maybe not that last, unless she’s a really special lady. But the rest certainly apply.

Capistrano 2.0 Preview Release 2 is now available (version 1.99.1). You can only grab it from the Rails beta gem server:

gem install -s capistrano

NOTE that Capistrano 2.0 is not 100% backwards-compatible with Capistrano 1.x recipes. For more information on upgrading, check out

To install the preview release, you’ll need to make sure you’ve already got the following gems installed, too, which Capistrano depends on (and which can be found in the main Rubygems repository):

  • net-ssh
  • net-sftp
  • highline

Download it, install it, try it out. Kick the tires. Report what doesn’t work. We’re getting close to a general release!

SO. Now that all of that is out of the way, let’s talk about what’s new in PR2. First, the bug fixes:

  • The “copy” deployment strategy now checks out the local copy to a temporary directory, rather than using the current working directory. This makes it possible to use with some picky SCM’s that don’t like checkouts being made into an existing checkout.
  • The “deploy:check” task was broken for some deployment strategies. It should work now for all of the pre-packaged strategies.
  • The “shell” task should actually work now.
  • The “desc” keyword will apply to the next defined task, regardless of which namespace the task is defined in.
  • Don’t retry failed connections when an explicit :auth_methods list is given via :ssh_options.
  • Fixed a few minor documentation typos.

Next, the new features:

Feature: The “deploy:cold” task will run migrations before starting the app. If it is the first time you’ve deployed your app, chances are the database needs setting up, too!

Feature: The old method of extending tasks (e.g., tasks named “before_deploy” and “after_deploy” extending the “deploy” task) is now discouraged (though not formally deprecated, yet). The new approach uses some new keywords:

before :deploy, :my_custom_task
after “deploy:symlink”, :do_this, :and_do_that

More generally, you can attach tasks of your own creation to arbitrary “events”, using the “on” keyword:

on :before, :my_custom_task, :only => :deploy
on :after, :do_this, :and_do_that, :only => “deploy:symlink”

The :before event gets triggered before any event is invoked, and :after gets called immediately after the event finishes successfully. There are four other events currently supported by Capistrano:

  • :start is triggered when a task is invoked via the command-line
  • :finish is triggered when a task invoked via the command-line finishes successfully
  • :load is triggered after all recipes have loaded, but before any tasks are executed
  • :exit is triggered after all tasks have been executed

You can even define your own events, and then trigger them using the “trigger” method.

Feature: The “deploy:app” namespace has been axed. The tasks that it contained now live in the “deploy” namespace directly. Thus, “deploy:app:start” and “deploy:app:stop” are now “deploy:start” and “deploy:stop”, respectively.

Feature: If your “scm_command” is set to a custom value because your SCM lives in a non-standard location on the remote host, you previously ran into problems if your SCM command did not live at the same location on your local host. Now, if you need different settings for the scm_command depending on whether it is being invoked locally or remotely, you have the option of specifying either one separately:

set :scm_command, “/opt/local/bin/svn”
set :local_scm_command, “/usr/local/bin/svn”

Note that if “scm_command” is set, “local_scm_command” will default to that value, but if “local_scm_command” is set, “scm_command” is unaffected.

Feature: Servers are now uniquely identified by Capistrano based on their full connection information, including hostname, username, and port. (Before, servers were only unique based on the hostname.) This makes it possible to use Capistrano in a NAT’ed environment, where all of your servers are using the same hostname, with different port numbers.

Feature: The “capify” command now understands the “-h” switch, which should make it behave a little more like people expect.

Ruby and Rails continues book bonanza

O’Reilly has analyzed the book sales once again. Here are the juicy bits about Ruby and Rails books:

In the Web design and development area, it’s worth noting that Ruby on Rails has continued its blazing growth, but Ajax books have not. The decline of both PHP and ASP are striking…

…Rails in the bottom middle was a small speck in last year’s first quarter post. Now the size of the box fits the size of its name at least. And its market share is almost equal to SQL and has surpassed VBA, Perl and Python. Python is also experiencing good growth, just not at the blazing velocity of Ruby. I would expect by next year, we will see Ruby have an even larger share/square.

Slingshot goes public

Joyent’s Slingshot technology for creating offline-capable Rails applications has gone public. They’re even doing a competition to celebrate: The best ports of various open source Rails applications can win a 1-year big Accelerator ($1250 value). Now there’s a project you can hack on the plane to Portland in a few weeks ;).

Capistrano 2.0 Preview 1

Capistrano 2.0 Preview 1 is now available for installing and testing:

gem install -s capistrano

(It’ll show up as version 1.99.0; the 1.99.x series will be used as the preview releases for 2.0)

For those of you late to the party, Capistrano is a utility for executing remote commands in parallel on multiple remote servers. It is ideal for system administration, and for deploying web applications.

Note, though, that this release is not entirely backwards compatible with Capistrano 1.x, so you may need to massage your recipes a little to make them work smoothly under the new version. In order to make the upgrade process as smooth as possible, I’ve begun compiling a few documents to point out new features, gotchas, and upgrade paths:

Like Capistrano 2.0, the new website is still a bit rough in spots, and will see more documentation appearing over the next few weeks. If you have any feedback for either Capistrano 2.0 or the website, please join us on the Capistrano mailing list and make your voice heard!

RailsConf Keynotes and Fourth Track

We’re putting the finishing touches on the RailsConf 2007 schedule this week. Given the huge number of high quality proposals (well over 3 times the number from last year), we’re working on putting together a fourth track.

We have also finalized an exciting lineup of keynote speakers for the conference. I was frankly a bit worried about the keynote lineup as we started initial planning of RailsConf 2007. Last year’s keynotes were going to be hard to live up to. My fears were ill-founded. We ended up with a program to be really excited about.

Tim Bray, Sun, Co-creator of XML and Atom

Avi Bryant, Creator of Seaside and DabbleDB

Ze Frank, Comedic Digital Savant

David Heinemeier Hansson, 37 Signals, Creator of Ruby on Rails

Dave Thomas, The Pragmatic Programmers

The RailsConf program promises to be thought-provoking, trend-starting, entertaining, tone-setting, and, most of all, fun.

See you in May!

Javascriptian REST

Eric Mill went ahead and created Jester, a library that lets you manipulate your Rails-style resources with javascript models. I think it’s great that we’re seeing implementations in other languages. This python port of Routes implements map.resources, can a python port of ActiveResource be far behind?

Rails 1.2.3: Compatible with Ruby 1.8.6 (and other fixes)

While Rails Edge continues to move forward at a rapid clip, we’ve still had the time to make sure that Rails 1.2.x stays in the game. This release irons out the few wrinkles there was between Ruby 1.8.6 and Rails 1.2.2. So now you can enjoy the latest Ruby with the latest Rails.

Besides the 1.8.6 compatibility, we’ve included a few minor fixes. Nothing major. This should be a drop-in replacement for Rails 1.2.2.

As always, you can upgrade with gems or use the latest svn tag (rel_1-2-3). Enjoy!

Plugin loading internals have changed, for the better!

Until now, the task of locating and loading plugins into your app was handled by a handful of private methods on the
Rails::Initializer. These methods were fairly large, coarse grained, and as a result hard to hook into without resorting
to fragile cut and paste if you wanted to customize how your plugins are loaded.

New in Edge Rails, changeset 6277 replaces this smattering of methods with two new internal classes, Rails::Plugin::Locater and Rails::Plugin::Loader. If you need to hook into how plugins are loaded, you can define a subclass of Rails::Plugin::Loader, then register your custom class to be the class that handles plugin loading using the new plugin_loader configuration option in your config/environement.rb: do |config|
    # Config settings...
    config.plugin_loader = PluginLoaderWithDependencies

This should make extensions on top of the plugin system, such as the Plugems approach developed by the team over at Revolution Health, far easier to implement and maintain.

To those monkey patching the plugin loading subsystem in Rails, this introduces substantial changes to the way that plugins are located and loaded. In the short term this might mean that your customizations to the internals will very likely break, but the good news is that in the long term the new implementation will be far easier to customize.

For those adventurous early adopters living on the Rails Edge, please give your apps a test run to ensure these changes
don’t break anything for you. As always, bug reports and patches are welcome: