A WiFi lantern to increase developer team cooperation
BI-Beacon was initially known as CILAMP; short for Continuous Integration Lamp. The problem that CI status indicators (or “build lamps”) solve is one of developer coordination and cooperation.
When several code changes happen concurrently on each developer machine, and those changes are checked in to a shared code server, it is in the whole teams’ interest that the state of the joint code base is still OK:
- The system should always compile without errors
- All automatic tests (unit, integration, system) should still be passing
- Generating artifacts (installers, packages, app bundles) should still work
How BI-Beacon is utilized in a CI/CD scenario
Using triggers or polling of the build servers current state together with BI-Beacon – a live indication of the current or previous build can be visualized in a physical arena where all devs can see, for instance in the center of the room.

A slow yellow pulse means the build server is currently building; the result is not yet available.

Green color indicates that the the system built without errors – all tests passed. Everyone can update their local sources (or fork master) without worry, and it’s also an excellent time to check in your changes.

Red means something failed; either with a compile error or some test didn’t pass. Now is not a good time to update your local source.
Effect
Having a build indicator available makes the team collaborate more efficiently, and avoids conflicts where developers are annoyed with each other’s bad commits; in fact, this is such a common need that throughout the years development teams have often spent their time and energy on coming up with their own homegrown solutions, as in the left image below.

Of course your ninja-devs could probably come up with their own solution to this problem, however travelling that road is rocky and may come at a high cost:
- Developer time is expensive, and building even “homegrown hacks” is non-trivial
- Homegrown solutions tend to fail after some time, causing either service outage or high maintenance cost
- The developer that initially built the solution may switch workplace, again causing a service outage