So what are some of the advantages that you get from using this RESTful development approach?

While REST is an excellent fit for database-backed Web applications, it is probably an even stronger fit for Web services. The REST architecture provides an excellent platform for providing services. After all, Web services are essentially APIs that let you manipulate some form of resource. Rather than create another layer on top of HTTP, as the SOAP Web service protocol does, REST-based Web services rely on the existing functionality of HTTP to provide Web services.

Because REST uses what is already built into HTTP, rather than layering another semantic layer on top of it as SOAP does, REST is a much simpler architecture for implementing Web services. The most popular consumer-facing Web services, such as those provided by Amazon, Google, Yahoo, and others, all offer a REST-based interface. REST is more popular than SOAP today for implementing commercial Web services. Considering the book example again, you could easily imagine a Web service API that used URLs identical to those that a browser uses to get HTML content — in Rails, the same RESTful controller actions with xml at the end of the request URL is enough to get you full XML Web service responsiveness. This gets into the next topic of interest related to REST, that of representation.

When you request a page using a RESTful architecture, the page that is returned can be considered a representation of the resource that you are requesting. However, think of an HTML page as just one possible representation of any given resource. Other representations might include an XML document, a text document, or a block of JSON-encoded JavaScript.

Using the RESTful architecture, you would request a different representation of a resource using the same method, but by passing a different piece of metadata to the server, thus indicating the representation that you would like to have returned. For example, the following two requests would both be routed to the same controller and action method:

http://www.myapp.com/book/5
http://www.myapp.com/book/5.xml

The first request would return an HTML representation of the book resource. The second request would return an XML representation of the book resource — Chapter 5 showed the Rails mechanism for easily managing this. The ease of adding output mechanisms is another advantage of a RESTful architecture. The same controllers and actions can be used to deliver a variety of response representations — including HTML, RSS, and XML. This makes implementing Web services in a RESTful architecture extremely easy, and again maintains a consistent design style.

As I mentioned earlier, with the release of Rails 2.0, REST has been adopted as the standard architecture for a Rails application. What does that mean? Rails provides a set of tools that makes building RESTful-style applications easy for the developer.

When you use the scaffold generator to automatically create the CRUD skeleton of your application for a given resource, the controller and action methods generated are RESTful. In versions of Rails that supported REST prior to version 2.0, you had to explicitly say that you wanted your scaffolding to be REST-based by using the scaffold_resource generator. In just a bit, you'll get a chance to use the scaffold generator to create a REST implementation for a resource in a real Rails application.

> rails restful_cookbook

> cd restful_cookbook
> ruby script/generate scaffold Recipe
    exists app/models/
    exists app/controllers/
    exists app/helpers/
    create app/views/recipes
    exists app/views/layouts
    exists test/functional
    exists test/unit
    create app/views/recipes/index.html.erb
    create app/views/recipes/show.html.erb
    create app/views/recipes/new.html.erb
    create app/views/recipes/edit.html.erb
    create app/views/layouts/recipes.html.erb
 identical public/stylesheets/scaffold.css
dependency model
    exists app/models/
    exists test/unit/

    exists test/fixtures/
    create app/models/recipe.rb
    create test/unit/recipe_test.rb
    create test/fixtures/recipes.yml
    exists db/migrate
    create db/migrate/001_create_recipes.rb
    create app/controllers/recipes_controller.rb
    create test/functional/recipes_controller_test.rb
    create app/helpers/recipes_helper.rb
     route map.resources:recipes

route map.resources:recipes

map.resources:recipes

map.resources:projects do |project|
  project.resources:tasks
end

class RecipesController < ApplicationController
    # GET /recipes
    # GET /recipes.xml
    def index
        @recipes = Recipe.find(:all)
        respond_to do |format|
            format.html # index.html.erb
            format.xml { render:xml => @recipes }
        end
    end
    # GET /recipes/1
    # GET /recipes/1.xml
    def show
        @recipe = Recipe.find(params[:id])
        respond_to do |format|
            format.html # show.html.erb
            format.xml { render:xml => @recipe }
        end
    end
    # GET /recipes/new
    # GET /recipes/new.xml
    def new
        @recipe = Recipe.new
        respond_to do |format|

format.html # new.html.erb
        format.xml { render:xml => @recipe }
    end
end
# GET /recipes/1/edit
def edit
    @recipe = Recipe.find(params[:id])
