Capistrano is a remote server automation and deployment tool written in Ruby.
-
Using Capistrano with Dynamic Virtual Environments
The Problem At Metal Toad we use Capistrano to facilitate deploying projects. It allows us to support different environments, pulling and pushing databases and files, for all sorts of products.
-
Pond Life Ep.2
Hello Everyone!
-
Fixing "no such file" error in Capistrano upload()
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"))".
-
Faster Database Backups via Drush! Plus Capistrano Integration
When working with Drupal sites, Drush is your go-to tool. This post is going to focus on the drush sql-dump command. This allows you to export your database to a sql file, so you can restore it later. This can be particularly useful when you are working in a development environment and need to deploy a site to production for the first time. Or when you start work on a new clients existing site, you need to export their live database and download it to your local environment.
-
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?
-
Simplify your WordPress Deployments
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.
-
Integrating Compass with a Git / Capistrano deployment workflow
When we added the Compass CSS authoring framework to our projects, new wrinkles appeared in the deployment process. Committing the artifacts to Git was used for our first prototypes, but is unsuitable for team projects because it's a sure-fire way to introduce merge conflicts. Running compass on the server (either with Cap or the Drupal module) is appealing, but a minority of our projects deploy to hosts without the ability to install Compass. Rather than support multiple strategies, we decided on executing Compass locally on the workstation running Capistrano. Changes are needed to several files:
-
Capistrano authorization How-To
Cap has made our deployments simple, fast, and reliable. However, it can only access services you yourself have access to. Establishing this access for the first time can be a bit of a trick.
-
Deployment with Capistrano Part 2: Drush integration
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. From capify.org: 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.