Last week, this error brought many of our deployments to a screeching halt. "upload via sftp failed on metaltoad.com: Net::SFTP::StatusException (Net::SFTP::StatusException open ...releases/20130408223054/drupal/ sites/all/themes/boilerplate/css/compiled/default.css (2, "no such file"))".
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?
Deploying code to WordPress installations has always been a bit of a struggle. Although there are a few WordPress plugins that help in deployments, there hasn't really been a simple WordPress deployment process. It's about time that process became a lot easier.
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/domain.com-error.log)
- 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.
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
- 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.
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.