imedo Development Blog

Capistrano 2 supports custom deploy strategies. You basically just have to implement the “deploy!” and “check!” methods in your class and you’re good to go.

But how do you tell Capistrano to use your strategy?

I looked into the code and found no way of setting your strategy. So I changed capistrano, that it’s possible to set the strategy. When I asked Jamis Buck to pull the change, he suggested that I just set the strategy directly. This approach wouldn’t need any changes to to code base.

Well then we went ahead and did just that. So here’s the code for setting your custom deploy strategy (Don’t forget to require the file with your code)

set :strategy, Capistrano::Deploy::Strategy::DifferentAppRootRemoteCache.new(self)

It works like a charm.

Popularity: 2% [?]

I know: PHP deployment is really easy. You just copy the files to the server and you’re good to go. Why bother with something like Capistrano for WordPress deployment? Well, we’re using Rails and we’re spoiled children, and because we can. That’s why. Ok, to be honest: I don’t like the copy/checkout the files and upload them deployment.

There already is a good tutorial for WordPress deployment with capistrano but it’s for Capistrano 1 and SVN. I’ll show you the neccessary modifications to use cap 2 and git. It’s easy, really.

Ok, then let’s go:

Local directory structure:

base_dir
 - .git (Git Repository)
 - Capfile
 - config
    - deploy.rb
 - public
   - *.php (etc...)

Server side Capistrano structure:

app-dir
  - current => link to releases/2008....
  - shared
    - wp-config.php
    - uploads (wp-uploads-folder)
  - releases
    - 2008.....
       - public/ (wordpress goes here)

So you have to configure your Apache (or lighty or whatever) to use app-dir/current/public as Docroot.

My deploy.rb file looks like this:

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

set :application, "mywordpress-blog"

set :deploy_to, "/var/www/apps/#{application}"
set :deploy_via,    :copy
set :copy_strategy, :checkout
set :user,          'deploy'
set :use_sudo, false
set :keep_releases, 3

set :scm, :git
set :repository, "/Users/hvolkmer/Projects/mywordpress-blog/"
set :branch, "master"

role :app, "blog.example.com"
role :web, "blog.example.com"
role :db,  "blog.example.com", :primary => true

desc "This is here to overide the original :restart"
deploy.task :restart, :roles => :app do
  # do nothing but overide the default
end

desc 'Link to upload folder, cache and config'
task :after_symlink do
  run "cp #{deploy_to}/#{shared_dir}/wp-config.php #{deploy_to}/#{current_dir}/public/wp-config.php"
  run "ln -nfs #{deploy_to}/#{shared_dir}/uploads/ #{deploy_to}/#{current_dir}/public/wp-content/uploads"
end

Notice that I symlink the uploads folder but copy the wp-config.php file. That’s ugly but neccessary, because php resolves the basepath of the target file and not the symlink when it tries to include other files. (So it would end up trying to include files from the shared directory). I’m told that in the latest PHP that bevaiour is fixed.

Using the deploy_via “copy” model doesn’t require to install git on the target system.

I was thinking about using vlad the deployer for that task because it is supposed to be simpler and leaner and all that. But as it is currently lacking the copy-deployment model and required git on the server side, I just stayed with capistrano which turned out to be the simpler solution for for us in this case.

So always remember: Pick the right tool (for you and) for the job and be happy with it.

Popularity: 20% [?]