How To: Capistrano w/ same server repository

Mon, June 30, 2008 - 169 comments

Sometimes when you deploy with Capistrano you have just one server that acts in many roles (web, app, database all in one). When I have a client that has a single server for a single app I'll often setup an SVN repo to be accessed via svn+ssh. This causes a little bit of a hickup when you try to deploy with Capistrano because you need to tell the server to checkout the code from itself, but that isn't the same access pattern you need when you are committing things to the svn as a developer. Of course you could deploy_via :copy but that takes a bit longer, an easier route is to have one SVN access pattern for the server to checkout the code, and a different one for yourself as a remote machine. Here is how:

Here is an example deploy.rb file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


require 'mongrel_cluster/recipes'

# setup vars used later in the script
set :application, "yourdomain_com"
set :user, "brian"
set :runner, user
set :main_server, "www.yourdomain.com"

# source code repository
set :local_repository,  "svn+urdomainssh://www.yourdomain.com/repository/#{application}/trunk"
set :repository, "file:////repository/yourdomain_com/trunk"

# ssh port is 29361
set :port, 29361

# set the location for the app on the server
set :deploy_to, "/var/www/apps/#{application}"

set :deploy_via, :checkout

# setup servers
set :domain, main_server
role :app, main_server
role :web, main_server
role :db,  main_server, :primary => true

# post deploy tasks
desc "Link in the production symlinks"
task :after_update_code do

  # link the database.yml file
  run "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml"
  
end #end after_update_code

after "deploy", "deploy:cleanup"

Notice the directives :local_repository and :repository, the first tells Capistrano how to access the source code repository from your local machine (the one you are deploying code from). The second tells it how to access the repository from the server. We use a local file checkout on the server since we don't want to have to mess with private keys, and self referential connections on the server.

Rails, Ruby, Capistrano