As a development team, we’ve taken that same core value of making things easier and applied it to our software development & deployment workflow. Over time, we’ve progressively improved our process. We’re now at the point where we’re happy with it, and I wanted to share what we’ve been up to.

The Typical Flow

Let’s assume I’m using GitHub and Pivotal Tracker and I’ve just completed a story. What’s next? Push my changes up to GitHub, click Finish on my story, wait for the build to go green, deploy to staging. Then, click Deliver on all the stories that have just been deployed. Other stories were most likely ready to be delivered as well, so I’ll check that they were actually included in the deployment, and then Deliver them in Tracker.

The typical flow goes like this:

1. Commit the changes to my story
2. Push to GitHub
3. Click Finish on story in tracker
4. Wait for green build
5. Deploy to staging
6. Click Deliver in Tracker

That’s not really that bad. I’m lazy though. If something can be automated, I want it to be automated. For instance, the deployment process should be automatically handled by my Continuous Integration server.

If we take this to the next step and automate our build and deployments as described in Robbie Clutton’s Building Confidence post, we can reduce that flow to this:

1. Commit the changes to my story
2. Push to GitHub
3. Click Finish on story in tracker
4. Wait for green build
5. Click Deliver in Tracker

Let’s assume we’ve done that. That’s a nice improvement, as deploys will happen automatically whenever there’s a green build. That in itself is amazing.

But, what if we could reduce the steps in my everyday flow to this?

1. Commit the changes to my story
2. Push to GitHub

I want that!

A Streamlined Flow

Here’s the basic idea: tie the commit message to the Tracker Story ID. This enables all kinds of functionality that will get us down to that two step process.

GitHub & Pivotal Tracker Integration

GitHub supports integration with Pivotal Tracker. Dan Podsedly blogged about this back in 2010. You just tag your commits with Tracker Story IDs, and GitHub automatically comments on your story with the commit message. And, most importantly, it will click Finish on the story for you.

First, configure the Pivotal Tracker service hook on GitHub.

Once this is enabled, you can start tagging your commits to use the hook. The syntax for your commit message is pretty simple. Add the following at the end of your commit message:

