© Frank Peters, 123RF

Der Jenkins-Erfinder Kohsuke Kawaguchi hat in einem Blogpost und nach Absprache mit einigen Hauptentwicklern einen neuen Kurs für den CI/CD-Dienst vorgeschlagen. Er möchte nicht nur, dass die Entwicklung von Jenkins 2 Fahrt aufnimmt, sondern auch eine Cloud-Native-Version zu Wasser lassen.

Glaubt man Jenkins-Erfinder Kohsuke Kawaguchi, steckt die quelloffene Continuous-Integration-Software Jenkins [1] in einem “lokalen Optimum” fest. Jenkins gefalle zwar traditionellen Nutzern, kann aber keine neuen Anwender anheuern. Zugleich wachse um Jenkins herum neue Konkurrenz heran [2].

Zugleich habe sich die CI-CD-Landschaft in den letzten Jahren komplett verändert. Waren Continuous Integration (CI) und Delivery (CD) beim Projektstart noch neu, sei beides heute selbstverständlich und oft zentraler Bestandteil vieler Dienste. Zwar sei Jenkins in den letzten zehn Jahren zur Erfolgsgeschichte geworden, doch einige Probleme seien mitgewachsen und nicht gelöst.

Die Nutzer wollen heute mehr Plugins, mehr Workloads und mehr Verfügbarkeit von Jenkins, was die Software an ihre Grenzen bringe. Laut Kawaguchi ist die Software zu komplex. Der Betrieb einer (größeren) Jenkins-Instanz erfordere zu viel Overhead, mitunter seien tägliche Neustarts nötig. Probleme bereiten unter anderem die Pipeline Execution, Amok laufende Prozesse und der Speicherbedarf. Alles Dinge, die Admins heute nicht mehr tolerieren würden.

Upgrade-Schmerzen

Zugleich würden viele Admins zögern Jenkins und seine Plugins zu aktualisieren, weil ihnen dieser Schritt immer mal wieder auf die Füße falle. Auch beim Anpassen von Jobeinstellungen würden mitunter ungewollte Nebeneffekte auftreten. Das zeichne das Bild einer Testsoftware, die selbst schlecht getestet sei. Zugleich würden die dadurch verursachten Probleme das Jenkins-Projekt selbst aufhalten: Statt vorwärts zu gehen, schlagen sich die Entwickler mit Kompatibilitätsproblemen herum.

Jenkins funktioniert laut Kawaguchi traditionell nach dem Lego-Prinzip. Admins greifen sich die Teile heraus, die sie brauchen, und montieren ihre Lösung zusammen. Doch dieses Prinzip sei heute nicht mehr angemessen, mehr Plugins seien keine Lösung. Im Gegenteil: Jenkins müsse deutlich einfacher zu benutzen sein und im Handumdrehen einsatzbereit. Das würde helfen Nutzer besser zu unterstützen und halte die Entwickler-Community am Laufen.

Für die genannten Probleme bietet Kawaguchi zugleich eine Lösung an. Seine Firma Cloudbees wolle die Probleme zusammen mit dem Projekt angehen. Um dieses Ziel zu erreichen, müsse das Projekt zwei Schlüsselziele verfolgen: Einerseits ein Cloud Native Jenkins aus der Taufe heben, andererseits bei der Jenkins-2-Entwicklung einen Zahn zulegen.

Cloud Native Jenkins

Eine generalisierbare CI/CD-Engine, die auf Kubernetes läuft, ist die Idee für Cloud Native Jenkins (CNJ). Dank einer fundamental anderen Architektur und einem neuen Erweiterungsmechanismus soll CNJ künftig auf Basis von Kubernetes beliebig skalieren. Eine eigene Arbeitsgruppe, die Cloud Native SIG, kümmert sich um die Umsetzung.

Den Plänen nach soll CNJ eine Serverless- beziehungsweise FaaS-Build-Execution ermöglichen (die dank Jenkinsfile Runner [3] bereits teilweise existiere) und bestimmte Funktionen als Microservices anbieten. Zudem sollen die Dienste über Custom Resource Definitions (CRDs) mit Kubernetes reden.

Das Speicher-Backend könnten die Entwickler über lokale Dateisysteme hinaus auf Cloud-basierte Speicherlösungen ausweiten. Auch hier sei das Skalieren ein wesentlicher Punkt. Jenkins Configuration as Code (JCasC, [4]) soll dabei eine zentrale Rolle erhalten.

