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"
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?