Conceptric
  1. Capistrano works!

    Effective version control and Capistrano managed deployment has hugely enhanced my workflow and quality.

    Deploying even my simplest web applications was a complicated matter:

    1. Log in as a privileged user.
    2. Create the domain deployment directory.
    3. Export the application code from Subversion.
    4. Update the file ownership and privileges.

    For Wordpress I also had to export code for each theme or plug—in to the required locations. So I decided to improve the situation. I’ve changed the way my Wordpress sites are handled in Subversion; haven’t moved to Git yet like the rest of the world, and I am using Capistrano to manage the deployment.

    Capistrano is a Ruby based remote task manager, the most commonly used tasks being for web application deployment. Obviously the original target was Ruby on Rails, but many people use it for PHP. It uses Secure Shell (SSH) as the preferred method for logging into remote servers; all communication is then encrypted.

    What follows isn’t a full set of instructions on deploying PHP with Capistrano, HostingRails.com provide a useful piece and you should look at the Capistrano manual, these are my thoughts. May be something more detailed might come later… but no promises.

    Managing the source code.

    The Subversion repository for each blog project uses a vendor branch of the Wordpress source code and svn:externals properties to import the required themes and plug—ins from their respective repositories.

    Wordpress updates are integrated into the vendor branch and then into any of my projects without disturbing any custom code changes. For merging changes I can strongly recommend using the svn_load_dirs.pl script, it allows you to maintain file history and makes the whole process easier.

    And now deploy.

    I currently have my main Subversion and Web servers on the same machine, leaving me with the option to use the local file:// protocol to retrieve the application files. I wanted to make my deployment script more universal so that I could use it for the production and development platforms.

    The obvious choice was the svn+ssh:// protocol I normally use, but in addition to SSH, I use public key authorisation with passphrases for all of my servers. A frequent problem was that Capistrano didn’t like asking for passphrases for remote machines.

    Since the repository and deployment machines are one in the same, I can use SSH forwarding to provide a recursive tunnel by defining the following in the deploy.rb script.

    set :user, "me" 
    ssh_options[:forward_agent] = true
    

    The variable user tells Capistrano which user has SSH access and the forward_agent option allows the same SSH credentials for the tunnel to the Subversion server. Now , if your svn user is different from the ssh user you’ll need to add another couple of things:

    set :svn_user, username
    set :repository, "--username #{svn_user} svn+ssh://hostname/repository/#{application}/trunk"
    

    These variables enabled me to use the default deployment tasks for my application, there’s no need to override them, just use the before_ and after_ hooks to define additional functionality.

    The result.

    I have two WordPress blogs deployed on my server using Capistrano and Subversion for remote control, including custom themes and third—party plugins. I’ve already redeployed to incorporate changes and everything has worked perfectly.

    Next… Drupal?

    There are no comment for this post at the moment. Please feel free to let me know what you think.

    What do you think?

    XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

    You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.