Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Tools
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker
Pivotal Labs

Introducing AutoTagger – easy multi-stage deployment tagging with git

Pivotal Labs
Monday, March 30, 2009

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.

Installation

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

Capistrano Integration

AutoTagger comes with 2 capistrano tasks:

  • release_tagger:set_branch tries to set the branch to the last tag from the previous environment.
  • release_tagger:create_tag runs autotag for the current stage

Example config/deploy.rb file:

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:

  • ci/01
  • staging/01
  • production/01

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

Known Issues

  • 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.

Acknowledgments

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.

Happy tagging!

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Pivotal Labs

New York Standup 10/7/2008

Pivotal Labs
Wednesday, October 8, 2008

Interesting Things

When you specify a gem from a custom source, and it has dependencies on a separate source, you need to list both sources in geminstaller.yml.

This comes up when you are installing a gem from github and that gem depends on other gems from rubyforge. You can specify multiple sources by adding more –source attributes.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

sub

Alex Chaffee
Tuesday, October 2, 2007

Yellow Submarine

(Update — version 0.3 released 2-Oct-07. Release notes are here.)

We use subversion for our source control. We love it. But we’ve noticed a few flaws, and a few weeks ago I decided I’d had enough and wrote a wrapper for it that fixes a few of the most glaring ones:

  • Externals get messed up pretty frequently. If you remove or rename an external, the old one gets left around on disk, and if you convert an external to a “real” directory or vice versa then the next update simply fails.
  • Externals are updated in series, not in parallel, meaning that if you have a lot of externals your updates can take an excruciatingly long time.
  • Externals are updated even if they’re frozen to a specific revision number, which wastes even more time on update.
  • If you want a clean checkout — say, for an automated build — the only way to do it is to do a full checkout, even if 99% of the files are already there on disk.
  • The co command is not compatible with the convention of putting files under /trunk, requiring you to type out your whole repository URL followed by /foo/trunk foo
  • The name of the executable is hard to pronounce — either “ess vee enn” or “seven”, but nobody says “seven” except when they’re saying “seven up”, which is, I admit, a pretty good pun, but come on, how much cooler is it to say, “sub”?

The current version of sub fixes all of the above (except for converting directories to and from externals, and I’m going to make that work pretty soon).

Install with

sudo gem install sub

Help text is below the fold.

Usage:
  sub co project_name [dir_name]
    checks out [base_url]/project_name/trunk into ./project_name (or dir_name if specified)
  sub up [dir]*
    fast update (default command, so 'sub dir...' or just 'sub' work too)
  sub help
    prints this message

Options:
  --verbose, -v
      lots of output
  --quiet, -q
      no output at all except for errors
  --help, -h
      prints this message
  --clean, -c
      'up' command removes all unversioned files and directories
  --url [base_url]
      sets base repository url for 'co' command
      (default is ENV['SUB_BASE_URL'] or ENV['SVN'] or svn+ssh://rubyforge.org/var/svn)
  --version
      prints release version

Using sub up took the update time for my main project from 16.5 sec to 3.5 sec (we have about 20 externals).

If you have a common repository like we do, set it in your .bash_profile like this

export SUB_BASE_URL=https://svn.mygreatcompany.com/svn

and then

sub co foo

will run

svn co https://svn.mygreatcompany.com/svn/foo/trunk foo

Otherwise it’ll default to Rubyforge’s repository.

If you want to see what commands it’s executing, --verbose will show you (it indents the system commands so they’re easier to spot).

Enjoy! And please suggest improvements of any kind.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (783)
  • rails (117)
  • testing (90)
  • ruby (86)
  • ruby on rails (71)
  • jobs (62)
  • javascript (59)
  • techtalk (44)
  • ironblogger (42)
  • rspec (39)
  • bloggerdome (34)
  • productivity (34)
  • activerecord (30)
  • rubymine (30)
  • git (29)
  • gogaruco (29)
  • nyc (27)
  • design (24)
  • mobile (23)
  • pivotal tracker (22)
  • process (21)
  • cucumber (21)
  • jasmine (19)
  • ios (18)
  • tracker ecosystem (17)
  • webos (17)
  • objective-c (17)
  • fun (16)
  • android (16)
  • palm (16)
  • ci (16)
  • "soft" ware (16)
  • bdd (15)
  • tdd (15)
  • cedar (15)
  • rails3 (14)
  • performance (14)
  • css (14)
  • gem (13)
  • mouse-free development (12)
  • selenium (12)
  • goruco (12)
  • bundler (12)
  • api (12)
  • keyboard (11)
  • meetup (11)
  • railsconf (11)
  • nyc-standup (11)
  • capybara (10)
  • mac (10)
Subscribe to gem Feed
  1. ←
  2. 1
  3. 2
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Tools
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >