Introduction
This project has been deprecated.
In today’s world of information and sensory overload, it is challenging to raise above this noise threshold. In a professional software development environment where continuous integration is used to build quality software, it is vital to bring failed builds to the attention of the responsible developers as quickly as possible. This problem is easily solved in a fun way by using a discreet build light for each developer.
Architecture
The system starts with a build server plugin to collect build events. Different plugins can be built for different build systems, such as Jenkins, Hudson, CruiseControl, Bamboo, Buildbot and TFS (among others) without affecting the rest of this system. Using a simple protocol, this information gets pushed to the centralised notification server. This server keeps a cache of two types of statuses for each user:
- Attention is required (e.g. a failed build)
- Build activity (e.g. a build is currently building)
When an event is received, the notification server will broadcast it to the applicable users if their notification client is registered. This client registers the user when the USB light is plugged in.
As the build light can’t convey information specific to a particular build configuration, the information is aggregated by the notification server. Simply put, if any build that you have contributed to in any way is building, your light will turn yellow; if your attention is required, it will turn red. In the absence of both the aforementioned, your light will radiate green.
A fourth status, using blue, means the status of builds are unknown, e.g. if the notification server is down or while the client has not yet registered.
The system was designed to work with any build server which can expose events, as long as the events can be mapped sensibly to events that the notification server can interpret. At this stage, only a TeamCity build server plugin has been implemented, as it is my build server of choice. It is a distributed, customisable and extensible system that caters for a large number of technologies on different platforms.
Due to a limitation of the TeamCity Open API, it is necessary for the notification server to retrieve some information from the source repositories.
Software
Hardware
The very first iteration of this project used a single pair of lights to indicate the global status of the build environment. Although this scored points for being cool (similar to existing feedback devices), it wasn’t particularly useful. Some of my colleagues suggested to have team lights. That was a good suggestion, but when I received an Arduino experimenter’s kit containing an Arduino Uno, I realised one could construct a build lights device for each developer.
Although the Arduino connects over USB, communication is actually emulated as if using a serial port. This is not ideal if you require a plug-and-play device. For that reason, I switched to a Teensy development board, while still using the Arduino software. As I was nearly done with the project, a colleague showed me the development of the blink(1) USB RGB LED on Kickstarter by ThingM. This was just perfect for my needs and great timing.
As I haven’t worked with electronics in several years, and in particular not with USB, I experimented heavily with different libraries. That’s the reason the project allows for using different protocols and hardware devices. If you’re interested in building your own hardware to work with this system, you can adapt the original custom firmware.
