If there's one tool which streamlined our production workflow it must be git. We started using it about a year ago - like everyone else. We joined Github for our own projects, and the open source ones, too. But one post from Bryan Helmkamp helped us getting the server setup streamlined, particularly, the multistage Setup. So this is mixing gits' and capistranos' best aspects. Why Multiple Stages? For many, bliss is when you can deploy with one command. This is great at the start of the project and the default for capistrano. The problem is that as soon as the project has a certain size, the speed at which one can deploy actually slows stuff down. This is because everyone has to wait with adding stuff until the deployment is done and agreed upon by the customer. How it works Now with multiple stages, at one point we decide that a number of features are complete and can be tested by users. We update the staging branch and deploy that with capistrano to the stage server. There, the customer can check out the new features while we continue developing. When we reach an agreement we can deploy we update the production branch from the staging branch and deploy that. So let's jump in.

Installation

We are using the capistrano-ext gem and the gitworkflow.rb from Brian's post in lib/tasks to standardize branching for deployment, and the actual deployment process. If you want to set up a new project to use those methods, you need to create

• config/deploy.rb
• config/deploy/*.rb
• lib/tasks/gitworkflow.rb
• Capfile

into your application. You can look here for some explanation - basically, you have to 'capify' the application and create deploy/envs.rb for each environment. If it’s aready capified, check the differences.The project should be in sync with a master branch (on github in my example).

Setup

This deployment setup requires two extra branches on github. This can be done with:

git checkout -b staging             # creates a branch locally
git push origin staging             # pushes the branch to github
git checkout -b production          # same for the production branche
git push origin production
git checkout master
git branch -d staging
git branch -d production

The local branches are deleted after each deploy.

For the following to work, the git config needs to be right. Much of this (maybe all of it) will be set correctly when cloning the project from github. Check:

git config --list

If the variables are not set right you can use

git config remote.origin.url git@github.com:simplificator/yourapp.git
git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git config branch.master.remote origin
git config branch.master.merge master

Or alternatively, perform a new git clone git@github.com:simplificator/yourapp.gitin another directory and work from there.

Then, the deployment targets need to be set up.

cap staging deploy:setup
cap staging deploy
cap production deploy:setup
cap production deploy

It’s likely you need to go to the server to set up the databases. One way of doing this is going to the deployment location into the current checkout and then running

rake db:create:all

We need

• yourapp_production
• yourapp_staging

Here you need to do some badly documented magic:

• get gems
• setup apache for passenger
• run the migrations

Workflow

• Branch for working.
• Add and commit in your branch. Stash everything else.
• Unit test.
• Checkout master, pull, and merge your branch.
• Unit test.
• Push the master up.

Staging

When you’re happy with what you’ve done you can stage your work:

rake tag:staging
cap staging deploy:migrations

or the shortcut rake deploy:staging. When you do that, the staging branch is replaced with your local master branch.

Production deploy

When you want to push the staging branch into production, do

rake tag:production
cap production deploy:migrations

When you do that, the production branch is replaced with the staging branch from github.

Fixing

When you have to do a fix for the production server:

export BRANCH=hotfix
rake branch:production

hackhackhack…

git commit
export BRANCH=hotfix #(unless it's the same shell still)
rake tag:staging BRANCH=hotfix
cap staging deploy

After this, your staging server is running your corrected production code. If it works, you can redeploy this using

rake tag:production
cap production deploy

from the same shell (because of the BRANCH variable). Then the stage server is free again to take the more recent code.

New development doesn't affect that process.

Conclusion

I'm sure a lot more of this could be automated (like the initial db setup) - I'm not claiming we got all edges out of the process. But it can give you some ideas on how to do it yourself. For us, it has rendered our deployments much more professional, without adding too much cruft (after the initial setup of the first project). The stage server helps us to train ourselves with deployments of complicated software involving many moving parts until they run smoothly and will execute on production without trouble.