Capistrano - News

Farewell

2009-02-25T05:07:00Z

Capistrano has been a fantastically fun and varied project to work on, and it’s taught me a lot. However, it’s time for me to say goodbye, and move on. You can read the full announcement on my blog, but the gist of it is that I’m no longer going to be updating or maintaining Capistrano (or related libraries). Thanks to everyone who offered their support and encouragement over the last couple of years. It’s been great!

Love/Hate Survey

2009-02-05T17:56:00Z

In order to help guide development decisions for future versions of Capistrano, I’ve put together a small survey here:

http://www.surveymonkey.com/s.aspx?sm=MqcehUinkef0BkEhmqX5KA_3d_3d

It is seven questions, all optional, and all free-entry. It should only take 5-10 minutes to fill out. Thanks!

Capistrano 2.5.4

2009-02-05T05:04:00Z

Capistrano 2.5.4 is now available. If you’re installing by hand, or by a manually downloaded gem, be sure and grab net-ssh 2.0.10, too, which Capistrano 2.5.4 depends on. (If you’re installing remotely by gem, that dependency should be taken care of automatically.)

There aren’t any new features in this release, just bug fixes:

The ‘user’ option from ~/.ssh/config is now handled better. If you set an explicit user in your deploy.rb, that user will be used. If you don’t, the user from ~/.ssh/config will be used. If there is no user setting in ~/.ssh/config, the USER environment variable will be used.
Sudo “try again” prompts should be detected more robustly now. If you experienced issues where an incorrect sudo password would cause Capistrano to (apparently) hang, chances are this release will fix that for you.
The supported environment variables are now listed at the end of the -H output.
Capistrano should play more nicely with newer rspec versions. The optional include_priv parameter to respond_to?() is supported now.
If you’re using the remote_cache strategy with rsync (you’ve specified any files or directories to exclude in the :copy_exclude array), the -t switch is now being passed to rsync, which will preserve file times.

As ever, please report bugs to:

http://capistrano.lighthouseapp.com/projects/8716/tickets

And feel free to fork the project and submit pull requests with your clever ideas:

http://github.com/jamis/capistrano

Enjoy!

Net::SSH 2.0.5

2008-12-07T05:07:00Z

A new version of Net::SSH 2.0.5 is out. Net::SSH is the library that Capistrano uses to communicate to your servers via the SSH2 protocol. You can upgrade using Rubygems:

  gem install net-ssh

This new release fixes a handful of bugs, among them:

Using SSH agent forwarding on windows via Pageant should work now. Before, you’d get errors related to “undefined method ‘close’”. These should be fixed now.
Net::SSH should be working under Ruby 1.9 now.

Update: Net::SSH 2.0.6 is hot on the heels of 2.0.5. 2.0.5 was released without a critical file, thanks to an omission in the Manifest file. Make sure you grab 2.0.6, and not 2.0.5.

Capistrano 2.5.3

2008-12-07T04:50:00Z

Capistrano 2.5.3 is a maintenance update. Install it via Rubygems:

  gem install capistrano

There are no new features; only a handful of bug fixes:

A lingering issue with git deployments has finally been laid to rest. If you’ve been getting “Unable to resolve revision” errors when deploying from a git repository, give cap 2.5.3 a try.
A bug in the get/put/upload/download helpers that caused them to ignore blocks that were passed to them has been fixed.
If a failed deploy triggered a rollback when there was no previous deployment to roll back to, deploy:symlink would explode. It is now more robust and will do nothing if there is no previous release.
Rubies that don’t inspect terminals well (i.e. JRuby) will now default screen columns to 80, instead of raising an obscure exception.
If the :previous_release variable is queried when there is no previous release, it will return nil instead of raising an exception.

The biggie here is the fix for git deployment, but if you’ve been bitten by any of the others, you might want to give 2.5.3 a spin. Even if you haven’t, it’s better to have fixed software than broken software, right?

Capistrano 2.5.2

2008-11-13T18:58:00Z

It looks like one particular change to 2.5.1 didn’t see enough testing. If you were trying to deploy from git with Capistrano 2.5.1, you probably ran into this little error: “Unable to resolve revision for ‘HEAD’ on repository ’...’”. It turns out to have been due to some flags that were added to the “git ls-remote” call. I just released cap 2.5.2 which removes those extraneous flags, and deploys via git should be working again.

Nothing else changed in this release.

Capistrano 2.5.1

2008-11-07T21:22:00Z

Capistrano 2.5.1 is now available. This is release is primarily a maintenance release, but does include a few new minor features.

Features

The -T switch now allows you to specify a pattern, which will be used to filter the output (like Rake’s -T does).
If you want to write tools that read Capistrano’s task list, you’ll find the new -t switch useful. It causes -T to omit the task description and any trailing text.
RemoteDependency#try now uses invoke_command instead of run, so you can use sudo and friends to test commands.
A new environment variable HOSTFILTER. This works like the HOSTS environment variable, but instead of making all tasks run on the given hosts, it will only run tasks that would run on any of the given hosts.
If you are using subversion, you can set the :scm_arguments variable to specify arguments that should always be passed to subversion. (Other SCM’s have not yet been tweaked to work with the new :scm_arguments variable.)

Other Fixes

Commands executed locally under Windows should work better now.
If :sudo_prompt is blank, sudo() will not emit the -p switch.
Symlinks are now copied when using rsync.
The git query-revision now matches on the exact branch name.
The SCM::Base#scm method is now exposed publicly.
Some locally executed commands will be logged now.
Ruby 1.9 compatibility tweaks.

Download it and give it a try! As ever, bugs may be reported via the Capistrano ticketing site. If you’ve got a patch you’d like to submit, you can either submit it with a ticket, or via a GitHub pull request. Or, you can send me an email with your patch.

Fast Remote Cache

2008-09-03T16:44:00Z

I just moved the deployment strategy we use at 37signals to GitHub. Feel free to grab it and try it out: http://github.com/37signals/fast_remote_cache/tree/master.

It’s basically a variation on the standard remote cache strategy, but it makes hard links to the files instead of copying them, which turns out to be much, much faster on large applications. It’s used as a Rails plugin (though it isn’t specific to Rails). The README should be sufficient to get you started with it!

Capistrano 2.5.0

2008-08-29T03:08:00Z

Capistrano 2.5 is now available, with several new additions and a fair helping of bug fixes and general improvements. To install it:

gem install capistrano

Here’s a rundown of what’s new:

parallel() helper

A common question by people learning Capistrano is “how can I tell what the current server is?” There still isn’t a good answer to this (since Capistrano executes each command against all active servers in parallel) but Cap 2.5 introduces the “parallel” helper that might just make the question moot.

An example is worth 1,000 words:

task :restart_everything do
  parallel do |session|
    session.when "in?(:app)", "/path/to/restart/mongrel"
    session.when "in?(:web)", "/path/to/restart/apache"
    session.when "in?(:db)", "/path/to/restart/mysql"
  end
end

When you execute that hypothetical :restart_everything task, the parallel helper compares all active servers against the conditions. All matching conditions for a server indicate which command(s) will be run against that server, and then all those commands (for all matching servers) are run in parallel. (In this case, the mongrels would be restarted on the app servers at the same that apache is being restarted on the web servers, and mysql is being restarted on the db servers.)

The only way to do something similar before 2.5 was to invoke 3 separate run commands, which would run the commands serially, instead of in parallel.

You can pass callback blocks to each condition, as well, to handle output specially for each case:

123	session.when "in?(:app)", "/path/to/restart/mongrel" do \|channel, stream, data\| # same format of callback as you would give to run() or sudo()end

You can also specify a fallback condition, to be used when a server fails to match any of the conditions:

1	session.else "/execute/something/else"

Lastly, the string specifying the condition must evaluate to valid Ruby code. Inside it, you can access the in?() helper (to query whether the current server is included in the given role), as well as a “server” variable that you can use to match specific hosts by name:

1	session.when "server.host =~ /app/", "/command/to/execute"

This should allow some exciting new usage patterns to emerge. Please share what you come up with!

Chained gateways

Prior to 2.5, Capistrano was not easily able to accomodate servers that needed to be accessed via two or more gateway machines. In 2.5, the gateway variable can now be an array of hostnames, and the gateway will tunnel through all of them:

1	set :gateway, %w(jamis@gateway.host deeper.host final.host)

In that example, each server would be connected to via a triply-chained gateway, tunneling from the local server to the final host via gateway.host (using “jamis” as the username), then deeper.host, and then final.host.

“-s” and “-S” infer the types of their arguments

When you set a variable from the command-line (using -s or -S), the type of the value will now be inferred. This allows you to set booleans, integers, floating point values, and nil values from the command-line, as well as strings (the fallback if a type cannot be inferred).

deploy:rollback and mongrel

Prior to 2.5, deploy:rollback would fail with mongrel processes that were spawned via Rails’ script/process/spawner tool. This was because the mongrel processes were restarted after the bad revision was removed, resulting in mongrel dying because it’s current working directory was invalid.

In 2.5, the bad revision is not actually removed until after the restart happens.

Dry-run mode

Prior to 2.5 you could use the "-d" (--debug) switch to step through your recipes. In 2.5, this is expanded with the "-n" (--dry-run) switch, which will run the tasks straight through, but will not actually invoke any of the (remote) commands. (Local commands are still executed.)

Other changes and bug fixes

From the change-log:

