The FastRemoteCache is a custom deployment strategy that specializes the standard RemoteCache strategy. It works just like the RemoteCache, but instead of actually copying the cache to the final release directory, it uses a custom “copy.rb” script to hard link the files. This allows the copy stage to be very fast.
For small applications, and especially for those that aren’t bundling vendor/rails, this won’t make much of a difference. But for large applications the speed-up will be significant.
-
Capistrano 2 or later (www.capify.org)
The FastRemoteCache, as the RemoteCache, assumes that your source repository is accessible from both your local (deploying) host, as well as the remote (target) hosts. If either of these is not true, you will not be able to use the FastRemoteCache strategy.
Furthermore, it assumes that you have Ruby (1.8.6, preferably) installed on the target machines. If it is not installed in a standard location, you can set the :ruby variable to the location of the ruby executable.
When using this with Rails applications, all you need to do is install this as a plugin in your application. Make sure your Capfile has a line like the following:
Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }
It should be just before the line that loads the ‘config/deploy’ file. If that line is not there, add it (or rerun “capify .”).
If you are not using this with a Rails application, you’ll need to explicitly load recipes/fast_remote_cache.rb in your Capfile.
Next, tell Capistrano to use the fast_remote_cache deployment strategy by putting the following line in your config/deploy.rb (or Capfile, if you aren’t deploying a Rails app):
set :deploy_via, :fast_remote_cache
Lastly, if you want to exclude certain directories or files from being deployed, set the copy_exclude variable:
set :copy_exclude, %w(test .git doc config/database.yml)
The copy_exclude array can also include glob patterns, if you want to get tricky.
For the fastest possible deploys:
-
Always deploy as the same user. If you’re part of a team where everyone can (and does) deploy, create a new user (e.g., “deploy”) and set it up so that your team can all log in as this user. Make sure this user also has read access to your source code repository.
-
Avoid sudo if at all possible. set(:use_sudo, false), and then make sure that the deploy user has sufficient permissions to start and stop the mongrels, write to the necessary directories, etc.
-
Disable the “group_writable” setting: set(:group_writable, false). This is only necessary when you have multiple users deploying.
-
Don’t include Rails (or other large libraries) in your application. Yes, it is convenient to include them, but they bloat your app and make checkouts and copies much slower. You have to balance convenience in development versus speed of deployment. Find a compromise that works for you.
This code is released under the MIT license, and is copyright © 2008 by 37signals, LLC. Please see the accompanying LICENSE file for the full text of the license.