Using Lava Lamps for Continuous Integration build status notifications

Taking the idea of using Lava Lamps as notification tools for your Continuous Integration status, green lamp for success, red lamp for failure, the so called eXtreme Feedback Devices, and using as a guide the instructions in Pragmatic Automation, I have made some improvements to use remote notification, meaning that lamps don’t need to be connected to the build server, and a more automated process, that will turn off the lamps out of business hours.

The code is in a new project, Continuous Lava, in case it’s useful for somebody else. There are two parts, one for Apache Continuum and one for CruiseControl.

Actually, it is not necessary to use lava lamps but you can turn on and off any device you plug to the X10 power adapters. Imagine a loud siren, or my favorite, electric discharges to developer’s chairs!!! (we’ll leave this as an idea for future projects)

UPDATE: fixed the link to Pragmatic Automation

11 thoughts on “Using Lava Lamps for Continuous Integration build status notifications

  1. Thank you for your contribution to the Extreme Feedback Device idea.

    I have just one hint on the “turning off”-problem. Most of the time, the red lamp should be off. So what you really switch off is the green one. Why not shrink the whole setup to just one lamp: on means trouble (former red lamp) and off means ease (former green lamp). If your team is disciplined, you don’t need explicit lamp downtimes anymore.

    Have a look at our setup:


  2. Daniel,
    You make a good point in your blog about handling the red/green color blind issue. However, there’s a failure mode with the one light solution… instead of “all’s well” indicated by an unlit lamp, it could really be indicating “lamp is unplugged” or something similar. By the way, I especially like how “ONOZ” has been incorporated into your group culture 🙂
    – Dave

  3. Daniel, yes there are many possibilities, lights, sirens, music,… you just have to chose the one you like better

    Mark, the idea of precommit builds has been out for several years, it can be done using pre-commit hooks in svn, cvs,… using branches or many ways.

    In my opinion is overkilling and causes several other problems, like commit merging, and adds too much burden to team development.

  4. I didn’t plan to take over the comment section of this blog entry, but i have to leave a reply to your much appreciated follow-ups:

    Carlos, we didn’t like to choose, we took it all:
    light, sound, water, text and more (the USB rocket launcher is yet to be integrated).

    David, your hint about the failure possibility is valid. Sometimes, we check to see if the bulb isn’t burned. But the lamp is accompanied by sound (through the speakers), text (on the LED bar), a grim email and sulky colleagues. You really can’t miss the broken build.

    Keep on tightening the feedback loop.

  5. Pingback: Every morning in Africa, an xper wakes up. He knows he must run at full speed. | Nautilus Team Blog

  6. Pingback: Every morning in Africa, an xper wakes up. He knows he must run at full speed. « Nautilus Team Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s