Jenkins als CI Werkzeug

Verzeichnis

Links

Einführung

Continuous Integration - Idee

Continuous Integration (CI) ist ein Teil der modernen Software Entwicklung. CI stellt den Prozess dar, der das Bauen und Testen einer Anwendung abbildet. Mit Hilfe von CI lassen sich Fehler schneller finden und beheben.
Die Idee der kontinuierlichen Integration ist es, dass die Entwickler frühzeitig und regelmäßig Änderungen in das Versionsmanagement einchecken. Diese Änderungen sollten funktionsfähig sein, sodass die gesamte Applikation auf Integrationsprobleme geprüft werden kann. Es ist somit die Verfügbarkeit einer lauffähigen Version gegeben, die dann z. B. für anderweitige Testzwecke oder Vertriebszwecke genutzt werden kann. Eine typische Anwendung sind sogenannte Nightly Builds, bei denen zu einer vorgegebenen Uhrzeit der aktuelle Programmcode übersetzt wird und dabei Tests mit der erstellten Software automatisch ausgeführt werden. Bei gefundenen Problemen kann ein Entwickler dann z. B. direkt per Mail über das gefundene Problem informiert werden.

Jenkins als CI Werkzeug

Jenkins (ehemals Hudson) ist ein webbasiertes Open Source Continous Integration System. Es ist in Java geschrieben und plattformunabhängig. Die Basis von Jenkins unterstützt zahlreiche Werkzeuge darunter SVN, Ant, Maven sowie JUnit. Durch die Community können weitere Funktionen mit Hilfe von Plugins hinzugefügt werden. Somit lässt sich Jenkins für jedes Projekt individuell anpassen. Auch für Projekte mit anderen Sprachen/Technologien wie z. B. PHP, Ruby oder .NET ist Jenkins geeignet. Testwerkzeuge lassen sich über Plugins über die intuitive Benutzeroberfläche integrieren. Builds können durch verschiedene Auslöser gestartet werden: z. B. Änderung des CVS oder Zeitplan (z. B. Nightly Builds). Nightly Builds sind besonders bei Open Source Projekten zu finden und bedeutet, dass die Applikation nachts gebaut und getestet wird.

Support und Download

Jenkins veröffentlicht wöchentlich eine neue Version, mit neuen Features sowie Bugfixes. Zusätzlich zu den wöchentlichen Veröffentlichungen, steht eine LTS (Long Term Support) Version bereit. Diese wird im Dreimonatszyklus von der Community vorgeschlagen. Auf der Jenkins Website stehen sowohl das letzte Release, sowie der LTS Release zum Download zur Verfügung. Es stehen für verschiedene Plattformen (Windows, Debian, Mac OS X, uvm.) native Pakete zur Verfügung.

Installation

Einführung

Für Jenkins stehen bereits native Pakete bereit (Windows, Ubuntu/Debian, Mac OS X, uvm). Ebenso findet man es als Webarchiv (.war Datei). Diese kann alternativ auf weiteren Plattformen manuell installiert werden.

Installation als Windows Dienst

Für Windows Benutzer steht Jenkins als ZIP Archiv zur Verfügung, welches eine setup.exe enthält. Diese installiert bei Bedarf fehlende .NET Bibliotheken. Man wird grafisch durch die Installation geführt und kann Einstellungen wie z. B. Installationspfad angeben. Jenkins ist nun als Dienst vorhanden. Dieser lässt sich, wie in Windows üblich, starten und stoppen. Ist der Dienst gestartet, lässt sich Jenkins über den Port 8080 erreichen (http://hostname:8080).

Verzeichnisstruktur



Verzeichnisstruktur Abb. 1.1

OrdnerBeschreibung
jobsJeder Job bekommt ein eigenes Verzeichnis in jobs. In diesen einzelnen Verzeichnissen sind alle Job-relevanten Daten lokalisiert (z. B. Source Code, alle Builds).
jreIm Ordner jre befindet sich die Java Runtime Environment.
pluginsHier werden die installierten Plugins gespeichert.
updateses werden Informationen über neue Updates von Jenkins oder Plugins verwaltet.
userContentHier können benutzerdefinierte Dateien abgelegt werden. Diese sind dann über http://hostname:8080/userContent/.. erreichbar

Das am Meisten genutzte und somit wichtigste Verzeichnis ist das 'job' Verzeichnis (Abb. 1.2). Neben den Verzeichnissen builds und workspace, gibt es auch eine config.xml im Hauptverzeichnis, in der die Job-Konfiguration festgehalten ist.

job Verzeichnis Abb. 1.2

Benutzeroberfläche

Auf der Startseite (Abb. 2) erhält man einen Überblick über die angelegten Jobs mit Information über den aktuellen Build Status (Erfolgreich/Fehlgeschlagen). Unter der Navigation, die sich auf der linken Seite befindet, kann man den Status des Build-Prozessors sehen.

Start Abb. 2.1

Wenn man über die Navigation auf 'Jenkins verwalten' klickt, kommt man auf die Jenkins Verwaltungsseite. Hier findet man jegliche Einstellungsmöglichkeiten rund um Jenkins, von dem Hinzufügen von neuen Plugins bis zur Systemkonfigurierung.

Jenkins verwalten Abb. 2.2

Konfiguration

Einführung

Bevor man den ersten Job erstellen kann, müssen die Systemeinstellungen von Jenkins konfiguriert werden.

Konfiguration der globalen Einstellungen und Pfade

Wenn man im Jenkins-Verwaltungsbereich ist (Abb. 2.2) und dort auf System konfigurieren navigiert, kommt man zur Konfiguration. Hier können die grundlegenden Einstellungen vorgenommen werden. Es besteht die Möglichkeit globale Umgebungsvariablen zu definieren. Weiterhin müssen die Werkzeuge Ant und Maven sowie die JDK Installation angepasst werden. Hier bietet sich die Möglichkeit, entweder es automatisch installieren zu lassen oder aber die Installation z. B. via Pfad Angabe zu realisieren.

Konfiguration eines Mail Servers

Die Konfiguration eines Mail Servers bietet sich ebenso an. Dieser kann z. B. Entwickler benachrichtigen wenn ein Build fehlgeschlagen ist.

Build Job

Einführung

Build Jobs können verschiedene Aufgaben übernehmen. Meist hat ein Software Projekt mehrere Build Jobs. Zum Beispiel einen Build Job zum Ausführen von Unit Tests, einen weiteren zum Ausführen von komplexeren Integrationstests und einen zum Verteilen der Software auf einen Testserver.

Typen von Jobs

Unter Jenkins gibt es bei der Erstellung eines Jobs verschiedene Typen (Abb. 4.1). Free Style Projekt ist die meistgenutzte Einstellung. Hier hat man die größte Flexibilität. Es lassen sich verschiedene Verfahren beliebig kombinieren. Der 'Maven 2/3 Projekt' Job bietet schon einige Maven spezifische Konfigurationsmöglichkeiten und kann so äußerst einfach Maven Projekte integrieren. Der dritte Build Job besteht die Möglichkeit externe Prozesse zu überwachen. Dies bedeutet, dass auch Prozesse die außerhalb von Jenkins laufen, überwacht werden können.
Jobname und EinstellungAbb. 4.1
Bei einem Multikonfigurationsprojekt Job, hat man die Möglichkeit den gleichen Job mit verschiedenen Konfigurationen laufen zu lassen. So kann zum Beispiel ein Test unter verschiedenen Umgebungen laufen oder aber eine andere Datenbank nutzen. Eine letzte Möglichkeit ist es, einen existierenden Job zu kopieren. Dies ist eine einfache Möglichkeit, einen ähnlichen Job mit nur geringer Abweichung zu erstellen.

Job Konfiguration

Die Job Konfiguration lässt einem den Job flexibel einstellen. Als erstes sollte man sofern man nicht lokal im workspace des Jobs arbeitet, das Source Code Management einstellen. Es bietet sich CVS und SVN in der Standard Jenkins Konfiguration an. Aber auch Github lässt sich über ein Plugin einbinden. Wenn man z. B. Subversion als Source Code Management wählt, muss lediglich die Repository URL (ggf. Benutzername, Passwort) sowie die Check-out Strategie gewählt werden. Nachdem man das gewünschte Source Code Management konfiguriert hat, sollte man den Build-Auslöser einstellen. Hier bietet sich die Möglichkeit, den Job in Abhängigkeit von anderen Projekten zu starten, zeitgesteuert oder es wird nach einem Zeitplan das Source Code Management auf Änderungen abgefragt.
Der nächste Schritt ist, die Build-Eigenschaften einzustellen. Dort wählt man z. B. bei einem Maven 2/3 Projekt eine unter den Jenkins Einstellungen installierte Maven Version. Ebenfalls muss der Pfad zur der Stamm-POM Datei, sowie die gewünschten Goals und Optionen eingegeben werden. Bei einem Ant Projekt sind schließlich die Ant Einstellungen vorzunehmen. Als letzte Konfigurationsmöglichkeit gibt es die Post Build Aktionen. Dort unter anderem Einstellungen von Plugins vorgenommen. Hat man z. B. ein Plugin installiert, welches Testergebnisse veröffentlicht, so muss dort der Pfad zu den Ergebnissen angepasst werden. Außerdem können Builds anderer Projekte ausgelöst werden.

Automatisches Testen

Einführung

Das automatische Testen hat bei der kontinuierlichen Integration (CI) eine elementare Rolle. Mit Hilfe dieser Tests ist es möglich, jede Version der Software (Build) zu überprüfen, ob an dieser Version weiter gearbeitet werden kann oder aber noch Änderungen vorgenommen werden müssen. Dies ist wichtig, um einen definierten Status der Software zu kennen.

Integration von Werkzeugen

Jenkins unterstützt bereits in der Standard Konfiguration eine Reihe von Testwerkzeugen darunter auch zum Beispiel JUnit. Weitere Werkzeuge z. B. für Überdeckungstests lassen sich über die Jenkins Plugins nachinstallieren.

Beispiel

Beispiel Projekte




Zurück zur Werkzeugübersicht
Zurück zur CSI-Hauptseite