[(Finishes|Fixes|Delivers) #TRACKER_STORY_ID]

So, if you just fixed a CSS bug for story #35192613:

When you push to GitHub, the post-receive hook will then call back to Tracker and put a comment on the story with a link to the commit on GitHub:

At this point, we’ve eliminated step 3 from above. Now our workflow looks like this:

1. Commit the changes to my story
2. Push to GitHub
3. Wait for green build
4. Click Deliver in Tracker

Honestly, that’s a pretty nice workflow. If I’m diligent about tagging each commit with the Tracker Story ID, GitHub will handle Finishing the story for me. It’ll also add a comment to the story, so others can take a look at the commit related to the story. Technical PMs especially appreciate this, since their curiousity about what changed is easily satisfied by just clicking on the comment in the story.

But I want more. I want to automate steps 3 and 4.

Deliver Stories Automatically

Pivotal Tracker has an API hook to deliver all finished stories. However, it’s not what we’re looking for. If our CI server calls that API hook after a green build, it’s possible for other stories to have been finished in the meantime that will not be included in the deploy. So, calling this API endpoint will just cause false positives.

A side-effect of tagging all your commits with Tracker Story IDs is that the git log now contains a nice little list of stories that have been finished. This makes it trivial to automate delivery of only the stories that have been deployed.

Unpakt was keen to share the script that makes this happen. They’ve thrown it up as a gist:

#!/usr/bin/env ruby

# gem 'pivotal-tracker'
require 'pivotal-tracker'

TRACKER_TOKEN = "..."
TRACKER_PROJECT_ID = "..."

PivotalTracker::Client.token = TRACKER_TOKEN
PivotalTracker::Client.use_ssl = true

unpakt_project = PivotalTracker::Project.find(TRACKER_PROJECT_ID)
stories = unpakt_project.stories.all(:state => "finished", :story_type => ['bug', 'feature'])

staging_deploy_tag = `git tag | grep staging | tail -n1`

stories.each do | story |
  puts "Searching for #{story.id} in local git repo."
  search_result = `git log --grep #{story.id} #{staging_deploy_tag}`
  if search_result.length > 0
    puts "Found #{story.id}, marking as delivered."
    story.notes.create(:text => "Delivered by staging deploy script.")
    story.update({"current_state" => "delivered"})
  else
    puts "Coult not find #{story.id} in git repo."
  end
end

Using the pivotal-tracker gem, the script finds all Finished stories in your Tracker project, and looks for a commit in the git log with that Story ID. If it finds one, it marks the story as Delivered.

It also adds a note to the story:

Our New Development Workflow

So, here’s what our development workflow now looks like:

1. Commit the changes to my story (including the Tracker Story ID in the commit message)
2. Push to GitHub

GitHub will mark my story as finished, and add a comment. CI will then run. If there’s a green build, it will deploy to staging. The deploy script will then run the deliver_stories script shown above, and all stories that have been deployed will be marked as delivered.

This is really, really nice. Having this much of the process automated for me just makes my life easier. It also gives our PM much quicker feedback about what’s happening. It’s very easy to forget to click Finish on a story, or deliver stories that weren’t deployed, or forget to click deliver on stories that were. This workflow eliminates these concerns.

Caveat

For this to work properly, the script that deploys to staging must checkout the same SHA as the green build from CI. If the git log shows commits from after the green build, some stories may be marked as Delivered when they haven’t actually made it through a green build and been deployed.

Caution

This workflow is not for every team. For example, it may be that your team functions better with developers verifying that each story is actually available and working on the staging environment before clicking Deliver in Tracker. No Product Manager wants to try to accept a story only to find that it’s not actually available on the staging environment. It may also be that on your project “Deployed” is not the same as “Delivered”.

You should only consider adopting a flow like this if your project is of a nature where deploys are easy, everyone on the team is playing along, and you can agree that “Deployed” and “Delivered” are one and the same.

The workflow described in this post has been working perfectly for months at Unpakt. We initially ran into the problem described above in the Caveat section, because our CI server running our deploy script while HEAD was checked out instead of the green build’s SHA. We haven’t had any stories accidentally marked as Delivered since we resolved that with TeamCity’s Snapshot Dependency feature.

Unpakt is hiring!

Unpakt is a small team with solid financial backing, led by a highly successful entrepreneur. They are creating an intense but fun and respectful culture and are looking for talented people to join their team. Check out their job listings!

The post Level up your development workflow with GitHub & Pivotal Tracker appeared first on Pivotal Labs.

JetBrains’ TeamCity has all that, and more!

To be fair, TeamCity is missing some things that Jenkins has. However, I don’t remember what they are because I’ve never used some of the deeper features of Jenkins. One thing TeamCity doesn’t support well is running builds for multiple branches dynamically.

That said, I’m a huge fan of TeamCity. Here’s why.

TeamCity understands your tests. It uses custom formatters for RSpec, Cucumber, TestUnit and Shoulda. This means you get more than just a pass/fail on the build. You get a count of the tests that have run. You also get a count of the tests that failed. Seeing these numbers gives me a warm and fuzzy feeling that I don’t get with any other CI tool I’ve seen.

Because it understands the tests it’s running, it can keep track of them. For each spec, or cucumber step, it knows how many times it’s passed, and how many times it’s failed. And, it shows you the relevant stacktrace for each failure. You can also get statistics on a particular spec or step, like so:

It also knows what commit introduced a new failure. Here’s a shot of TeamCity showing a spec failure. The spec description is shown. Below that is the stacktrace in maroon. And to the right, it is showing that the spec first failed in build #532 with andre’s commit. The spec is still failing 105 builds later in build #637. It’s easy to see the stacktrace from both the first failure and the current failure. And yes, that spec has been broken since September 2011.

TeamCity makes it super easy to investigate what is making a build slow. Here’s a list of tests for the bundler gem, sorted by duration. You can filter, sort, and search the tests to analyze what’s going on.

You also get some interesting statistics at the build level:

The insight and analysis that TeamCity makes possible is extremely compelling. After using TeamCity for a few years, I used Jenkins for a a few months. I really missed all of the features above, and felt a lot less connected to my tests.

Other things I find to be very useful:

• Immediate feedback if a test fails during a build. The build will go red as soon as the first test does.
• If a failing test is fixed in a newly running build, it’ll let you know.
• Besides the awesome insight into your tests, TeamCity has support for larger teams. Users can set or take responsibility for a broken build or individual test. So, it’s easy to keep your team informed about who is working on what.
• RubyMine integration, including pre-tested commits.
• TeamCity is free for 20 build configurations and 3 slave agents.

Full list of features: www.jetbrains.com/teamcity/features

Here’s the demo environment: teamcity.jetbrains.com

DISCLAIMER: I do not work for JetBrains, nor are they sponsoring this post. I do, however, love their products.

The post TeamCity is pretty cool, you should totally check it out appeared first on Pivotal Labs.

• BitBucket now has Git support. Unlimited private repos for free.
• If you’re using RVM in a shell script, it’s a good idea to call it with sh -c. RVM does weird things to your shell, and we’ve seen it exit the calling process unexpectedly. Do something like sh -c "rvm exec gem install chef" to safely use RVM.
• Kris mentioned that when writing complex migrations, you should consider testing them. You can write a test that asserts on the state of the DB before and after the migration runs up and down. Sounds like a pretty good idea to me.
• Firefox 9 will have support for the CSS font-stretch property. Finally! See this bug report from 1999.

Help!

• We were seeing one to two seconds of clock drift every twenty seconds on a VM running Ubuntu. If you start seeing this on your VMs, do not use ntpdate to fix it. Install the guest additions from your VM software. It’ll set up the clock to sync with the physical clock on the host machine. Much nicer!

The post [Standup][NYC] Standup 10/6/2011 — Github competition appeared first on Pivotal Labs.

• Jon Berger and Adam Berlin recommended checking out Rails ERD.
• Josh K tells us that Nitehawk Cinema is the hip new place to see movies and be seen. And eat and drink while doing so. It’s under the river and through the beards.
• Adobe bought Typekit and PhoneGap! Here’s a CNET article about it! Who knew CNET was still around?

Help

• Luke C asked about non-action views. It was recommend that he check out Rails Cells or a presenter or decorator pattern.

Events

• Wednesday — 6:30pm Node JS, Evan is our liaison

The post [Standup][NYC] Standup 10/4/2011 – Typekit, we still love you. appeared first on Pivotal Labs.

• Schubert mentions that if url_for is blowing up on you, you’ve got fundamental problems. Think of this as the canary in the coal-mine. For example, if you’re trying to use namespaces in your rails controllers and there’s a pluralization problem, url_for will fail fast and hard.

• Kris Hicks let us know about Git from the bottom up, a free book that looks to be a great read for Git beginners and not-so-beginners alike.

• Kris also mentioned /proc/[pid]/status, which is available on most Linux distros. It contains lots of useful information about any process, such as process state, memory sizes, etc. See PROC(5) for more.

Stretch!

Worst turnout so far this week… three of us did some neck rolls. Let’s step it up tomorrow!

The post [Standup][NY] Thu 5/19/2011: Tomorrow is Friday; Saturday comes afterward appeared first on Pivotal Labs.

A standup of pivots (Sam Coward, Sean Moon, Peter Jaros, and Brent Wheeldon) have recently run into a bug in TeamCity that causes trouble with symlinks when using git.

If you commit symlinks into your repo, TeamCity will not properly transfer these to the build agents. They end up being copied over to the agents as plain text files.

The workaround for this issue is to use Agent-side Checkouts instead of Server-side Checkouts.

The post [Standup][NY] Wed 5/18/2011: TeamCity + git + symlinks == fail appeared first on Pivotal Labs.

Mike Gehard mentioned that there is a movement to extract ActiveResource from Rails. For now, it’s been shot down. But don’t bet against the haters! Work is underway to rewrite it from scratch. We’ll probably hear more about this as RailsConf proceeds.

Events

• TechCrunch Disrupt Hackathon is this weekend, May 21-22. Pizza, beer, and RedBull will be provided, and there will be much hacking.

Stretch!

Todd taught us a new stretch that involved us standing with one leg crossed over our other knee while bending and touching the floor. I always wonder what we must look like to innocent bystanders.

The post [Standup][NY] Tue 5/17/2011: ActiveResource, you're still my friend. appeared first on Pivotal Labs.

• Beware setting class variables in Rails Initializers: Schubert warned us that if you’re setting vars on your Rails classes inside of config/initializers, you’ll see weird things happen in development mode.

  If you set a class var on a model in an initializer, the value will be available on your first request to the app. However, upon the second request, Rails will reload the class, but it will not reload the initializers. At this point, you’ll have lost the value.

• Bash Brace Expansion: If you ever find yourself renaming a file in some faraway path, you think to yourself, “Wouldn’t be nice if I didn’t have to specify the entire path and filename twice?” Many shells provide you with a nice shortcut.

  So, instead of:

  mv /a/b/c/d/foo.feature /a/b/c/d/bar.feature
  

  You can use:

  mv /a/b/c/d/{foo,bar}.feature
  

  It’s pretty hot. Of course, there are many other applications of brace expansion. Check out the reference here:
  http://www.gnu.org/software/bash/manual/bashref.html#Brace-Expansion

Dangerous

Schubert rewired a bunch of power cables in the server room. If you notice that something isn’t right, you now know who to blame.

Events

• Peter mentions that BarCamp NYC is this weekend, May 21, 22. It sounds like a lot of fun, and a great place to learn and meet interesting people.

• Agile UX will be meeting here this Thursday. The topic will be Rails for UXers.

Stretches

Finally, Austin lead us in stretches this morning. It was quite exhilarating. Most of us ripped our pants and snapped our credit cards in half.

The post [Standup][NY] Mon 5/16/2011: Best Stretch Leader EVAR appeared first on Pivotal Labs.

CiMonitor has long had support for CruiseControl.rb and Jenkins (formerly Hudson). However, my CI tool of choice is TeamCity from JetBrains. We’ve recently added native support in CiMonitor for displaying your TeamCity build status, and I want to show you how to get it going. It’s as easy as configuring a new project and pointing to TeamCity’s REST API. Let’s walk through it step by step.

Install CiMonitor

For native TeamCity support, you’ll need to be on the latest version of CiMonitor. Follow the installation instructions on the CiMonitor GitHub page. If you already have CiMonitor installed locally, you’ll have to update to the latest version.

Create a New Project

Login to CiMonitor, and create a new project.

Choose “Team City Rest Project” as the Project Type.

For the Feed URL, you’ll be hitting the REST API provided by TeamCity 5.0 and newer. The correct format for the URL is as follows, with the # representing the TeamCity project number:

http://teamcity:8111/app/rest/builds?locator=running:all,buildType:(id:bt#)

You can find the correct project number by clicking onto the project in TeamCity and looking in the URL. Grab the number from the buildTypeId parameter.

You will also need to fill in a TeamCity username and password that CiMonitor will use to access the REST API.

Example Settings

Once you’ve set up the new project, save it and you’re all set.

Watch Your Builds Run!

You can now easily see the status of your TeamCity builds.

CiMonitor will also show that a build is currently in progress.

Wrapping Up

The integration is pretty solid, but there are one or two things that may seem to be odd behavior.

CiMonitor keeps track of build start times to control the size of the build dots for each project. The older the build, the smaller the dot. Currently, TeamCity’s REST API doesn’t publish the start time of a running build. Since this data is unavailable, CiMonitor just uses the current time when it fetches the feed. This is a minor issue, and JetBrains has already committed a fix for their REST API which will be released in the next version of TeamCity. CiMonitor will use the new field if it’s present in the feed.

Also, TeamCity has a great feature that will tell you that a build is failing before it even finishes. This has an interesting effect on CiMonitor. If a TeamCity build is red, the next time it begins running, CiMonitor will show it as green until the first test fails. Once TeamCity picks up on a failure, CiMonitor will show the build as red. This can be a little confusing at first because it may look like a build-in-progress is green before it has finished.

Hopefully you find this new functionality useful!

The post Radiating your TeamCity Builds appeared first on Pivotal Labs.