Capistrano and the Rails Application Lifecycle

Using Capistrano

It’s All About the Farm and Environments cover most of the background on why and where you would use Capistrano. In this section, we’ll tackle the actual use of Capistrano above and beyond those straightforward deployments. What if you want to deploy your application only to your staging server, even though both the staging and production servers are listed in the deploy.rb file? What if you discover a serious error on your most recent production-server push, and you need to undo it ASAP? Those are exactly the kinds of questions we’ll answer here.

Built-in Tasks

Capistrano comes with a bunch of built-in recipes—some of which we’ve already used. (We used the setup and deploy actions with the cap command in A Basic Deployment, for example.) If you locate your Capistrano gem, you can even look up the source code for these built-in recipes. The path should be something like /path/to/gems/capistrano-1.2.0/lib/capistrano/recipes/standard.rb, for the adventurous among you.

If you look through the documentation, you’ll notice that a few assumptions have been made for each of the built-in tasks:

• Roles have been defined and assigned:

  • app for the application servers

  • web for the web servers

  • db for the database servers, with exactly one of the listed servers identified as the primary

• You manage your FastCGI processes with the built-in spawner and reaper scripts (which are in the script/process folder of your application).

The roles are pretty much required. They aren’t ...