end
# POST /recipes
# POST /recipes.xml
def create
    @recipe = Recipe.new(params[:recipe])
    respond_to do |format|
        if @recipe.save
            flash[:notice] = 'Recipe was successfully created.'
            format.html {redirect_to(@recipe) }
            format.xml {render:xml => @recipe,
                               :status =>:created,
                               :location => @recipe }
        else
            format.html {render:action => "new" }
            format.xml  {render:xml => @recipe.errors,
                               :status =>:unprocessable_entity }
        end
    end
end
# PUT /recipes/1
# PUT /recipes/1.xml
def update
    @recipe = Recipe.find(params[:id])
    respond_to do |format|
        if @recipe.update_attributes(params[:recipe])
            flash[:notice] = 'Recipe was successfully updated.'
            format.html {redirect_to(@recipe) }
            format.xml {head:ok }
        else
            format.html {render:action => "edit" }
            format.xml  {render:xml => @recipe.errors,
                               :status =>:unprocessable_entity }
        end
    end
end

# DELETE /recipes/1
    # DELETE /recipes/1.xml
    def destroy
        @recipe = Recipe.find(params[:id])
        @recipe.destroy
        respond_to do |format|
            format.html {redirect_to(recipes_url)}
            format.xml  {head:ok }
        end
    end
end

<h1>Editing recipe</h1>
<%= error_messages_for:recipe %>
<% form_for(@recipe) do |f| %>
    <p>
        <%= f.submit "Update" %>
    </p>
<% end %>
<%= link_to 'Show', @recipe %> |
<%= link_to 'Back', recipes_path %>

<h1>Listing recipes</h1>
<table>
    <tr>
    </tr>
<% for recipe in @recipes %>
    <tr>

<td><%= link_to 'Show', recipe %></td>
    <td><%= link_to 'Edit', edit_recipe_path(recipe) %></td>
    <td><%= link_to 'Destroy', recipe,:confirm => 'Are you sure?',
   :method =>:delete %></td>
</tr>
<% end %>
</table>
<br />
<%= link_to 'New recipe', new_recipe_path %>

<h1>New recipe</h1>
<%= error_messages_for:recipe %>
<% form_for(@recipe) do |f| %>
    <p>
        <%= f.submit "Create" %>
    </p>
<% end %>
<%= link_to 'Back', recipes_path %>

<%= link_to 'Edit', edit_recipe_path(@recipe) %> |
<%= link_to 'Back', recipes_path %>

Rails naming conventions for databases and models can be summarized as follows:

It's not just legacy databases that violate this naming structure, by the way. Most commonly, a Rails database might use a non-standard name for a foreign key where the tables have multiple links, or where the connection has a more specific logical name in the context of the relationship then the foreign model has in general.

If your legacy database has more egregious departure from Rails' expectations, you can modify where Rails looks for database information at two different levels. The ActiveRecord::Base class has a couple of properties that allow you to change database defaults throughout your application (see Table 12.3. This is useful if you are only using the legacy database (or, I suppose, if you are creating a new database, but don't like Rails conventions). These properties are most usefully set in the environment.rb file so they take effect when your application is loaded.

However, there are many circumstances where changing global defaults will not be effective in mapping the legacy database. Your alternative option is to set the table names and primary keys on a model by model basis.

Within each model, the class properties set_table_name and set_primary_key can be used to customize the naming convention mapping that model to a database table. A sample usage would look like this:

class Book < ActiveRecord::Base
    set_table_name "book_data"
    set_primary_key "book_key"
end

Remember, the use of these properties is not limited to dealing with legacy databases, but with any naming oddities you choose to impose on databases you create.

Non-standard choices in the naming of foreign keys is noted in the declaration of the relationship in the ActiveRecord classes — the naming changes need to be noted on both sides of the relationship. The options for each kind of relationship are listed in Table 12.4.

This set of methods, options, and properties should allow you to link up with any database that gets thrown at you.

Even if you are working with a legacy database, you may still want to create a second database using Rails conventions for data that is specific to your Rails application. Just to name one possible situation, the legacy database could be an existing book catalog shared by many different applications, and it might make sense to keep your user information in a database specific to your Web application. Rails can manage the case where there is more then one database in the system, but there are some tricks to managing it properly.

