The Rally software code base changes rapidly. The development team is continuously making enhancements and building new features for weekly releases to our production systems. In part, the ability and confidence to push code with a high frequency comes from our comprehensive collection of automated tests. The test suites include front/back-end unit tests, integration tests and selenium-driven browser testing. Everything is rolled up and tracked as builds by a Jenkins continuous integration server.
Jenkins Web Interface
At a recent group retrospective we decided to try out some new team working agreements, which included:
you cannot push code to a failing build
if you break a build and cannot fix it within 30 minutes then you must revert that commit
To improve visibility into the status of our builds we purchased some Visual Signal Indicator lights and linked them up to Jenkins with a Ruby script. The script runs once a minute and uses blinky to control the lights via a USB cable. Once you’ve compiled and installed some native USB libraries (we followed the Blinky instructions using homebrew on OSX) Blinky is very straightforward to use:
The script uses the Jenkins remote access API to retrieve the state of our builds, as an XML document, from the Jenkins server. Then the script updates the light’s color according to whether the builds are passing (green), failing (red), or warning (orange).
The behavioral effect of build lights as visual indicators has been interesting and largely positive. When a light turns red we check the Jenkins server, track down the issue and get it resolved within a much shorter time period than in our darker days. People outside of the development team ask about the lights, make comments on the build status and now have a better understanding of what our testing strategy means. Improving in-company visibility into our processes is healthy and a good thing.