October 15, 2007
A Whip Without a Growl is No Fun

Bugger. Growl doesn't have an option to wake your Mac from a screen saver, even on a per-app or per-event basis - and it isn't going to get one. I have to say, I don't agree that it would be that evil an option, provided that it wasn't the default. People wouldn't have to turn it on if they didn't want to, after all.

I'm quite prepared to believe that it would be a bugger to implement, though.

Why do I want it? Well, I'm currently Build Whip here at GU, and ccmenu is an essential tool in my armory. It would be really nice if I could arrange to be told about a broken build even if my screen saver has kicked it. I can make it play a sound, I suppose, but it's not really the same.

What's a Build Whip? Well, we have a big old team here, twenty-odd pairs, and we are not allowed to check in on red. Someone needs to make sure that the build gets fixed ASAP, and it's my job to make sure that happens.

Still none the wiser? OK, well, we practice something called Continuous Integration. When we are happy with a bit of code we've written, we put it into a single shared place, the code repository. Whenever the code in the repository changes, one or our server machines automatically bursts into life, and compiles all the code (to make sure that it's valid) then runs all our automated tests (hopefully demonstrating that it's bug free).

If this all works, the build is green. If not, it's red, and there's always some what that the entire team is informed of this. At my last site, we had a lava lamp. At GU, we have a big-ass plasma TV showing all sorts of stuff, and ccmenu or ccTray.

If the build is red, it need to be fixed ASAP. Fixing the build can be enormously complicated by other people putting further changes into the repository while you are working on it, so that's not allowed. Since that means that no one can check in (i.e. put code changes into the repository) while the build is red, that means it's even more important that the build is fixed ASAP. ASAPer? ASAPest? Whatever. So you have a build whip, whose job it is to either fix the build, or more often to track down the pair whose change was responsible for breaking the build, and make them fix it.

More on this later. Time to go shopping.

Posted to Agile by Simon Brunning at October 15, 2007 06:30 PM
Comments
Post a comment
Name:


Email Address:


URL:



Comments:


Remember info?