Kontinuierliche Integration mit Jenkins

Jenkins

Um ein Software-Projekt mit Hilfe von kontinuierlicher Integration zu entwickeln, gibt es viele Software-Produkte, die den Entwickler dabei unterstützen. Darunter fällt Jenkins, welches in diesem Artikel betrachtet wird. Jenkins wurde unter dem Dach von Sun Microsystems von Kohsuke Kawaguchi entwickelt. Damals hieß es »Hudson«. Kawaguchi verließ das Unternehmen, nachdem Sun von Oracle übernommen wurde. Oracle verweigerte die weitere Nutzung des Namens »Hudson« und entwickelt es selbst weiter. Da Kawaguchi Hudson unter dem Namen »Jenkins« weiterentwickelt, ist es somit ein Fork. Jenkins ist in Java geschrieben und läuft plattformunabhängig als Web-Anwendung auf einem Server. Der Quellcode unterliegt der MIT-Lizenz.

In Jenkins können Jobs definiert werden, die als sich wiederholende Arbeitsabläufe zu verstehen sind. In der Regel umfasst dies mehrere Schritte, die automatisiert ausgeführt werden. Innerhalb der Konfiguration eines Jenkins-Jobs ist es möglich, verschiedene Arbeitsabläufe zu definieren, die unter Linux in der Regel Shell-Skripte enthalten. Jenkins kann man daher auch als Aufsatz für derartige Skripte verstehen. Der Vorteil von Jenkins ist, dass sich die Jobs leicht und intuitiv erstellen lassen und die Entwickler zudem viele Konfigurationsmöglichkeiten nutzen können.

Generell werden Jenkins-Jobs in zwei verschiedenen Varianten ausgeführt. Die erste ist das Konzept der täglichen Builds, die täglich ausgeführt werden. Das zweite Konzept ist die bereits erwähnte kontinuierliche Integration von Quellcode, die immer dann ausgeführt wird, wenn Änderungen am Quellcode vorgenommen worden sind. Hierbei wird ein Jenkins-Job immer dann gestartet, wenn Änderungen im Projektarchiv durchgeführt wurden. Bei den täglichen Builds hingegen werden die Änderungen eines Tages stets zusammengefasst.

Ein Jenkins-Job bildet einen gewissen Arbeitsablauf ab, welchen man in vier Unterpunkte aufteilen kann. Die erste Ausführung ist die Auslösung des Jobs. Dieser kann zeitgesteuert, ereignisgesteuert oder durch eine Änderung im Quellcode ausgelöst werden. Bei der zeitgesteuerten Auslösung kann eine bestimmte Uhrzeit definiert werden. Wenn zum Beispiel 18 Uhr angegeben wurde, dann startet Jenkins automatisch den angelegten Job. Äquivalent dazu kann auch ein Job ereignisgesteuert ausgelöst werden. Dabei kann konfiguriert werden, dass ein bestimmter Jenkins-Jobs nur dann ausgeführt werden soll, wenn ein Vorgänger-Projekt erfolgreich verlaufen ist. Die dritte Möglichkeit ist die Auslösung nach einer Änderung im Quellcode. Jenkins scannt dazu das Quellcode-Archiv (Repository) in gleichmäßigen Abständen und löst den Jenkins-Job aus, wenn eine Änderung registriert wurde. Der letzte Auslöser ist der einfachste: die manuelle Ausführung.

Der zweite Schritt ist ein denkbar kurzer: Der Jenkins-Jobs startet, lädt sich den Quellcode vom Repositorium herunter und geht dann in den dritten Schritt über, den Buildvorgang.

