Parse / extract server settings from your Capfile

One interesting thing that has evolved from our use of Capistrano is the configuration files have become the de-facto documentation hub for a project's server connection details. (We do maintain inventory data elsewhere, but for the developer in the trenches, config/deploy/prod.rb is the first place to look). A question arose: How to parse the settings out of these files?

Avoid Potholes When Deploying Drupal Sites to Media Temple Virtual Private Servers

I recently had occasion to set up a new Drupal site on a dedicated virtual private server on Media Temple (dv 4.0). Everything was going swimmingly until I deployed the site and tried to reach it via the IP address.

The result was the install.php page, even though my settings file was uploaded and had the correct settings for the database.

To make matters more frustrating, the log files were not located in the standard place (/var/log/httpd/

Deployment with Capistrano Part 2: Drush integration, Multistage, and Multisite

In my last post, a basic intro to to running cap deploy was presented. Now, let's look at some more advanced scenarios. (See Part 1 for the actual task definitions described here).

  • Multistage: Deploy to different environments (such as testing vs. production).
  • Drush Integration: Use the power of Drush to extend Cap's reach into Drupal's internals.
  • Multisite: Run many sites from a single code base.

Capistrano: Drupal deployments made easy, Part 1

I'm a big fan of having an automated deployment process. It's really the web development analog to the "one step build process", as described in the Joel Test. In the past I have used various shell scripts to perform this task, but I have recently become a convert to Capistrano (or "cap" for short). With Capistrano, uploading your code to the test server is as simple as typing cap deploy. When you're ready to launch in production, it's just cap production deploy.


Simply put, Capistrano is a tool for automating tasks on one or more remote servers. It executes commands in parallel on all targeted machines, and provides a mechanism for rolling back changes across multiple machines.

In detail, here are the features that got me hooked. There's a lot more that cap can do, and I'll describe some more tricks in part 2 of this post.

  • Atomic deployments with error checking. Cap uses a set of symlinked directories, and the links are updated during the final step. It also won't allow a deployment to keep plowing ahead if an intermediate step fails. This makes your deployment atomic; it will either fail or succeed entirely.
  • Fast rollback. If something does go wrong, getting back to the previous state is as simple as cap deploy:rollback.
  • Parallel execution. If you use multiple servers in a load-balanced environment, cap can make managing them easier.
  • Multistage deployments. "Stages" are different server instances of your code. You may have different servers for development, content entry, and production. With the Multistage extension, cap can share code for common tasks between these stages.

Stage-specific Drupal settings with local_settings.php

The decision to store settings.php in your version control system can be sticky. On one hand, there may be application-specific settings you would like to manage (perhaps the session lifetime, for example). On the other hand, it's a bad practice to store passwords in VCS, and some settings are host-specific. Perhaps you'd like to disable CSS aggregation on your development stage, or enable memcached only on your production stage.

Ready for transformation?