Der Sprint näherte sich dem Ende, die letzten Änderungen waren eingecheckt und alle Tests sind erfolgreich durchgelaufen. Es war also an der Zeit die neuen Features auf das Demo-System unseres Kunden zu deployen. Eigentlich kein Problem, schließlich sind das lediglich ein paar Klicks auf der Jenkins-Oberfläche und alles Weitere geschieht ganz von selbst und bedarf keiner weiteren Anstrengungen. Zumindest war das früher einmal so. Aus dem kleinen Projekt hat sich mittlerweile ein relativ komplexes System aus verschiedensten Web- und Clientanwendungen entwickelt. Und so wuchs auch die Anzahl der Deployment-Jobs auf über zehn an. Das Deployment an sich wurde zu einer eigenen Wissenschaft. Das spiegelte sich auch in der Bereitschaft der Teammitglieder wieder, diesen Task zu übernehmen.
Durch einen Artikel im Java Magazin wurden wir auf eine neue Version des Jenkins und das darin enthaltene Pipeline-Plugin aufmerksam.
Die spannendste Neuerung war die Möglichkeit, einen Jenkins-Job ausschließlich über Groovy Code zu erstellen. Getreu dem Motto “Code over configuration” klang diese Tatsache erst einmal sehr reizvoll und es war klar, dass wir diesem Thema mehr Zeit widmen mussten.
Der erste Schritt war es unseren Jenkins auf den neuesten Stand zu bringen und alle notwendigen Plugins für die Pipeline zu installieren. Der erste Pipeline Job war schnell angelegt und wie erwartet besteht dieser im Grunde aus einer Eingabe für den Namen und einer Textarea für den Groovy Code.
- aus unserem Git-Repo ausgecheckt
- mit Maven gebaut
- und auf unseren Server deployed werden.
Das Gleiche musste nun nur noch für die anderen Archive wiederholt werden. Allerdings lag die gesamte Logik im Job selbst und müsste somit für jeden anderen Job kopiert werden. Als verantwortungsbewusste Softwareentwickler schrillten hier sofort die Alarmglocken. Glücklicherweise bietet das Pipeline Plugin eine weitere Möglichkeit einen Job zu definieren: das Jenkinsfile.
Hier kann man die Definition des Jobs in ein separates File auslagern und in einem Repository ablegen. Außerdem gibt es die Möglichkeit globale gemeinsam nutzbare Bibliotheken bereitzustellen. In unserem Fall beinhalten diese die gesamte Logik unseres Deploymentprozesses und werden von jedem Job verwendet. Genauere Infos dazu gibt es unter https://jenkins.io/doc/book/pipeline/shared-libraries/
Zusammenfassend kann man sagen, dass sich die Anzahl der Jobs deutlich verringert hat und unser Jenkins wesentlich übersichtlicher geworden ist. Durch die Wiederverwendbarkeit des Codes sind wir äußerst flexibel und können in Zukunft schnell auf Änderungen reagieren. Die Minimierung des Konfigurationsaufwandes und Verlagerung des Codes in ein Git-Repository ermöglicht uns alle Vorteile einer Versionsverwaltung zu nutzen. Und zu guter Letzt sind wir jetzt auch wieder im Stande mit einem einzigen Klick zu deployen.
