Mit dieser Wahl erstellen Sie ein vollkommen neues Projekt, gänzlich ohne weitere vordefinierte Parameter. Neben frischen Projekten bietet sich diese Auswahl ebenfalls für die Erstellung eines Job-Templates an, das nach einmaligem Anlegen beliebig oft als Basis wiederverwendet werden kann, zum Beispiel wenn Sie oft neue Plugins für ein und dieselbe Plattform schreiben. Auch für Anfänger ist dies eine gute Wahl, da die Einrichtung somit von Grund auf erlernt werden kann.

Es klingt zwar nach der meisten Arbeit, da Sie mit einem vollständig leeren Projekt anfangen, allerdings ist dies meist die beste Variante, vor allem auch am Anfang Ihrer Jenkins-Karriere. Sie werden schnell merken, dass nicht annähernd alle Werte und Möglichkeiten ausgeschöpft werden müssen, um ein lauffähiges Projekt zu konfigurieren. Außerdem sind Freestyle-Projekte am flexibelsten und somit am leichtesten auf besondere Bedürfnisse anpassbar.

Später sollten Sie dann wenn möglich auf die angesprochenen Templates zurückkommen, um nicht immer komplett bei Null anzufangen, wenn bereits ein ähnliches Projekt angelegt wurde.

Wie der Name schon sagt, ist hier das universelle Build-Werkzeug Maven im Spiel. Maven ist ebenfalls in Java implementiert und stammt aus dem Hause der Apache Foundation. Es bietet viele Möglichkeiten, Projekte zu verwalten und zu standardisieren, allerdings wird es meist nur bei größeren Vorhaben, vor allem im Java-Bereich eingesetzt. Jenkins verfügt standardmäßig über eine sehr gute Integration dieses Tools.

Mavenbuilds werden über XML-Dateien mit dem Namen pom.xml (Project Object Model) konfiguriert. Bei der Auswahl dieses Jobtyps wäre Jenkins in der Lage, eine bereits vorhandene pom.xml zu lesen und viele Einstellungen des Jobs in Bezug auf Build-Schritte daraus zu extrahieren. Sie müssen lediglich den Pfad und den Namen der Pom-Datei sowie die zu verwendenden Goals angeben. Im Goals-Feld können außerdem auch weitere Maven-eigene Kommandozeilenoptionen übergeben werden.

Dies stellt eine nicht unerhebliche Reduktion des Einrichtungsaufwandes dar – allerdings sollten Sie davon absehen, Ihr Projekt nur in Maven zu überführen, um diesen Vorteil nutzen zu können. Außerdem müssen die meisten grundlegenden Einstellungen dennoch vorgenommen werden, wobei sich das Vorgehen nicht von der Verwendung eines Freestyle-Projekts unterscheidet. Auffallende Differenz ist die Option Baue dieses Projekt, wenn eine SNAPSHOT-Abhängigkeit gebaut wurde in der Rubrik Build-Auslöser. Jenkins durchsucht dabei die Pom-Datei nach Abhängigkeiten zu anderen Projekten, die ebenfalls unter Jenkins-Kontrolle stehen. Sollte einer dieser Jobs gebaut werden, wird das aktuelle Projekt ebenfalls neu gebaut. Mehr zu Abhängigkeiten erfahren Sie in den folgenden Kapiteln.

In den erweiterten Einstellungen des Build-Schritts finden Sie interessante Möglichkeiten wie das Inkrementelle Bauen, das Parallele Bauen sowie Private Maven-Repositories. Letztere können bei vielen Builds sehr hilfreich sein, da jeder Build ein eigenes lokales Maven-Repository bekommt und somit keine Konflikte untereinander auftreten können.

Nachteilig wirkt sich bei der Verwendung eines Maven-Jobs die reduzierte Flexibilität gegenüber Freestyle-Projekten sowie die bei großen Applikationen verringerte Geschwindigkeit aus.

Diese Art eines Jobs gibt Ihnen die Möglichkeit, »externe« Tools wie zum Beispiel Cronjobs, E-Mails und Services zu observieren. Viele dieser Dienste sind unbeobachtet und »laufen einfach«. Wenn allerdings Builds fehlschlagen, weil wichtige Tools für den jeweiligen Build nicht funktionsfähig sind, ist es an der Zeit, selbige zu überwachen und den eigentlichen Job nur dann zu starten, wenn auch alle nötigen Services und Programme einsatzbereit sind – ein wichtiger Punkt für einen stabilen und automatisierteren Build-Prozess. In der Praxis führen fehlende oder fehlerhaft konfigurierte externe Werkzeuge oft zum Fehlschlag eines eigentlich sauberen Builds.

Auf der Hand liegen hierbei zum Beispiel Einsatzgebiete wie das Prüfen der Ergebnisse eines Cronjob, der eine Testdatenbank aus dem Livesystem repliziert, ein Selenium-Server für Frontend-Tests einer Webapplikation oder auch das simple Verifizieren auf die Existenz eines Programms. Bekanntlich verderben viele Köche den Brei – da passiert es schnell, dass ein Kollege ein Tool für nicht mehr nötig hält oder die teilweise sehr pragmatisch handelnden Paketverwaltungen ein Paket für überflüssig erachten und beim Upgrade deinstallieren.

Die Konfigurationsoberfläche dieses Projekttyps lässt nicht sehr viel an möglichen Einstellungen zu. Dies liegt daran, dass die eigentliche Einrichtung über die Kommandozeile geschieht. Die Verwendung ist schnell erklärt. Das folgende Beispiel stellt einen beispielhaften Aufruf unter Unix dar:

$ export JENKINS_HOME=http://localhost:8080 $ java -jar /jenkinshome/WEB-INF/lib/jenkins-core-*.jar "Job Name" $app

Das Gleiche unter Windows:

$ set JENKINS_HOME=http://localhost:8080 $ java -jar \jenkinshome\WEB-INF\lib\jenkins-core-*.jar "Job Name" cmd.exe /c $app

Zuerst wird wieder die Jenkins-URL gesetzt, wobei im obigen Beispiel von einer frei zugänglichen Instanz ausgegangen wird. Sollten Sie Zugriffsrechte eingerichtet haben, können Sie diese im Format http://user:pw@jenkinspfad.tld übergeben. Die zweite Zeile startet jeweils ein spezielles Jar, welches das Job Name-Projekt verwendet und die Anwendung $app samt Parameter aufruft. Ein sehr simples Beispiel wäre etwa die Prüfung auf eine installierte Version von Git:

$ java -jar .../jenkins-core-*.jar "Monitoring Git" git –version $ # beziehungsweise unter Windows $ java -jar ...\jenkins-core-*.jar "Monitoring Git" cmd.exe /c git –version

Das Ergebnis können Sie dann sowohl in der Konsole, als auch über die Weboberfläche begutachten. Je nach Rückgabewert der Shell wird der Job als erfolgreich oder fehlgeschlagen markiert. Um die genannten Kommandos nicht ständig manuell ausführen zu müssen, bietet sich natürlich ein Cronjob oder ein anderes Projekt an, in dem vor dem eigentlichen Build via Shellskript der entsprechende Befehl ausgeführt wird (siehe Kapitel 4, Abschnitt „Buildverfahren“).

Hierbei handelt es sich um die komplexeste Möglichkeit eines Jenkins-Jobs. Nach der Auswahl dieses Jobtyps ist es möglich, hoch konfigurierbare Jobs zu erstellen, die mittels verschiedener Optionen ein Testen unterschiedlicher Umgebungen erlauben. So wäre es denkbar, ein und denselben Job mit mehreren Datenbanken plattformspezifisch zu bauen. Somit ist es vor allem bei plattformübergreifender Entwicklung, wie es bei Java oder Python oft der Fall ist, möglich, nahezu alle Eventualitäten abzudecken.

Ein weiterer interessanter Anwendungsfall wäre der Test einer Extension für unterschiedliche Versionen der gleichen Software. Nach jedem Commit wäre somit innerhalb kürzester Zeit eine genaue Aussage über die Kompatibilität des Produkts verfügbar.

Als letzten möglichen Anreiz für den Einsatz eines Multikonfigurationsprojekts möchte ich die unter den Webdesignern weitverbreitete Differenz zwischen verschiedenen Browsern anmerken. Durch die Verwendung eines solchen Projekttyps können Sie relativ einfach innerhalb eines einzigen Projekts sämtliche für Ihre Applikation relevanten Browser testen. Eine enorme Zeitersparnis – von den Nerven ganz zu schweigen. Diese Art von Jobs werden im zweiten Teil des Buchs behandelt.

Hinter dieser Option verbirgt sich ein simples Textfeld, das mittels Autovervollständigung bereits eingerichtete Jobs als Ausgangsbasis für den neu zu erstellenden vorschlägt. Mit solch einem vorkonfigurierten Rohling lässt sich natürlich ein Großteil des Konfigurationsaufwandes sparen.

Achten Sie allerdings darauf, nicht beliebige Jobs von einem bestehenden Job abzuleiten. Dies kann schnell zu einer Art »Copy/Paste« führen, was genau wie in der Entwicklung der Software selbst, nie eine gute...