Jenkins: The Definitive Guide

Chapter 8. Notification

Introduction

While it is important to get your build server building your software, it is even more important to get your build server to let people know when it can’t do so. A crucial part of the value proposition of any Continuous Integration environment is to improve the flow of information about the health of your project, be it failing unit tests or regressions in the integration test suite, or other quality related issues such as a drop in code coverage or code quality metrics. In all cases, a CI server must let the right people know about any new issues, and it must be able to do so fast. This is what we call Notification.

There are two main classes of notification strategies, which I call passive and active (or pull/push). Passive notification (pull) requires the developers to consciously consult the latest build status, and includes RSS feeds, build radiators, and (to a certain extent) emails. Active notification (push) will pro-actively alert the developers when a build fails, and includes methods such as desktop notifiers, chat, and SMS. Both approaches have their good and bad points. Passive notification strategies such as build radiators can raise general awareness about failed builds, and help install a team culture where fixing broken builds takes a high priority. More direct forms of notification can actively encourage developers to take matters into their own hands and fix broken builds more quickly.

Email Notification

Email notification is the ...