Allow HOSTS spec to override even non-existent roles
Sort releases via “ls -xt” instead of “ls -x” to allow for custom release names
Add descriptions of -n and -d to the verbose help text
Rename deploy:rollback_code to deploy:rollback:code
Make sure a task only uses the last on_rollback block, once, on rollback
Add :shared_children variable to customize which subdirectories are created by deploy:setup
Allow filename globbing in copy_exclude setting for the copy strategy
Allow remote_cache strategy to use copy_exclude settings (requires rsync)
Make None SCM module work in Windows
Recognize mingw as a Windows platform
Fixed failing tests in Windows
Made :scm_auth_cache control whether password option is emitted in subversion module
Fixed timestamp bug in CVS module

Feedback

As ever, please report bugs via the Capistrano issue tracker. If you’d like to submit a patch, please make sure it applies cleanly on the latest version of the source code, and submit it either via the issue tracker above, via email, or via GitHub pull request.

Lastly, the Capistrano mailing list is a great place to ask and answer questions, and to swap tips and tricks. There is also an IRC channel you can use: #capistrano on irc.freenode.net. (The IRC channel requires a bit of patience, since your question might not be noticed right away.)

Thanks!

Capistrano: From the Beginning

2008-08-27T22:21:00Z

Capistrano: From the Beginning is the first in what (I hope) will be a series of in-depth how-to’s for setting up and using Capistrano. This one is targeted at people who have finished their first Rails application and want to know how to deploy it. It includes some tips for choosing and setting up your environment.

Perhaps the most “revolutionary” thing about this article: it discourages the use of the deploy:cold task. In running the last two tutorial sessions, and in setting up some applications from scratch recently, I’ve discovered that deploy:cold is, essentially, worthless for launching a new application. The reality is that there is not a single command that can magically configure and deploy your application for the first time. This article attempts to hold your hand as you walk you through the (many) steps that are required. And, ultimately, Capistrano does prove helpful, even in this tedious task.

By the time you’ve reached the end of the article, you should be able to “cap deploy” your application, though, which is really the whole point of Capistrano when used with Rails deployment!

Capistrano 1.4.2: Mandatory Upgrade for Capistrano 1.4.1

2008-08-26T15:48:00Z

If you are currently using Capistrano 1.4.1, you are strongly urged to upgrade to Capistrano 1.4.2. This upgrade adds no new features, and is entirely compatible with Capistrano 1.4.1. All it does is make Capistrano play nice if Net::SSH 2.x is installed.

This is absolutely necessary if you wan to have Capistrano 2.3 or later installed alongside Capistrano 1.4.x, because Capistrano 2.3 and later depend on Net::SSH 2.x. Even if you are not currently using Net:SSH 2.x or Capistrano 2.3 or later, it is strongly recommended that you upgrade, because eventually you might want to have one or the other of those installed, and doing so with cap 1.4.1 will result in some really obscure errors.

Save yourself some time troubleshooting: upgrade today!

Online Capistrano Tutorial Session #2

2008-08-04T13:30:00Z

The first online Capistrano tutorial session was very successful, thanks to everyone who participated. Now, it’s time to try again!

The second online Capistrano tutorial session is now open for registration: http://events.capify.org/events/2.

It is scheduled for Wednesday, August 13th, at 7pm (Mountain time), and will last two hours (plus up to an hour at the end for Q&A). As before, this tutorial is targeted at beginning Capistrano users, those will little or no prior experience. (If you’re looking for a session for more advanced users, keep watching this space—I’ll probably do one of those eventually, as soon as I can write a curriculum for it.)

Pattern: Conditional Configuration

2008-07-14T22:31:00Z

Here’s a pattern that I’ve been using and seeing more and more often. The problem it solves is this: how do I configure Capistrano differently for some set of predetermined scenarios? The most common usage of it is when configuring Capistrano to deploy to different staging locations, and you want to configure each stage differently.

The cleanest solution simply involves creating a different task for each scenario. Within each task, you set variables, declare roles, and load files:

task :scenario_a do
  set :deploy_to, "/path/to/scenario_a"
  role :web, "scenario_a.web"
  role :app, "scenario_a.app"
end

task :scenario_b do
  set :deploy_to, "/path/to/scenario_b"
  role :web, "scenario_b.web"
  role :app, "scenario_b.app"
end

When you then go to invoke a task (like deploy), you simply invoke the scenario task you want first:

  $ cap scenario_a deploy

Capistrano simply invokes the task in the same order they were specified, so in this case, it will first call scenario_a (which will set up the deploy_to variable and the roles) and then will call deploy, which will use the settings you gave.

It’s really a quite powerful pattern for conditional configuration.

Capistrano Links on del.icio.us

2008-07-10T15:10:00Z

Call for links!

