AutoTagger is a gem that helps you automatically create a date-stamped tag for each stage of your deployment, and deploy from the last tag from the previous environment.
Let’s say you have the following workflow:
- Run all test on a Continuous Integration (CI) server
- Deploy to a staging server
- Deploy to a production server
You can use the
autotag command to tag releases on your CI box, then use the capistrano tasks to auto-tag each release.
gem sources -a http://gems.github.com sudo gem install zilkey-auto_tagger
To contribute, you can fork the github repository.
You can also visit the tracker project
The autotag executable
Installing the gem creates an executable file named autotag, which takes two arguments: the stage, and optionally the path to the git repo:
$ autotag demo # => creates a tag like demo/200804041234 in the current directory $ autotag demo . # => same as above $ autotag demo /Users/me/foo # => cd's to /Users/me/foo before creating the tag
Running autotag does the following:
$ git fetch origin --tags $ git tag <stage>/<timestamp> $ git push origin --tags
AutoTagger comes with 2 capistrano tasks:
release_tagger:set_branchtries to set the branch to the last tag from the previous environment.
release_tagger:create_tagruns autotag for the current stage
require 'release_tagger' # The :stages variable is required set :stages, [:ci, :staging, :production] # The :working_directory variable is optional, and defaults to Dir.pwd # :working_directory can be an absolute or relative path set :working_directory, "../../" task :production do # In each of your environments that need auto-branch setting, you need to set :current_stage set :current_stage, :production end task :staging do # If you do not set current_stage, it will not auto-set your branch # set :current_stage, :staging end # You need to add the before/ater callbacks yourself before "deploy:update_code", "release_tagger:set_branch" after "deploy", "release_tagger:create_tag"
Assume you have the following tags in your git repository:
The deployments would look like this:
cap staging deploy # => sets branch to ci/01 cap production deploy # => sets branch to staging/01
You can override with with the -Shead and -Stag options
cap staging deploy -Shead=true # => sets branch to master cap staging deploy -Stag=staging/01 # => sets branch to staging/01
- DOES NOT work with capistrano ext multi-stage
- It will accept invalid tag names (if you specify a tag name with a space, it will blow up when you try to create the tag)
I have this working on a single project, and there is a fairly complete spec suite, but use at your own risk. It’s probably worth setting up on a demo project before adding it to a production repo.
Over time it would be nice to add other scms like subversion as well, so that you have a single way of tagging, regardless of scm.
Special thanks to Brian Takita, who gave me an initial implementation. Another useful link is http://codeintensity.blogspot.com/2008/06/changelogs-and-deployment-notification.html.
About the Author
BiographyMore Content by Pivotal Labs