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 hard to set up, ...
Get Capistrano and the Rails Application Lifecycle now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.