capistrano-gitflow_version

= gitflow_version: a Capistrano recipe for git deployment using tags in a multistage environment using MAJOR.MINOR.REVISION.BUILD

The best thing about this recipe is that there is almost nothing to learn -- your cap deploy process barely changes. Gitflow simply adds some tagging/logging/workflow magic to the multistage recipe.

# BEFORE
$ cap deploy              # 'deploy' goes to staging
$ cap production deploy   # 'deploy' goes to production

# AFTER
$ cap deploy
# 'deploy' goes to staging; tagged test-MAJOR.MINOR.REVISION.BUILD
$ cap production deploy
# deploys latest staging tag, or if last tag is a production tag then that, to production
# for specifying the tag by hand add `-s tag=MAJOR.MINOR.REVISION.BUILD`
# tag 'test-MAJOR.MINOR.REVISION.BUILD' goes to production
# tag 'vMAJOR.MINOR.REVISION.BUILD' created; points to test-MAJOR.MINOR.REVISION.BUILD

# BONUS
cap gitflow_version:commit_log
# displays a commit log pushed to staging
# ... alternatively, if you're using GitHub, will open a page using branch compare
cap production gitflow_version:log_log
# displays a commit log of what will be pushed to production

== INSTALLATION

First, install the gem:

gem install capistrano-gitflow_version

Then update config/deploy.rb

require 'capistrano/gitflow_version'

== DETAILS

After experimenting with several workflows for deployment in git, I've finally found one I really like.

• You can push to staging at any time; every staging push is automatically tagged with a unique tag.
• You can only push a staging tag to production. This helps to enforce QA of all pushes to production.

=== PUSH TO STAGING

Whenever you want to push the currently checked-out code to staging, just do:

cap staging deploy

gitflow will automatically:

• if the last tag was a test-MAJOR.MINOR.REVISION.BUILD will automatically increment BUILD
• if the last tag was vMAJOR.MINOR.REVISION.BUILD will ask you what the next tag should be
• create a new tag
• configure multistage to use that tag for the deploy
• push the code and tags to the remote "origin"
• and run the normal deploy task for the staging stage.

=== PUSH TO PRODUCTION:

Whenever you want to push code to production, you must specify the staging tag you wish to promote to production:

cap production deploy -s tag=test-0.8.4.3

gitflow will automatically:

• alias the staging tag to a production tag without the test- prefix
• configure multistage to use that tag for the deploy
• push the code and tags to the remote "origin"
• and run the normal deploy task for the production stage.

=== NOTES:

• you may need to wipe out the cached-copy on the remote server that cap uses when switching to this workflow; I have seen situations where the cached copy cannot cleanly checkout to the new branch/tag. it's safe to try without wiping it out first, it will fail gracefully.
• if your stages already have a "set :branch, 'my-staging-branch'" call in your configs, remove it. This workflow configures it automatically.

== CREDIT

Originally forked from Alan Pinstein's git_deployment repo. Gemified and hacked by Josh Nichols. There wasn't really a license originally, so...

Forked from Josh Nichols's capistrano-gitflow repo. Hacked by Alice Brown. Put under the MIT License. See the LICENSE file.