We want to centralize the wide breadth of knowledge that has spread accross the World Wide Web into one, easy to bookmark location:

del.icio.us/capistrano_links/

Have you written about Capistrano?

If you have, please send us a link (or links for that matter) to capistrano_links@filmprog.com.

We will then summarize your content in the notes field for easy reading and searching. You'll now have one place to go for the all the content available on the web concerning Capistrano.

But what if I have old information?

That's great! Because sometimes there are people out there who, for various reasons, are not able to upgrade to the latest version of cap. Just let us know what version (approximations are fine) of Capistrano you wrote the article for. And it will get tagged accordingly.

Were all in this together

The faster you send us your link the better the account will be! Don't wait, send your link now!

Online Capistrano Tutorial Session

2008-07-06T03:50:00Z

When: Tuesday, July 15, 2008, at 7:00 PM MDT (what's this is my own time zone?)
Where: Online, via Campfire
Duration: 2 hours
Seats: 10
Cost: $10
Sponsors: SliceHost — awesome VPS hosting!

To register, go here: http://events.capify.org/events/1.

This tutorial will focus on using Capistrano to deploy a Rails application from a Subversion repository. It will be targeted at beginners (so if you already have experience with Capistrano, you might not find much value here). Attendees will be given temporary shell access to a server, and a simple Rails application will be provided. During the course of the tutorial, attendees will configure and deploy the Rails application.

If there is sufficient interest, and this format of presentation works well enough, I may offer subsequent sessions on more advanced topics, including (but not limited to) deployment using Git, non-Rails deployment, and non-deployment uses of Capistrano.

What version(s) of Capistrano will be covered?

This tutorial will only cover the most recent version of Capistrano (2.4.3, as of this writing). You do not need to have it preinstalled, as the tutorial will include instruction on installation if needed.

Older versions of Capistrano will not be covered, but if you have specific questions about an older version of Capistrano, you may ask them during the course of the tutorial.

Why Campfire (instead of e.g. IRC)?

For one thing, Campfire lets you easily paste images and code into the stream of the chat. This lets people follow along without having to jump to external links, potentially losing the context and the flow of the tutorial.

For another thing, Campfire provides transcripts. This means that I can easily email attendees a transcript of the session when the session is finished. (If things go well, and if there is enough interest, I may even offer the transcript for sale later, for a few dollars, to people who were unable to attend.)

If the session were very large (40, 50, or more people) Campfire might not be as good a fit for what I have in mind. But for a group of 10, it’s just about perfect.

Why only 10 people?

This session is just an experiment, to see how well this venue can work for teaching people how to use Capistrano. If it works well, I may experiment with larger groups later. For now, though, ten seems about right for a tutorial session. More than that and I think it would get difficult to give each attendee sufficient attention. I fully intend for these to be hands-on opportunities, where attendees will actually follow along and deploy an application.

Why $10, instead of free, or $100?

As mentioned above, this is just an experiment, not a money-making opportunity (yet!). If there is sufficient demand, subsequent sessions may cost more. The $10/seat is mostly just minimal compensation for the time I'm putting into organizing the session and creating the curriculum.

Also, if this initial experiment were free, the danger would be people signing up without commitment. By requiring people to pay for the privilege of attending, they are more likely to show up, and less likely to be frivolous or merely casually interested.

Why Subversion instead of Git, or CVS, etc.?

Because most Rails devs are still using Subversion. Besides which, once you can deploy from subversion, switching SCM’s isn’t that much of a jump. If there’s enough interest, I may offer another session sometime on Git-based deployment.

What should I expect if I sign up?

Once you sign up and your payment is received, you’ll receive an email with (among other things) a URL to a web page. This web page will initially just have the tutorial’s date and time on it, along with a list of software you should already have installed and configured on your server before the tutorial begins (including Ruby, Subversion, etc.).

A couple of hours before the session starts it will be updated with a URL to the Campfire room, as well as your login credentials to the server, and the location of the Subversion repository hosting the Rails application.

You may sign into the Campfire room any time after the URL is available. The session will start at the indicated time, with a few minutes spent on introductions and waiting for stragglers. The tutorial will then begin and will run for approximately two hours.

Once the tutorial ends, your access to the Campfire chat room and the tutorial server will be terminated. A transcript of the tutorial will be emailed to you.

For people who were unable to attend, the transcript may be made available for a small fee (probably just a few dollars for this first tutorial).

Tentative outline

The following outline is tentative and is subject to change:

Installing Capistrano
Configuring Capistrano for your Rails project
cap deploy:check
cap deploy:setup
cap deploy:cold
cap deploy
cap deploy:rollback
cap deploy:cleanup
cap deploy:migrations
Overriding tasks
Extending tasks
Customizing deployment

Register!

Sound good? Then sign up!