Understanding Deployment Strategies
Deployment strategies are just ways for capistrano to get your code onto your target servers, ready to rock and roll... there are currently four built-in strategies, some are better than others for large projects, some better than others for difficult network setups, be aware that they all have their pros and cons.
strategy.deploy!
it's only fair that you know what is going on under the covers.. the following headings explain how each one works, alternatives and the pros and cons of each. ( at least, in this author's opinion)
The deployment strategy is defined in the slightly misleadingly named :deploy_via variable (which I often confuse with the :gateway variable)
Examples:
set :deploy_via, :checkout set :deploy_via, :copy set :deploy_via, :export set :deploy_via, :remote_cache
Deploy Strategy :checkout
Both checkout, and export should be familiar to users of subversion - since they directly reflect subversion commands.
In this case, your code is deployed to the server by capistrano issuing a "checkout" command, for example
# Example Settings set :deploy_to, /u/apps/example set :repository, svn+ssh://test.example.com/repository/trunk # Example Command as run by Capistrano on your target server [host1.example.com]# svn checkout svn+ssh://test.example.com/repository/trunk /u/apps/example/releases/20081008215259/
Deploy Strategy :copy
The copy strategy is for those who struggle with a firewall or network problems stopping their deploy target servers not being able to access their SCM repository.
The copy strategy is designed to take a local copy (e.g. on the machine where capistrano has been invoked) of the code, and compress it somehow (You can use the :copy_compression variable outlined below to customise how) and copy it over scp to the target servers, where it is extracted to your :deploy_to location, to the usual "...../releases/20081008215259/" style directory.
The copy strategy comes with its own set of variables:
set :copy_strategy, :export set :copy_cache, true set :copy_cache, "/tmp/caches/myapp" set :copy_exclude, [".git/*", ".svn/*"] set :copy_compression, :gzip # Also valid are :zip and :bz2
Deploy Strategy :export
Both export, and checkout should be familiar to users of subversion - since they directly reflect subversion commands.
In this case, your code is deployed to the server by capistrano issuing an "export" command; which for those unfamiliar extracts a copy of the HEAD, minus the .svn metadata directories - rendering this an "exported" copy, rather than a working, versioned copy. "Exported" directories can not be "updated" from the repository with the likes of "svn update"
An example follows:
# Example Settings set :deploy_to, /u/apps/example set :repository, svn+ssh://test.example.com/repository/trunk # Example Command as run by Capistrano on your target server [host1.example.com]# svn export svn+ssh://test.example.com/repository/trunk /u/apps/example/releases/20081008215259/
Deploy Strategy :remote_cache
Remote cache works by using a working copy of your code stored in a 'cache' on the target server(s) to speed up deployment.
Typically this uses the :repository_cache variable to identify where the cache will be stored, but this defaults to :shared_path + 'cached-copy/' (which is :deploy_to + 'shared/' by default)
# Example Settings set :deploy_to, /u/apps/example set :deploy_via, :remote_cache set :copy_exclude, [".svn", ".DS_Store"] set :repository, svn+ssh://test.example.com/repository/trunk
# Example truncated, capistrano does something clever to decide whether to create this repository cache, or just sync it [host1.example.com]# svn update /u/apps/example/shared/cached-copy # Then *ONE* of the following, depending whether or not you specified :copy_exclude [host1.example.com]# rsync -rp --exclude=".svn" --exclude=".DS_Store" /u/apps/example/shared/cached-copy/* /u/apps/example/releases/20081008215259 [host1.example.com]# cp -RPp /u/apps/example/shared/cached-copy/ /u/apps/example/releases/20081008215259
Remote Cache works by targeting this directory, making sure it matches your :repository (in case you have changed the value of that variable) and updating it to the latest version, be that "git pull" or "svn update", will depend on your SCM.
It then proceeds to copy this code base to your :deploy_to location using either the "cp" command, or if you have specified exclusions (see below) rsync. Assuming this was all successful... capistrnao then runs the rest of your deployment script.
Extra variables:
set :copy_exclude, [".svn", ".DS_Store"]