Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Ian Zabel

Posts By

LABS
Level up your development workflow with GitHub & Pivotal Tracker

I've been working with my client, Unpakt, for a while now. One of their core values is making people's lives easier. They're specifically focused on making it easy for people moving to a new home or office to find a mover, compare prices and book their move online.

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!

LABS
TeamCity is pretty cool, you should totally check it out

At Pivotal, our default choice for CI is Jenkins. I feel that Jenkins does a fine job running builds and reporting on a pass/fail. It also has nice plugins and plenty of features like build labeling and clustering.

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.

PIVOTAL LABS
[Standup][NYC] Standup 10/6/2011 — Github competition

Interesting

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

PIVOTAL LABS
[Standup][NYC] Standup 10/4/2011 – Typekit, we still love you.

Interesting

  • 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

LABS
[Standup][NY] Thu 5/19/2011: Tomorrow is Friday; Saturday comes afterward

Interesting Things

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

LABS
[Standup][NY] Wed 5/18/2011: TeamCity + git + symlinks == fail

Interesting Things

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.

LABS
[Standup][NY] Tue 5/17/2011: ActiveResource, you're still my friend.

Interesting Things

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

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.

LABS
[Standup][NY] Mon 5/16/2011: Best Stretch Leader EVAR

Interesting Things

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

LABS
Radiating your TeamCity Builds

If you're using a Continuous Integration tool, you should also be using an information radiator like Pivotal Labs' CiMonitor. CiMonitor is designed to be displayed on a screen that the entire team can see. If any of your builds go red, it shows up as a big red square and the team can quickly respond.

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.