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.
Capistrano comes with a bunch of built-in recipes—some of which
we’ve already used. (We used the
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 hard to set up, ...