In the database.yml file, set up your new Rails database as the default development, test, and production environments, and set up the legacy database with a differently named set of environments. Continuing with the assumption that the legacy is some kind of centralized catalog, that would give you catalog_development, catalog_production, and catalog_test, all pointing to some version of the legacy database.

Now, each ActiveRecord model in your application will point to a exactly one table in one of the two databases. The models that point to the Rails database don't need any special treatment, but the models that point to the legacy database are going to need to explicitly mention to Rails. The best way to handle this if you have multiple legacy ActiveRecords is to create a common parent class for all of them. The parent class only needs to contain the line of code that establish the connection, for example:

class LegacyBase < ActiveRecord::Base
  self.abstract_class = true
  establish_connection "catalog_#{RAILS_ENV}"
end

There are two additional things to note. The abstract_class line is there to tell Rails that LegacyBase really is an abstract class that will have no instances, specifically that keeps ActiveRecord from searching the database for a table named legacy_bases. In the next line, the #{RAILS_ENV} within the string ensures that the Rails application will always connect to the appropriate version of the database for the environment, whether you are in production, development, or test mode.

You do lose a couple of Rails automation features when using a second database, whether or not it's legacy. The automatic features of the Rails test environment assume the regular database connections. This means, for example, that the rake test:prepare task which automatically reloads the database from the schema won't run on your second database. You also won't get automatic loading of fixtures. The fixture loading is also kind of balky in any case where the table name does not match the ActiveRecord model name — meaning any case where you've changed the naming default.

You can work around this by changing the naming defaults in the test classes. I recommend doing this all at once in the test_helper.rb file:

def self.set_fixture_classes
  set_fixture_class:legacy_database_table => LegacyClassName
end

You can include as many table/class pairs as you want in the call to set_fixture_class. To actually load the fixtures in the legacy test database, you need to explicitly load them. Again, include the following method in the test_helper.rb file:

def load_external_fixtures(*tables)
  fixture_root = File.join(RAILS_ROOT, 'test', 'fixtures')
  Fixtures.create_fixtures(fixture_root, tables) do
    LegacyBase.connection
  end
end

This works in all ways, except that you don't get the special helper methods that Rails uses to allow direct access to fixtures, you'll need to explicitly find the data from the database. Also, you need to be a little careful with the ordering of the tables — if there's a hard foreign key constraint you'll need to put the required class before the class that requires it.

You'll also need to explicitly remove the classes, again in the test helper. Foreign key constraints will need to be in the reverse order for teardown then for load.

def teardown_fixture_data(*classes)
  classes.each do |klass|
    klass.delete_all
  end
end

Then you need to explicitly call this in your test classes:

class LegacyTest < ActiveSupport::TestCase
  set_fixture_classes
  def setup
    load_external_fixtures("table_1", "table_2")
  end
  def teardown
    cleanup(Class2, Class2)
  end
end

The reason why you want to do the declaration in the helper rather than in the individual classes is simply that a single test will likely load multiple fixture classes, and it's easier to only have to type the messy table/class pairs once. You should also be able to explicitly call the set_fixture_class at the class level in the test helper, rather than just inside a method.

It is actually possible to define a relationship between two ActiveRecord models that live in different databases, as long as ActiveRecord does not need to perform an SQL JOIN command to mange the data. In practice, this means that one-to-one or one-to-many relationships are fine, but many-to-many relationships are problematic.

You can work around this limitation by creating a proxy object in your local database. The local table would only generally only have one column, the remote ID of the legacy model. You also need a join table that joins the proxy id to the legacy model id. That lets you set up a structure like this (these class declarations would of course normally be in their respective app/model files):

class LegacyProxy
  belongs_to:legacy_model
end
class LegacyModel
  has_one:legacy_proxy
end

This sets up an ordinary one-to-one relationship between the proxy in your local database, and the actual model in the legacy database. Now, a class that wants to have a many-to-many relationship with the legacy model can declare a relationship with the proxy — the join table here is whatever name you give to the join table:

class LegacyModelGroup
  has_and_belongs_to_many:legacy_proxies,
       :join_table => "legacy_join_table"
      def legacy_models
        legacy_proxies.collect {|p| p.legacy_model}
      end
end

Long term, you might want to make your life easier by defining accessors on the proxy object that defer to the legacy model, but you certainly don't need to do that to make this setup useful.

Rails has built-in support for sending outbound e-mails using either SMTP or SendMail. You can configure the mechanism you prefer by adding a single line to your application's config/environment.rb file. If you want to use SMTP, add this line to your environment.rb file:

config.action_mailer.delivery_method =:smtp

Or, if you want to use SendMail for your outbound e-mails, add this line:

config.action_mailer.delivery_method =:sendmail

The config.action_mailer call will actually trigger a class method on ActionMailer::Base. In most cases, you won't want to put this setting in the global environment.rb file.

Your email settings will probably change for each Rails environment — your production mail server is probably not accessible during development, and you probably don't want to be sending live emails during testing. Place the mailer configuration in the conifg/environment directory in the file corresponding to the environment you want to configure.

If you choose SMTP, you also have to add some additional code to configure your SMTP settings. You will add a block of code similar to the following to set up your SMTP options:

config.action_mailer.server_settings = {
   :address => "my.smtpserver.com",
   :port => 25,
   :domain => "My Domain",
   :authentication =>:login,
   :user_name => "username",
   :password => "password"}

By default the test environment in config/environment/test.rb sets the mail settings like this:

config.action_mailer.delivery_method =:test

This prevents test mails from being sent out, and instead puts the mail messages in a class property of each ActionMailer class, named deliveries.

You can also configure whether Rails will consider it an error if the mail message can't be sent, this setting is off in the development environment:

config.action_mailer.raise_delivery_errors = false

After you have your e-mail server properly configured in the environment.rb file, the next step in adding e-mail support to your application is to generate a mailer model using the script/generate mailer command.

> ruby script/generate mailer RegistrationNotice
       exists app/models/
       create app/views/registration_notice
       exists test/unit/
       create test/fixtures/registration_notice
       create app/models/registration_notice.rb
       create test/unit/registration_notice_test.rb

If you look at the model that is generated, you see that it is very similar to ActiveRecord-based models. It should look like this:

class RegistrationNotice < ActionMailer::Base
end

As with the ActiveRecord model classes, this class extends a Rails class, ActionMailer::Base, which provides the core of the class's functionality. The unit test file that is created is a simple stub, similar to what you get with the ActiveRecord generator.

Now that you have a RegistrationNotice mailer, you have the classes that you need to begin writing the e-mail code. Within the RegistrationNotice class, you add mailer methods that correspond to individual e-mail types that you want to support. In the mailer method, you set up the e-mail message by assigning values to variables representing attributes of the email to be sent. Let's look at an example of what a user registration e-mail mailer method might look like in the RegistrationNotice model that was created in the previous step:

def user_registered(user)
  recipients user.email
  subject = "Activate your Account"
  from = "[email protected]"
  body:recipient => user.name
end

In this method, you are setting four variables related to the e-mail message: the recipients, subject, from, and body. There are actually many more options that can be set for an e-mail, as described below:

In order to actually generate the message and send it, you don't call the mailer method directly — Rails creates a couple of wrapper methods that use the mailer method as part of the creation and delivery of the actual email message. These messages are of the form create_user_ registered and deliver_user_registered. The create version merely creates the email message object, while the deliver version creates the object and immediately sends it.

If you use the create version, you then send it using a structure like the following:

email = RegistrationNotice.create_user_notified(user)
RegistrationNotice.deliver(email)

This allows you to further process the email object before delivery if you want. Otherwise, the one line version just looks like this:

email = RegistrationNotice.deliver_user_notified(user)

If the body attribute of your mailer method is a hash, then Rails expects the actual body of the mail message to be in an ERb template located at app/views/registration_notice/user_notfied.html.erb. That's if you are sending an HTML email, the file name of the template for a text email would more properly end .text.erb or .plain.erb.

Rails will implicitly set the outgoing context type of the mail message to match the type extension of the ERb file, so choose wisely. Rails also allows you to have multiple templates for a single message, for example, both user_notified.text.erb and user_notified.html.erb. If Rails notices multiple templates, the mailer will assemble the message into a multi-part message, and let the user's client sort it out, giving the user control over whether to view the message in HTML or plain text.

This works nicely with attachments, which are specified in the mailer method using the attachment method. The :content_type is the MIME type of the attachment, the :body is the actual data, often acquired via File.read, and the :filename can also be specified. Multiple attachments can be added to a single message.