Für die Cloud müsse sich Jenkins nicht komplett neu erfinden. So bereite das Projekt Jenkins X (Abbildung 1, [5]) die Software bereits für den Einsatz in der Cloud und speziell auf Kubernetes vor. Die Entwickler könnten CNJ für Jenkins X anpassen, anschließend könne es als Engine für Jenkins X agieren.

Abbildung 1: Jenkins X (hier ein Screenshot) gehört laut Kawaguchi zu zukunftsweisenden Projekten für Cloud Native Jenkins.

Jenkins Evergreen [6] sei ein Versuch, vom Lego-Prinzip wegzukommen beziehungsweise Jenkins so vorzubereiten, dass Nutzer es schnell zum Laufen bringen. Nicht zuletzt müsse das Projekt die Sicherheit für CNF stärker in den Fokus nehmen (Secure by Design).

Minimum Viable Product

Kawaguchi schlägt vor, zunächst ein Minimum Viable Product zu entwickeln, also einen abgespeckten Prototyp. Dieser solle aus einer FaaS-artigen Jenkins Build Engine bestehen, von der Jenkins X Gebrauch machen könne. Auf diese Weise führe das MVP bestehende Projekte wie Pipeline, Evergreen, Jenkinsfile Runner und JCasC zusammen.

Konkret kann ein Webhook-Empfänger Webhooks von Github empfangen und in der Folge die Build Engine triggern. Die wiederum soll mit Hilfe des Jenkinsfile Runner eine Pipeline Execution ausführen, wobei der Runner als FaaS-Funktion läuft. JCasC-Dateien kümmern sich um Konfiguration und Pluginverwaltung. Mit Evergreen will Jenkins hingegen die Menge an kombinierbaren Plugin-Variationen in den Griff bekommen, zudem soll es als Testumgebung für Cloud Native Jenkins selbst einspringen.

Was dem MVP zunächst noch fehle, sei eine grafische Oberfläche. Vom MVP aus solle das Jenkins-Projekt die Software weiterentwickeln, neue Dienste ergänzen, das Erweiterungssystem überarbeiten und verlorene Features nachholen.

Jenkins 2 Reloaded

Während Cloud Native Jenkins anfangs gar nicht und später nur auf bestimmten Plattformen nutzbar sei, soll Jenkins 2 mit ein paar Änderungen wie gewohnt funktionieren. Um es künftig schneller zu entwickeln und eine höhere Stabilität zu erreichen, sei man aber willens, sich von Komponenten zu trennen. Zugleich erfordere die neue Ausrichtung Änderungen am Entwicklungsmodell.

Das neue Release-Modell solle sich an Jenkins Evergreen orientieren – es werde unweigerlich “Erwartungen enttäuschen”, besonders in Sachen Kompatibilität. Jenkins werde nicht mehr “für immer kompatibel” sein. Das Java-Projekt halte sich die Option auf disruptive Änderungen offen. Wenn das öfter Major-Versionen erfordere, sei Kawaguchi offen dafür. Er orientiere sich dabei am geänderten Entwicklungsmodell für Java SE, das nach einer Neustrukturierung an Fahrt aufgenommen habe.

Natürlich müssten sich die Upgrade-Unannehmlichkeiten für Jenkins-Nutzer am Ende lohnen. Das Projekt solle weitgehend kompatibel bleiben, um existierende Jobdefinitionen und Freestyle Jobs zu schützen. Das gilt aber offenbar nur für bestehende Versionen von Jenkins.

Ferner liefen

Zudem wollen die Entwickler Configuration as Code stärker in den Vordergrund rücken, das Entwickler-Erlebnis durch automatisches Erkennen von Projekttypen verbessern und die Jenkins-Pipeline weiter optimieren. Sie solle am Ende der Umbauten auch gut mit Cloud Native Jenkins zusammenarbeiten.

Daneben planen die Jenkins-Macher die “Feature-Oberfläche” zu reduzieren, um sich auf die wichtigen Komponenten zu konzentrieren. Das Projekt möchte dafür erforschen, welche Dienste Anwender aktuell tatsächlich benötigen und was die Konkurrenz anbietet. Fehlende oder ausrangierte Komponenten könne Jenkins dann nachliefern.

Langfristig solle auch Cloud Native Jenkins eine dank JCasC-Einsatz weniger umfangreiche grafische Oberfläche erhalten. Die will das Projekt aber vermutlich als eigene App und nicht als Plugin umsetzen. Als Vorlage für das neue Userinterface könnte dabei die bisherige Oberfläche Blue Ocean dienen.