Co-worker 1: “Hey…is our Jenkins even running?”
Me: “Uhh, yes? What do you mean?”
CW1: “Well, I’ve pushed 3 different commits, and it hasn’t told me that the build failed.”
Me: “Neat. Good job not breaking the build?”
CW1: “Oh wait, Jenkins only notifies us when it fails, that’s right.”
Me: “Right…but it would be better if we always knew what state it was in.”
The above conversation was real.
The names were changed to protect Matt Swanson, I mean, the innocent. (Oops!)
But Matt’s concern, err Co-worker 1’s concern, was legitimate – why do I have to go checkthe build status?
Continuous feedback was already something I was interested in investing in. A group of us read the book Continuous Integration as a book club, and there was an entire chapter on feedback in that book. The main takeaway I had from that chapter was that I wasn’t practicing continuous feedback (enough).
Being the curious little engineer that I am, I decided to look for an off-the-shelf solution for feedback indicators. After looking at many X10 solutions, and even some solutions that use a Beeper-service (yes, those pagers that were cool for about 2 weeks in the 90’s)…I finally stumbled upon the Philips Hue. Not only does Philips have a pretty good developer site, there is also a Jenkins plugin to make the necessary color changes for your Hue bulbs!
So now that everyone else has already done all of the hard work of making a kick-butt product, great documentation/instructions, and a simple plugin…I just had to turn it on!
Right?
Almost.
Below are a few “pro tips” that seem obvious to me now, but weren’t obvious to me a month ago. (So my hope is that these tips can help others make feedback valuable.)
ProTip #1: feedback is tricky.
You have to be careful that you aren’t just creating noise. Consider the following questions to help you decide if your feedback is helping, or potentially hurting…
- What questions are you trying to answer, or problems are you trying to solve?
- Would this new feedback mechanism have any negative side-effects or be a significant distraction?
- What if someone misused the information somehow?
ProTip #2: adding a colorful light in an already well-lit office is difficult.
It turns out that bright white lights can easily bleach out your color. So placement of the lamp is important (for us, near a shadow on a wall works well).
ProTip #3: if your feedback indicator is difficult to implement, perhaps your Continuous Integration (CI) process is too complex.
We currently have 2 completely separate teams using the Philips Hue as a build status indicator.
The team I’m working on has a very serialized CI process – unit tests run first, then functional tests, then deployment. In this case, the color of the lamp changes as it goes through the entire process.
My neighboring team has a very parallel CI process – each component has a build/test, once all components are done then a deployment process occurs. In this case, the color of the lamp only changes with the deployment process.
If you are not able to easily hook in a build status indicator, then you should consider refactoring your CI process in order to get the most feedback out of your process.
The color of the lamp matches the existing Jenkins standard color scheme for build status:
- blue– in progress
- green– successful
- red– failed
- yellow– unstable (whatever that means, hah!)
This type of feedback indicator works well because you don’t have to go looking for it. As you walk around our office, you can quickly see the status of our build.
A challenge for my readers:
