Rails Deployment | 321Capistrano
Once you have a server set up and running smoothly, you need a way to deploy your
application from the repository to the server. The naïve process ofsshing into the
server, updating the code, and restarting the server process gets old very quickly, and
it is error-prone.
Enter Capistrano (http://capify.org/): a framework for scripting interaction with
remote machines. Capistrano started out as a deployment framework (it was origi-
nally called SwitchTower). As people started using it for wider and more varied pur-
poses, it evolved into a general framework for executing commands in parallel on a
set of remote servers. In version 2.0, deployment is only a subset of the functionality
available through Capistrano, and the deployment tools must be explicitly loaded.
Capistrano, like the rest of Rails, follows theconvention over configurationpara-
digm. In general, the more “mainstream” your situation, the less configuration you
will have to write. The framework gives you enough power to do most things you
would want to do, but tries to make the simple situations simple.
The Capistrano 2.0 source code is an excellent example of well-structured Ruby
code. It is hosted in the Rails Subversion repository (http://svn.rubyonrails.org/rails/
tools/capistrano/).
Vlad the Deployer
Of course, as Capistrano grows larger and becomes more general, some people just
want a simple deployment tool. The Ruby Hit Squad released Vlad the Deployer
(http://rubyhitsquad.com/Vlad_the_Deployer.html) as a reaction against Capistrano’s
complexity. It does one thing: application deployment. It uses native programs (ssh
andrsync), as opposed to Capistrano, which depends on the Net::SSH library.
Because Vlad is focused on deployment only, the configuration file can be simpler. It
defaults to one server; Capistrano assumes a large setup—the default deployment
tasks assume separateweb,app, anddbroles. Either solution works well; generally,
Vlad is easier to get started with, and Capistrano will be more flexible for large
projects or those with unusual requirements.
Continuous Integration
Another powerful tool for software development, especially in large teams, is
continuous integration. As a principle, continuous integration comes from the
Extreme Programming discipline. It usually involves a build/test process that hap-
pens either just before or just after each version control commit. If tests fail, an email
is typically sent to the entire team, shaming the offending developer and providing an
incentive to fix the code.