Git deployment workflow using tags

by David on 12/08/2010

Post image for Git deployment workflow using tags

Up until now we’ve been hacking git branches to handle our master -> QA -> staging -> production workflow.

This meant that the typical development to production deploy required a sequence like:

git pull --rebase
git push
git checkout staging
git pull --rebase
git rebase master
git push
cap staging deploy
- check site in staging -
git checkout production
git pull --rebase
git rebase master
git push
cap production deploy

This was a tiresome process and, something told me, a rather unnecessary one. It was time to investigate Git tags.

The terminology used in the capistrano config file is rather misleading like it.

set :branch, "staging"

When you dig into the source, branch has a much broader meaning.

# You may set :branch, which is the reference to the branch, tag,
# or any SHA1 you are deploying, for example:
#
#   set :branch, "master"

Josh Nichols had beaten me to a better way of handling this, and packed in a handy gem. Enter Capistrano Gitflow (Rubygems | Github)

With this set in our Capistrano config (see the README for capistrano-gitflow) we can now tag and deploy to production or staging simply using two git, and one cap command

git commit -m "magical rainbows"
git push
cap staging deploy

With that last cap command the gitflow gem will hook into the deployment logic, prompt you to tell it something about the commit and then create a tag pointing to the current HEAD of the branch you are on, it then handles all the fetching and pulling of tags and finally passes the SHA into the normal capistrano deployment process.

If I was feeling extra mean to my co-workers, I’d hook the continuous integration server into the process and make it so you can only production tag a release that has built successfully.

The only concern I have regarding this plugin now, is how do I deal with the dearth of tags this is going to create in our Github repo?

Next post: