Bien qu'il soit important que votre serveur de build construise votre logiciel, il est encore plus important qu'il signale lorsqu'il ne peut pas le faire. Une part importante de la proposition de valeur de tout environnement d'intégration continue est d'améliorer le flux d'information sur la santé de votre projet ; que ce soit des tests d'intégration échoués, des régressions dans la suite des tests d'intégration ou d'autres problèmes de qualité comme une baisse dans la couverture de code ou de métriques de qualité de code. Dans tous les cas, un serveur d'intégration continue doit permettre aux bonnes personnes de connaître les nouveaux problèmes, et il doit pouvoir le faire rapidement. C'est ce que nous appelons : Notification.

Il y a deux principales catégories de stratégies de notification, que j'appelle passive et active (ou pull/push). Les notifications passives (pull) demandent aux développeurs de consulter consciemment le statut du dernier build. Ces notifications comprennent les flux RSS, les radars de build, et (dans une certaine mesure) les e-mails. Les notifications actives (push) vont alerter les développeurs de manière pro-active lorsqu'un build échoue. Ces notifications comprennent des méthodes telles que des notifieurs intégrés au bureau, le dialogue en direct et les SMS. Ces deux approches ont leurs points positifs et négatifs. Les stratégies de notifications passives telles que les radars de build peuvent diffuser une connaissance générale sur les builds échoués et aider à installer une culture d'équipe où la correction des builds cassés prend une haute priorité. Des formes plus directes de notification peuvent encourager activement les développeurs à prendre les choses en main et corriger les builds cassés plus rapidement.