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
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:
http://schneide.wordpress.com/2008/10/27/extreme-feedback-device-xfd-the-onoz-lamp/
Sincerely,
Daniel
Hello Carlos,
electric discharges, heartless… 😉
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
I like the electric shock idea, but I wonder if this multi-stage continuous integration practice would correct the problem with out the need for lava or shocks?
http://www.accurev.com/continuous-integration.html
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.
http://java.dzone.com/articles/preflight-builds-theres-a-time
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:
http://schneide.wordpress.com/category/extreme-feedback/
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.
No problem Daniel, you guys have really tried everything 😉
hmm… a lava lamp.. an interested topic though…
Agile Toys has an affordable kit that includes a beacon and an x10 Firecracker and hooks up with the x10 feature in CCTray. http://www.agiletoys.com
Pingback: Every morning in Africa, an xper wakes up. He knows he must run at full speed. | Nautilus Team Blog
Pingback: Every morning in Africa, an xper wakes up. He knows he must run at full speed. « Nautilus Team Blog