Jeffry Degrande, one of my mate’s in the Rails Rumble team wrote a blog post about our experience with continuous integration and automated building.
Read it below:
Continously Integrating Awesomeness
Very early on, during our initial conversations in preparation of 2010′s Rails
Rumble our team decided we would use a build system and continuous integration.
I ended up beign the one who was going to set it all up and take care of it
during the competition.
Initially I was going to use Hudson on a real box. Since we didn’t actually
have one available, plan B was to run it in a virtual machine on my mac. That
turned out to slow my mac down too much. Additionally configuring a new project
too longer, even after practicing it a few times than I wanted to spend on it.
So we settled on the excellent CI Joe by Chris Wanstrath.
CI Joe is beautifully simple: clone the repo, configure cijoe.runner to run ‘rake spec’
and point a github web hook to post to your mac. Use tunnlr.com if you’re stuck behind
a firewall.
We also had it posting to campfire which we were running in a browser on a
laptop connected to a huge plasma TV.
some stats
Just for fun, here are some stats:
- I counted 134 builds in the campfire logs
- 88 builds were successful; the highest number of builds we went without breaking it was 21
- About halfway through the rumble we went on for a while without fixing the build but we
really broke it about 12 times - The ssh tunnel kept disconnecting so not all commits triggered a build
Why fixing the build is your number 1 priority
I want to close with a small anecdote.
My first hours of the rumble were spent adding test coverage to everything
involving users while Daniel was working on the design for the app. In order
to make those tests pass doing the absolutely simplest thing that could work, I
added something like this to the layout:
<% if usersignedin? %>
Welcome back dude
<% end %>
That was all I need to make my integration tests pass, knowing that they would break as
soon as Daniel started working on implementing the designs. So I refactored those tests
to remove duplication and moved on.
Fast forward a couple of hours: Daniel had finished the design and had started work on
the layout. The tests started failing as expected. Yet, I continued work on other things.
We all ignored the build for about 2 hours, adding functionality while 9 specs were failing.
When I finally sat down and updated the tests to reflect the now implemented layout, the
specs were still failing. In fact, no matter what I tried I couldn’t get them to pass.
The flash message I was expecting and testing for was not even there. What happened
was that we had introduced a bug at some point and it was hiding behind a hand full of
tests we temporarily allowed to fail. Had we waited until close to the end to fix
those tests; we probably would not have been able to find & fix that bug.
When the build breaks, fix it immediately