Der Buildvorgang kann sehr individuell genutzt werden, da er in Shell- beziehungsweise Windows-Batch-Skripten spezifiziert wird. Als Nutzer von Jenkins hat man dabei sehr umfangreiche Möglichkeiten, den Buildvorgang zu gestalten. Generell wird im Buildvorgang das Projekt kompiliert sowie die Tests ausgeführt. Sofern bei den jeweiligen definierten Shell-Skripten keine gravierende Fehler vorkommen – zum Beispiel Programmabstürze – geht Jenkins in den vierten Schritt über. Wenn jedoch etwas schief geht, dann bricht der Buildvorgang komplett ab und meldet den Entwicklern den Fehlschlag des Buildvorgangs.

Der Post-Buildvorgang ist der vierte und letzte Schritt, welchen Jenkins durchführt. Hierbei handelt es sich um Aktionen, die alle nach dem Buildvorgang durchgeführt werden. Dort können dann ebenfalls einige Aktionen definiert werden. So ist es sinnvoll, das Projekt in ein Paket zu packen. Je nach verwendetem System ist es möglich, sofort ein fertiges DEB- oder RPM-Paket bauen zu lassen. Daneben werden im Post-Buildvorgang auch die ausgeführten Tests ausgewertet. Die Modultests schreiben die Ergebnisse der durchgeführten Tests in Log-Dateien. Die Art der Log-Dateien unterscheidet sich dabei vom eingesetzten Test-Framework. Von Haus aus unterstützt Jenkins das Java-Test-Framework JUnit. Häufig werden hierzu XML-Dateien genutzt, die der Jenkins-Job zum Schluss auswertet. Bei der Auswertung werden dann die Log-Dateien nach einem festgelegten Schema eingelesen und interpretiert. Dabei wird die Anzahl der fehlgeschlagenen Modultests gezählt und als Ergebnis des Jenkins-Jobs ausgegeben.

Status und Wetterbericht zu verschiedenen Jenkins-Jobs

Sujeevan Vijayakumaran

Status und Wetterbericht zu verschiedenen Jenkins-Jobs

Anschließend erzeugt Jenkins mit dem Testergebnissen den Status des aktuellen Builds in Form von Farben und einen sogenannten »Wetterbericht«. Der Status ist »rot«, sobald zu viele Fehler aufgetreten sind, »gelb«, wenn eine geringe Fehleranzahl aufgetreten ist, und »blau«, sofern keiner der Modultests fehlgeschlagen ist. Häufig werden alternativ auch die »Ampel-Farben« genutzt, so dass ein erfolgreicher Build mit Grün statt Blau gekennzeichnet ist. Was unter einer »geringen Anzahl der Fehler« verstanden werden soll, lässt sich dabei einstellen. Wenn ein Jenkins-Jobs mehrmals durchgelaufen ist – der Quellcode also mehrfach Veränderungen erfahren hat – wird daraus der Wetterbericht erstellt. Der Wetterbericht zeigt an, wie der Verlauf der letzten fünf Jenkins-Jobs war. Strahlenden Sonnenschein gibt es, sofern alle Builds erfolgreich durchgeführt werden konnten, wohingegen es Gewitter gibt, wenn alle letztmaligen Builds fehlgeschlagen sind. Zudem existieren noch weitere Zustände wie zum Beispiel Wolken, sofern nur wenige der letzten Vorgänge fehlgeschlagen sind. Die einzelnen Werte, aus denen der Status eines Jenkins-Jobs erzeugt wird, lassen sich hierbei ebenfalls konfigurieren, sodass Entwickler-Teams die volle Kontrolle über ihre Jenkins-Jobs haben.

Zum Abschluss des Post-Buildvorgangs und somit des gesamten Durchlaufs eines Jenkins-Jobs müssen schließlich noch die Entwickler informiert werden. Entwickler können entweder die E-Mail-Benachrichtigung nutzen oder alternativ sich des großen Plug-in-Pools bedienen. So können die Entwickler durch das Nutzen von Plug-ins über das XMPP-Protokoll oder einem IRC-Bot informiert werden. Wenn man noch einen weiteren Jenkins-Job direkt im Anschluss ausführen will, kann man zudem einen Trigger setzen, welcher dann den anderen Jenkins-Job startet.