Archive for the 'capistrano' Tag

A basic Git+Capistrano workflow

Saturday, July 7th, 2012

This post has been originally published on the Headshift Labs blog and is reposted here with permission.

~

Here in the London office, we use Git as a Version Control System and Capistrano to manage deployments for almost all our projects: not only Rails, but WordPress and Drupal as well. It’s a well tested tool and the development team has definitely benefited from having a unified way of deploying – regardless of the project language or the server.

As an aside, we already posted about VCS and Git in the past, so if you need an introduction you can head to that post, which despite being a couple of years old is still relevant.

The setup for the most basic applications usually involves two servers: a staging server and a production server. The staging server is used to show the application to the client and as a testbed to get them to accept user stories, while the production server hosts the real thing.

To cater for this scenario, we need to install the Capistrano Multistage Extension, which will allow us to create different deployment recipes for different servers.

We are not yet done, however: all the recipes are based on the master branch, which gives us very limited flexibility: we can only deploy what is on the HEAD of master at the time of running our cap deploy command. In a fast-moving project, with multiple developers working at the same time, it’s very unlikely that this will be what we want. We need more granular control on what we’re deploying.

To achieve this goal, we can create two Git remote branches: staging and production. We can then update the Capistrano configuration so that the recipe for the staging server will deploy the code committed to the staging branch, and the one for the production server will deploy the production branch.

Among other server-specific configurations, we will have to make sure our recipes are referencing the correct branch. This will mean, for example, adding the following line to the staging.rb recipe:

set :branch, 'staging'

This gives us fine grained control over what is deployed: we can merge the master branch into staging to get the latest changes, or just merge a subset of commits, or cherry pick the ones we want. Running cap staging deploy will then transfer to the server only the commits we selected.

The following image shows how a hypothetical repo may look at a given point in time:

 

The typical workflow to deploy the latest changes to staging (supposing we are on the master branch) is:

$ git checkout staging
$ git pull origin staging
$ git merge master
$ git push origin staging
$ cap staging deploy

If you know your Git, you’ll notice some of the commands are presented in their more verbose form. This is meant to make them safer, but if you know what you are doing you may as well just use git push and git pull. The same goes for rebasing, which is a topic worth a post all by itself.

It could be argued that forcing developers to go through the steps each time creates a useful barrier to prevent people from deploying without first thinking about it. On the other hand, it’s a rather long list of commands for a routine task, so it’s a perfect candidate for automation if you trust developers with deploying only when it’s needed.

This is not a fancy workflow and it requires a very minimal setup. It could be seen as standing in between very lean workflows as the one used by GitHub and more structured ones as the gitflow model. It’s not by any means the only workflow we use for our projects, but it’s common enough and it has worked successfully for a number of projects.