Writing code to receive e-mails through Rails is not any more difficult than it is to send e-mails. In fact, because there are fewer options to specify, it is probably easier to write the code to receive e-mails. Within an ActionMailer::Base subclass, if you specify a method named receive, it will be called with the email message already parsed into an email object exactly like the ones you would create in order to send an email. For example, the following snippet takes in a message and adds it to the database attached to the person who sent it.

def receive(email)
  person = Person.find_by_email(email.to.first)
  person.emails.create(:subject => email.subject,:body => email.
   body)
end

The tricky part is coaxing your email server to cause this method to be invoked when an email is received. The general form of this problem is well out of scope, however if you can access the email address you will be watching via IMAP, you can use the Ruby Net::IMAP library to fetch mail. The following code was adapted from the Rails wiki:

require 'net/imap'
imap = Net::IMAP.new('email_host_name')
imap.authenticate('LOGIN', username, password)
imap.select('INBOX')
imap.search(['ALL']).each do |id|
  message = imap.fetch(id, 'RFC822')[0].attr['RFC822']
  RegistrationNotice.receive(message)
  imap.store(message_id, "+FLAGS", [:Deleted])
end
imap.expunge()

A similar script could use NET::POP3. All you need to do is use a cron job or something similar to run this script periodically — note this script deletes emails as it reads them, which you might want to modify if you think you'll need access to the messages later on.

Capistrano is distributed as a Ruby gem. As of this writing, the current version is 2.3.

> gem install Capistrano

To use Capistrano, certain things need to be true about your development and deployment environments. You need to be using some kind of source control, Subversion is the default, but many other popular systems are also supported, including Git, CVS, Mercruial, and Perforce.

On the server side, you need at least one server to start, and you need a network address that can access that server. Obviously, the server needs to be able to run Rails. Less obviously, the server needs to be able to communicate via SSH. Capistrano sends commands to servers via a standard Unix SSH shell. The preferred target of a Capistrano deploy is Linux, although Mac OS X servers also should meet the standard. If your server is running MS Windows, you'll need to run Cygwin or some other Unix shell program to be able to use Capistrano. Capistrano prefers to have the login to the remote machines managed with public keys, although you can use password access if you'd prefer. If you have multiple servers, the same password must work on all of them.

Once Capistrano is installed, you start using it by typing the command capify . from your Rails root directory.

capify .
[add] writing './Capfile'
[add] writing './config/deploy.rb'
 [done] capified!

As you can see from the snippet, Capistrano will create two files, the Capfile's primary purpose is to load the deploy.rb file, which contains the actual deployment recipe. The Capistrano deployment file is just a Ruby file, with some custom structure behind it to allow you to create your own build tasks in addition to the standard ones.

The standard deployment file has a number of different settings and variables you'll need to adapt to the specifics of your application. The two most important are right at the top:

set:application, "set your application name here"
set:repository, "set your repository location here"

The application name is arbitrary, but is used as the root directory of your application files on the servers being deployed to. The repository variable has a URL for the code repository, which must be visible from the server being deployed to, not the development machine being deployed from.

You can also specify the remote directory location and the source control system being used, but Capistrano provides a default value for both (the default source control system is Subversion).

If you need to specify the username or password to your Subversion repository, you can use the same set syntax the attribute names are :svn_user and :svn_password. Instead of taking a string as the value of the property, you can also pass a block, which enables the following workaround if you don't want to place the Subversion password in the text file.

set:svn_password, Proc.new do
Capistrano::CLI.password_prompt('enter password: ')
end

The next most important thing you need to tell Capistrano is the location and types of your servers. The default in the file looks like this:

role:app, "your app-server here"
role:web, "your web-server here"
role:db, "your db-server here",:primary => true

Capistrano allows you to group your servers into roles. The naming of the roles is basically arbitrary, but the default convention separates your application into Web servers and database servers, or application servers that manage both. Normally, you'd start with on server, place it's address in the :app role, and comment out the other two lines. As your deployment gets bigger, you'd add additional servers to that line.

When you get to the point where different servers are playing different roles, then you split the list as needed. Capistrano's normal behavior is to run a command on all servers listed in all roles. Specific tasks, however, can be customized to run for a specific role or roles — it would make no sense to run database migrations on a server that didn't have a database, for example.

A role named :gateway, if it exists, is expected to have a single server, and Capistrano will route access to all other servers through that machine.

The first thing you need to do when you add a new server to your deployment is run the Capistrano setup task:

cap deploy:setup

The general form of a Capistrano command is very similar to a Rake command, cap is invoked, the first argument is the task to run, further options pass various options to the command.

