Jenkins im Rampenlicht

Nachteile der E-Mail-Benachrichtigungsfunktion und Benutzeroberfläche des Build-Servers

Der CI-Server wird an ein Versionskontrollsystem angebunden, in dem alle Entwickler eines Teams ihre gemeinsame Codebasis verwalten. Die Entwicklung in größeren Projekten erfolgt meist in mehreren Entwicklungszweigen (Branches), die separat voneinander im Versionskontrollsystem gepflegt werden können. Ein Grund für die Erstellung separater Branches sind beispielsweise Releases. Hierbei kommt es häufig vor, dass aufgedeckte Fehler in mehreren Branches vorhanden sind. Fehlerkorrekturen werden also in vielen Fällen von einem auf andere Branches übertragen.

Jeder Branch wird im Idealfall vom CI-System in einem eigenen Job überwacht. Es existiert also eine Vielzahl von Build-Jobs, deren Status je nach Aufgabengebiet der Entwickler unterschiedlich interessant sind.

Treten bei einem Build-Job Fehler auf oder ist dieser nach einem Fehler wieder erfolgreich, wird euer Team per E-Mail benachrichtigt. Ob ein Build-Job gerade läuft oder ein weiteres Mal in Folge erfolgreich war, wird von der E-Mail-Benachrichtigungsfunktion nicht abgedeckt. Zum Glück, denn das wäre wegen des zu erwartenden Mail-Aufkommens eher eine Belastung für euch. Nützlich wäre es allerdings, wenn euer Team bei bestimmten Szenarien ein Feedback bekäme, zum Beispiel beim Start eines Build-Jobs nach einem Fehler. Dadurch wird euch der mögliche Erfolg frühzeitig angekündigt, wodurch Wartezeiten verkürzt werden können.

Den aktuellen Status aller Build-Jobs könnt ihr in der Benutzeroberfläche des Build-Servers einsehen. Diese muss vom Entwickler allerdings explizit aufgerufen werden. Eine Zusammenfassung der Status mehrerer Build-Jobs ist genauso wenig vorhanden wie der notwendige Platz auf den Monitoren des Entwicklers.

Da sowohl die E-Mail-Benachrichtigungsfunktion als auch die Benutzeroberfläche des Build-Servers sowie beides in Kombination nicht optimal sind, um einen Überblick über den aktuellen Zustand einer Menge von Build-Jobs zu erhalten, habe ich mich im Rahmen meines IHK-Abschlussprojekts mit dieser Problematik beschäftigt. Umgesetzt wurde eine Software, die den Status von Jenkins-Jobs auf farbig leuchtende LEDs abbildet.

Philips Hue

Da die Zeit für die Umsetzung eines IHK-Projekts knapp ist, habe ich bei den LEDs auf unnötige Bastelei verzichtet. Neben der einfachen Installation war es trotzdem notwendig, dass die Hardware über eine API verfügt, über die ein Farbwechsel angestoßen werden kann. In Anbetracht dieser Anforderungen habe ich Produkte der Firma Philips aus der Hue Serie ausgewählt.

Die genannte Produktserie von Philips verfügt über Geräte, die sich in den Kontext „Smart Home“ einordnen lassen: Lampen, die sich beispielsweise zu festgelegten Zeiten ein- und ausschalten oder über ein Smartphone im gleichen Netzwerk in Farbe und Helligkeit anpassen lassen. Hierbei fungiert die sogenannte Philips Hue Bridge als Access Point. Lampen aus der gleichen Serie können sich über die ZigBee-Spezifikation beziehungsweise IEEE 802.15.4 mit dieser verbinden.

Neben der Smartphone App lassen sich die Lampen auch über eine im Netzwerk zugängliche API steuern. Diese lässt sich komfortabel über ein SDK ansprechen, das Philips für mehrere Programmiersprachen bereitstellt.

Status, Szenarien und Priorisierung von Informationen

Aus den bisher genannten Anforderungen wird klar, dass der aktuelle Status eines Build-Jobs (BUILDING, FAILURE, UNSTABLE, SUCCESS oder ABORTED) allein nicht ausreicht, um sich eine passende Farbe anzeigen zu lassen. Deshalb werden Statusübergänge ausgewertet, die im Folgenden als Szenarien bezeichnet werden. Bei diesen kann beispielsweise klar zwischen „BUILDING nach FAILURE“ und „BUILDING nach SUCCESS“ unterschieden werden.

Eine weitere Anforderung war es, dass mehrere Build-Jobs auf einer Lampe abgebildet werden können. Die gleichzeitige oder zeitversetzte Darstellung von unterschiedlichen Farben ist unmöglich und auch unsinnig. Aus diesem Grund werden die Szenarien nach Priorität sortiert und unwichtige Szenarien, wie z.B. der durchgängige Status SUCCESS, nur angezeigt, wenn es nichts Wichtigeres anzuzeigen gibt.

Das Ganze ist in einer mandantenfähigen Webanwendung konfigurierbar. In dieser können Teams getrennt voneinander ihre Lampen verwalten, wobei die hinzugefügten Hue Bridges der Allgemeinheit als Zugangspunkt für neue Lampen zur Verfügung stehen.

Besonderheiten der Anwendung

Bei der Abbildung von Jenkins-Jobs auf Lampen der Firma Philips handelt es sich um keine neue Idee. Es existieren bereits einige Open-Source-Projekte, die mehrere der genannten Anforderungen erfüllen. Jede dieser Anwendungen hat aber gewisse Einschränkungen. So erfordern sie beispielsweise die Installation als Jenkins-Plugin, unterstützen keine Ausschaltzeiten oder haben keine Benutzeroberfläche. Diese Einschränkungen habe ich in meiner entwickelten Anwendung „JenkinsHue“ adressiert.

Die Anwendung wurde in der Programmiersprache Java umgesetzt. Zu den eingesetzten Technologien zählen unter anderem AngularJS und das Spring Framework mit Spring Boot, Spring Security sowie Spring Data JPA. Betrieben wird die Anwendung aktuell mittels Docker Compose und einer PostgreSQL.

Open Source

Nicht nur die Idee der „Jenkins-Lampen“ ist gut angekommen, die Anwendung wird auch aktiv in einigen adesso-Teams genutzt. Deshalb habe ich die Anwendung als Open Source auf GitHub veröffentlicht. Ich freue mich über Pull Requests und euer Feedback!