La notification par email est la forme de notification la plus évidente et la plus commune. L'email est bien connu, omniprésent et facile à utiliser et à configurer (voirSection 4.8, “Configurer le serveur de messagerie électronique”). Ainsi, quand les équipes mettent en place leur premier environnement d'intégration continue, c'est généralement la stratégie de notification qu'ils essaient en premier.

Vous activez les notifications email dans Jenkins en cochant la case Notification par email et en fournissant la liste des adresses email des personnes qui doivent être notifiées (voirFigure 8.1, “Configurer les notifications par email”). Par défaut, Jenkins enverra un courrier pour chaque build échoué ou instable. Rappelez-vous, Jenkins enverra aussi un nouvel email dès le premier build réussi après une série de builds échoués ou instables, afin d'indiquer que le problème a été résolu.

Normalement, un build ne devrait pas prendre trop d'essais pour fonctionner à nouveau — les développeurs doivent diagnostiquer et reproduire le problème localement, le corriger, et alors seulement committer leur correction dans le gestionnaire de versions. Des erreurs répétées de build indiquent généralement une erreur de configuration chronique ou de mauvaises pratiques de développement (par exemple, des développeurs qui soumettent leurs modifications sans vérifier au préalable leur fonctionnement en local).

Vous pouvez également choisir d'envoyer un email distinct à tous les développeurs qui ont des changements committés dans le build échoué. C'est généralement une bonne idée, car les développeurs qui ont committé des changements depuis le dernier build sont naturellement les personnes qui devraient être les plus intéressées par les résultats du build. Jenkins va récupérer l'adresse email de l'utilisateur à partir du domaine de sécurité couramment configuré (voirSection 7.4, “Domaines de sécurité — Identifier les utilisateurs Jenkins”), ou en dérivant l'adresse email à partir de l'utilisateur de l'outil de gestion de versions s'il a été configuré (voir Section 4.8, “Configurer le serveur de messagerie électronique”).

Si vous utilisez cette option, il peut être moins pertinent d'inclure l'équipe entière dans la liste de diffusion principale. Vous inclurez de préférence les personnes qui seront intéressées par le suivi du résultat de chaque build (tels que les responsables techniques), et laisser Jenkins informer les développeurs contributeurs directement.

Cela implique que les changements ont provoqué l'échec du build, ce qui est généralement (mais pas toujours) le cas. Cependant, si les builds sont peu fréquents (par exemple les builds nocturnes, ou si un build est en attente pendant plusieurs heures avant d'être abandonné), de nombreux changements peuvent être committés. Il est alors difficile de savoir quel est le développeur responsable de l'échec du build.

Tous les builds ne sont pas semblables par rapport aux notifications par email. Les développeurs qui ont soumis des changements sont particulièrement intéressés par les résultats des builds des tests unitaires et des tests d'intégration (surtout ceux déclenchés par leurs propres modifications). Les testeurs seront eux plus intéressés par jeter un œil sur le statut des tests d'acceptation automatisés. La configuration des notifications par email sera donc différente pour chaque étape de build. En fait, il est utile de définir des stratégies de notification par email. Par exemple,

En fait, vous devriez adopter au cas par cas la stratégie de notification appropriée pour chaque tâche de build, plutôt que d'appliquer une politique globale pour toutes les tâches de build.