6 ways to make your alerting less boring (and more effective!)

Posted by Joep Weijers on November 8, 2018

Imagine you are a developer and you have just pushed a change that breaks the build. The Continuous Integration system, Jenkins in our case, sends you an email to notify you about this failure. BORING! Here are six examples that you can use to spice up your alerting and motivate your Development and Operations teams to react to alerts faster.

Chatbots

Alerting through emails is sooo 1990s, nowadays we use chat bots to tell us something has broken. But it is still the same dull message. Why not spice it up with some Artificial Intelligence like this:
Sir Jenkins alerting and harassing a build breaker

Warning lights

Each development team at TOPdesk has a big screen in their room with a Build Monitor view on it. When a build turns red or yellow on these monitors, we want to know about it. But we are not going to stare at the Build Monitor all the time. So we created this little eye catcher:

Code available at: https://github.com/joepweijers/jenkins-warning-light

Physical feedback

Suppose you have created a map with the physical locations of all your developers. We can then use this map to target developers who broke the build. For example with a turret that shoots foam darts:

Drones

Drones look cool, but their little, high-rpm rotors are very noisy. So they are perfect to let a developer know he broke the build:

Cars

The On-Board Diagnostics system on most cars is pretty easy to reverse engineer. With a small computer hooked up to the OBD2 port of a developer’s car, we can make the car part of our alerting system. Just let the car alarm go off:

But we can also control the door locks. And believe me: there is nothing more satisfying than the horrified look on the face of a developer, when he realizes that he can’t go home before he fixes the build:

Conclusion

At TOPdesk we are currently very satisfied with out Build Monitor views and the occasional email, but we like to experiment. Developers at TOPdesk are encouraged to work 10% of their time on their own projects for personal growth. This 10% time, one day every two weeks, is called Apekooi-time. From the previous examples the Jenkins warning light is the only real result of such an Apekooi-project. But nothing stands in the way technology-wise for the other examples, so go ahead and make your alerting awesome!

About the author: Joep Weijers

Joep is a Developer Experience Engineer at TOPdesk with a keen interest in delivering quality software continuously. He loves playing around with Jenkins Pipelines, GitLab CI, Selenium, Docker, Kubernetes and keeps in touch with his inner developer by educating his colleagues on testable Java code.

More Posts - Website

Twitter