Software::Entwicklung
Jenkins soll sich erneuern
Das freie Continuous-Integration-System Jenkins soll sich in zwei Richtungen erneuern. Zum einen soll es nativ in der Cloud laufen können, zum anderen soll sich die Entwicklung beschleunigen, womit öfter als bisher inkompatible neue Hauptversionen entstehen werden. Das kündigt der Jenkins-Gründer Kohsuke Kawaguchi an.
Jenkins entstand als Fallout der Übernahme von Sun durch Oracle. Dadurch war auch das freie Continuous-Integration-System Hudson in den Besitz von Oracle gekommen, dessen Entwickler allerdings in heftigen Streit mit Oracle gerieten, als das Unternehmen nichts für Hudson tat. So zogen die meisten Hudson-Entwickler mit einer Abspaltung von Hudson unter dem Namen Jenkins aus dem Einflussbereich von Oracle weg. In der Folge blühte Jenkins auf und wurde zu einem der erfolgreichsten und wichtigsten Open-Source-Programme. Doch nach Ansicht des Hudson/Jenkins-Projektinitiators Kohsuke Kawaguchi könnte Jenkins seine beste Zeit überschritten haben, daher müsse sich das Projekt jetzt erneuern.
Kawaguchi erklärt in einem langen Blog-Beitrag, dass es mittlerweile eine Reihe ungelöster Probleme in Jenkins gebe. Anfangs vielleicht noch als geringfügig angesehen, führen einige davon dazu, dass die Bedürfnisse mancher Benutzer nicht mehr erfüllt werden können. Manche Probleme betreffen aber auch alle. So gibt es Stabilitätsprobleme bei großen Jenkins-Instanzen. Fehler beim Generieren von Projekten können unter Umständen die Stabilität des gesamten Systems gefährden. Die Vielzahl von Plugins, die bei manchen Anwendern im Einsatz sind, verschärfen das Problem noch.
Die Konfiguration von Jenkins ist laut Kawaguchi auch nicht robust genug. Insbesondere bei der Aktualisierung von Plugins müssen die Administratoren immer fürchten, dass danach etwas nicht mehr geht. Da Jenkins in vielen Entwicklungsprojekten eine kritische Komponente ist, kann sie aber eigentlich keinerlei Ausfallzeiten verkraften. Ferner besteht Jenkins einem relativ funktionsarmen Kern und vielen Plugins. Mit der Standardinstallation kann kaum jemand etwas anfangen - es ist fast immer zusätzliche Arbeit nötig, bis man überhaupt starten kann. Ein weiteres Problem ist, dass die Entwicklung von Jenkins allmählich festfährt: Änderungen, die sich über mehrere Plugins erstrecken, werden immer schwieriger, ebenso wie das Aufrechterhalten der Code-Qualität.
Für Kawaguchi muss Jenkins diese Probleme auf zwei Arten angehen. Zum einen muss es eine Version von Jenkins geben, die nativ in der Cloud (das heißt unter
Kubernetes) läuft. Diese Version soll eine ganz andere Struktur und andere Erweiterungsmechanismen aufweisen. Jenkins wird eine Sammlung von Microservices, statt im Dateisystem werden die Dateien im Datendienst der Cloud gespeichert, alles Nötige wird von Anfang an vorhanden sein und die webbasierte Oberfläche soll stark verbessert werden.
Der zweite Ansatz ist eine beschleunigte Entwicklung von Jenkins. Seit Jenkins 2 von 2016 gibt es alle paar Tage bereits eine neue Version, doch dabei muss stark auf die Kompatibilität geachtet werden, was größere Fortschritte behindert. Kawaguchi will, dem Vorbild von Java folgend, häufiger neue Hauptversionen veröffentlichen, wenn inkompatible Änderungen nötig werden. Dabei muss allerdings abgewogen werden, ob die Änderungen wichtig genug sind, um die damit verbundenen Umstellungen bei den Anwendern zu rechtfertigen. Für CloudBees, die Firma, bei der Kawaguchi Chief Technology Officer (CTO) ist, sind die Probleme wichtig genug, um sie mit erheblichem Einsatz von Personal und Geld anzugehen. Es wird daher nur eine Frage der Zeit sein, bis erste Ergebnisse der neuen Entwicklungen veröffentlicht werden.