The setup command creates a directory structure for your application. Figure 12.1 shows the directory structure.

Figure 12.1. Directory structure for your application

Each deployment you make to a server using Capistrano gets it's own new directory under releases. The top level directory has a symbolic link called current that always points to the most recent release directory. Files that would be shared across deployments are placed in the shared directory — Capistrano also manages the appropriate links from each deployment to the shared directories.

The setup command must be run on any server before you can deploy to it, however there is no harm from running it on servers that have already been set up.

Assuming you are starting from a basic, single server deployment, the first deploy task you run is a cold deploy, meaning that a Web server is not already running on the server.

cap deploy:cold

This performs three tasks, each of which can also be triggered as separate Capistrano tasks:

Once you have the Web server running on the remote box, then you've entered the realm of hot deployment:

cap deploy

A hot deployment is the same as a cold deploy except that the database migrations are not performed (you need cap deploy:migrations to specifically do a hot deploy with database migrations. Also, instead of deploy:start, it calls deploy:restart, which calls the standard Rails script/process/reaper. This should stop anything that looks a Rails server process, then start them up again. It's designed to work with the spawner script. Again, you can customize behavior to match your own needs.

Should you notice a problem in the deploy and you need to go back to the previous known state, you run the following command:

cap rollback

This command deletes the current codebase, and points the current symbolic link back to the previous version, then restarts the Web server using the same deploy:restart task used in a hot deployment.

This section has covered the most commonly used Capistrano commands, here are a couple of others that you might find useful:

There are two ways to customize Capistrano's behavior, setting variables and creating your own tasks. Many tasks depend on variables that can be set either at the command line or in your Capistrano recipe. Capistrano variables are either environment variables or Capistrano variables. Environment variables are declared in your script using the following syntax:

ENV["FILES"] = "app/views, app/models"

And are added at the command line using the syntax:

cap invoke COMMAND="script/process/reaper"

Capistrano variables are set in the recipe as follows:

set:svn_user, "hmason"

Such variables are set at the command line using one of the two forms:

cap deploy -s svn_user=hmason
cap deploy -S svn user=hmason

The difference between the two forms is when the variable set is applied. The lower-case form is applied after the recipe file loads, so that the command line setting overrides any setting in the actual recipe script. The upper-case form loads the command line variables first, so any setting in the script overrides the command line.

Setting variables is nice, but the real power of Capistrano comes in the ability to write your own custom tasks and assign them as dependencies to any Capistrano task. The syntax for writing a new task is extremely similar to Rake. Here's a sample task that generates a database.yml file — it assumes you have some way of specifying the database host for each server and that YAML has been loaded:

desc "create database.yml"
task:create_database_yml,:roles => [:app,:db] do
  yaml = {
     :production => {
         :adapter => mysql
         :database => my_production
         :host => find_host($HOSTNAME) ## This is your method to
  write
         :username => 'fred'
         :password => 'dref'
      }
  }
  put YAML::dump(buffer), "#{release_path}/config/databse.yml",
     :mode => 0664
end

As in Rake, the desc method sets the comment for the next task definition to come down the pike. Unlike Rake, task dependencies are not set in the task definition. Instead, the task definition allows you to optionally specify which server roles the task applies to — in this case, the task only applies to servers that have database. Also, whereas if you define a Rake task multiple times, it will combine the definitions, a second definition of a Capistrano task will completely override the original task.

Capistrano has a couple of handy helper methods that manage server side activities, the previous snippet shows put, which places content in a file. Another commonly used one is run, which runs a shell command on all the servers affected by the task.

As with any build system, it's helpful to automatically set up dependencies so that a task will always run before or after another task. In Capistrano, this is done by placing a declaration to that effect in the recipe script. The general form is one of the following

after 'existing_task', 'new_task'
before 'existing_task', 'new_task'

You can include more than one new task by continuing to add the tasks as further arguments to the command. As is probably clear, new tasks specified as before are guaranteed to run before the actual task, and new tasks specified as after will always run after the existing task. You can have both a before and after on the same task, and the before and after declarations do compose, so you can have more than one of them for the same task and they will not override each other. Instead of a list of tasks, you can also pass a block.

This just scratches the surface of what you can do with Capistrano, each deployment is different, and getting your needs exactly right is not trivial. Check out Capistrano online for more complex details.