A little over a year ago I wrote up some instructions for deploying drupal sites using capistrano. It’s proved a popular entry, still getting a good bit of traffic, but in the time since I wrote it Capistrano 2 has joined us and my techniques have moved on, so it seemed high time I updated the instructions with some new ones.

As before, I’m going to presume that anyone reading this already has capistrano installed and has shell access to their server. If you need help with the former, I’d recommend stopping by the Capistrano website, and for the latter you should probably talk to your hosting company.

My approach is to keep each site’s assets (modules, themes, etc) within that site’s folder, and then store each site in version control (git or subversion). In common with capistrano-based rails deployments, I then have the site’s files and images stored in a shared folder and symlinked into the site, so that they can be preserved between deployments.

To get started go into the folder for the site you want to be able to deploy (eg. /path/to/drupal/sites/mysite.com) and type at the command line:

mkdir config
capify .

That will create the basic files for deployment, which you will then need to edit with your configuration details. I start by opening the file config/deploy.rb and deleting everything in it, so as to start with a blank slate. I then put in some overrides to capistrano’s default deployment methods so that they work better with drupal:

set :asset_folders, %W(images files)
 
namespace :deploy do
  desc "Link the asset folders from the shared folder into our site"
  task :finalize_update, :except => { :no_release => true } do
    logger.info 'finalizing update with custom method'
    run "chmod -R g+w #{latest_release}" if fetch(:group_writable, true)
 
    asset_folders.each do |asset|
      run "rm -rf #{release_path}/#{asset}"
      run "ln -nfs #{shared_path}/#{asset} #{release_path}/#{asset}"
    end
  end
 
  desc "Set up the expected application directory structure on all boxes"
  task :setup, :except => { :no_release => true } do
    run <<-CMD
      umask 02 &&
      mkdir -p #{deploy_to} #{releases_path} #{shared_path}
    CMD
    asset_folders.each do |asset|
      run "mkdir #{shared_path}/#{asset}"
    end
  end
 
  task :set_permissions, :except => { :no_release => true } do
    # do nothing
  end
 
  task :restart do
   # do nothing 
  end
end

You then need to set some basic configuration, so also in deploy.rb place:

set :deploy_to, '/path/to/your/drupal/sites'
 
# Make sure this is the domain name of your app as it is 
# what your sites folder will be named
set :site_name, 'staging.scodigo.com'
role :web, "your.server.com"
set :current_path, "#{deploy_to}/#{site_name}"
set :shared_path, "#{deploy_to}/shared/#{site_name}"
set :repository, "svn://your.svn.com/path/to/repos/trunk"

With that in place you’re all ready to go. But there was an extra step I decided to add this time around. Since I am frequently setting up new staging/test sites and often need to upgrade them to new versions of drupal, I wanted to be able to install and update the drupal files using capistrano.

To do that, I wrote a recipe that will grab the tarball for a given release, unpack it and install it, without wiping out an existing sites folder. To add that you will need to put the following code into your deploy.rb file:

namespace :drupal do
  desc <<-DESC
  Grab the specified version of drupal and install it
 
  This presumes that the variables drupal_version and drupal_path have been set
  DESC
 
  task :install do
    run "cd #{shared_path} && curl -O http://ftp.drupal.org/files/projects/drupal-#{drupal_version}.tar.gz"
    run "cd #{shared_path} && tar xzvf drupal-#{drupal_version}.tar.gz"
    run "rm -rf #{shared_path}/drupal-#{drupal_version}/sites"
    run "cd #{drupal_path} && rm -rf !(sites)"
    run "mv #{shared_path}/drupal-#{drupal_version}/* #{drupal_path}"
    run "mv #{shared_path}/drupal-#{drupal_version}/.htaccess #{drupal_path}/.htaccess"
    run "rm -rf #{shared_path}/drupal-#{drupal_version}"
  end
end
 
after "deploy:setup", "drupal:install"
set :drupal_path, File.join(deploy_to, '../')
set :drupal_version, "5.8" # Or whatever version you want to install

(You can download a copy of the combined deploy.rb file here)

Now, to set up your drupal site you just need to change directory to your site and type and command line:

cap deploy:setup

and to deploy a new version:

cap deploy

In practice, I tend to use these techniques in combination with the Capistrano Multistage extension, so that I can deploy a site to a staging server first, and then a production server. I’d highly recommend that approach, but for now will leave it as an exercise for the reader.

Please note that this technique is also designed to support a multi-site drupal set up, but hasn’t been extensively tested in that context. It should work, but no guarantees!

Recommend this post:

It’s always fascinating to see how applying good practice in one area can lead to unforeseen benefits. The article on version control with subversion in the latest issue of A List Apart is a fine example of just that. Not only is the use of version control a good way to manage your own projects, it’s a vital enabler for significant shifts in working practices and management styles.

Those of us who’ve been building software for a while and keep tabs on best practice in that arena are unlikely to see version control as anything new—CVS has been around since the 80s, after all—but it’s arguably only now really coming into its own as we see social practices, work practices and coding practices coming together. And of course we’re finally starting to see promising mac subversion clients, which has to help.

On a related note, John Gruber noted a couple of days ago:

It strikes me as an odd coincidence that two serious Subversion clients would debut at a time when many developers are starting to switch away from Subversion to distributed revision control systems such as Git and Mercurial.

You could argue that it isn’t really a coincidence at all. Perhaps the fact that technologists have found a superior model for managing versions, and matured it to a point where many of us are starting to use Git is a consequence of really getting to grips with what tools like subversion allow. We’ve become good enough at communicating the features and flaws of one generation of tools that we can both provide friendly tools, and simultaneously witness a more widespread migration to their progeny?

Recommend this post:

• Meerkat | Code Sorcery Workshop
  "Meerkat is an easy to use SSH tunnel manager built specifically for the Mac."
  (tags: mac software ssh tunnel)
• bkkeepr | Track your reading and bookmark on the go
  A nice little reading tracker service. You send them a message on twitter with the ISBN number of the book you’re reading, and they do the rest.
  (tags: books library reading twitter)
• mySociety » TheyWorkForYou video - seeking
  One of a series of blog entries from MySociety about their great new video features on TheyWorkForYou. Not only can you track what’s going on in parliament, you can watch very specific parts of the proceedings thanks to some clever work on their part
  (tags: flash mysociety parliament participation video)
• BBC Topics: How It Works
  An overview of the system the BBC have been using to bring together related content from across their huge network of websites
  (tags: aggregation bbc topics)
• MOO.com | Announcing the MOO API
  Really looking forward to seeing what people build with this
  (tags: api moo printing)
• Yahoo! Address Book API Delivered (Yahoo! Developer Network blog)
  Another step towards being able to import/export contacts without making users give away passwords
  (tags: api dataportability yahoo)
• Masquerade Rails OpenID Server
  My post on building an open id server in rails still gets a lot of traffic, but I’ve not been able to keep the code as up to date as I’d like. I’ve not tried this option yet, but it seems worth a look
  (tags: openid rubyonrails server)

Recommend this post:

Reading Stowe Boyd’s thoughts on plurk and writing my own post on the topic I began to wonder how much work it would really be to add a timeline view using something like the Simile Timeline library.

As a quick proof of concept I saved my twitter homepage to my laptop and added a little javascript. As well as calling in the timeline library from http://simile.mit.edu/timeline/api/timeline-api.js and using the first javascript iso8601 code I found through google, I added:

  jQuery(document).ready(function() {
    jQuery('body').prepend('<div id="my-timeline" style="height: 150px; border: 1px solid #aaa"></div>');
    var eventSource = new Timeline.DefaultEventSource();
    evts = [];
 
    jQuery('.hentry_hover').each(function (index, elem) {
      var $elem = jQuery(elem);
      var dateEvent = new Date();
      dateEvent.setISO8601($elem.find('.published')[0].getAttribute('title'));
      var evt = new Timeline.DefaultEventSource.Event(
         dateEvent, //start
         dateEvent, //end
         dateEvent, //latestStart
         dateEvent, //earliestEnd
         true, //instant
         $elem.find('.content a:first').text(), //text
         $elem.find('.entry-content').text() //description
      );
      eventSource.add(evt);
    });
 
    var bandInfos = [
      Timeline.createBandInfo({
        width:          "100%", 
        intervalUnit:   Timeline.DateTime.MINUTE, 
        intervalPixels: 10,
        eventSource: eventSource,
      }),
    ];
    tl = Timeline.create(jQuery("#my-timeline")[0], bandInfos);
  });

and pretty quickly I had a basic timeline view at the top of my twitter page.

Obviously this isn’t a very practical solution, but it’s an indicator of just how easy it would be to build something, whether as a GreaseMonkey script, or a proper client that uses the API and maybe loads tweets using AJAX as someone scrolls through the timeline.

Recommend this post:

• mad.ly – Rails 2.1 Time Zone Support: An Overview
  Helpful overview of one of a number of great improvements coming up in the next version of rails
  (tags: rubyonrails timezone)
• Mapping Xenophobic Attacks in South Africa | White African
  More great work being undertaken using the Ushahidi engine
  (tags: africa ict4d nptech ushahidi)

Recommend this post: