Continuous Integration: Jenkins-Gründer will Software in Cloud-Ära überführen

Der Erfinder der CI/CD-Lösung Jenkins, Kohsuke Kawaguchi, stellt Pläne für die Software vor. Er will die Entwicklung von Jenkins 2 beschleunigen und zugleich eine Cloud-Native-Version veröffentlichen, die auf Kubernetes läuft.

Artikel veröffentlicht am 4. September 2018, 9:45 Uhr, Kristian Kißling/Linux Magazin/Sebastian Grüner

Cloudbees kümmert sich als Hauptsponsor und Enterprise-Dienstleister um Jenkins. (Bild: Cloudbees)

In einem längeren Blogpost führt der Jenkins-Gründer und Cloudbee CTO Kohsuke Kawaguchi einige Probleme auf, die seiner Meinung nach die Software derzeit betreffen. So stecke die Open-Source-Software derzeit in einem "lokalen Optimum" fest. Die CI/CD-Landschaft (Continuous Integration und Continuous Delivery) habe sich demnach in den vergangenen Jahren komplett verändert und das Jenkins-Projekt müsse darauf reagieren. Einerseits soll deshalb eine Cloud-Native-Variante von Jenkins entstehen, andererseits soll das Projekt die Jenkins-2-Entwicklung beschleunigen.

Jenkins sei derzeit zwar Kernbestandteil in vielen Unternehmen, schreibt Kawaguchi, dafür aber zu schwierig zu verwenden und vor allem schwer zu skalieren. Zu den Problemen hinzu komme, dass die Entwickler und Admins auch Angst davor hätten, Jenkins und seine Plugins zu aktualisieren, aus Furcht, Dinge kaputt zu machen. Ebenso sei das ursprüngliche Lego-Prinzip von Jenkins heute nicht mehr angemessen. Entwickler bräuchten stattdessen schlüsselfertige Lösungen, was mit den Neuerungen erreicht werden soll.

Cloud Native Jenkins für Kubernetes geplant

Das geplante Cloud Native Jenkins (CNJ) soll unter anderem eine generalisierbare CI/CD-Engine mitbringen, die auf Kubernetes läuft. Es soll eine fundamental andere Architektur und einen neuen Erweiterungsmechanismus verwenden und dadurch zusammen mit Kubernetes beliebig skalieren. Es soll eine Serverless/FaaS-Build-Execution ermöglichen, bestimmte Funktionalitäten als Microservices und Container anbieten und die Dienste sollen über Custom Ressource Definitions (CRDs) mit Kubernetes kommunizieren. Jenkinsrunner sei hierfür ein Beispiel.

Laut Kawaguchis Vorschlag soll im ersten Schritt ein Minimum Viable Product (MVP) dafür entstehen. Dazu soll das Projekt bestehende Bemühungen von Jenkins Pipeline, Jenkins Evergreen, Jenkinsfile Runner sowie Jenkins Configuration as Code zusammenführen, um eine FaaS-artige Jenkins Build Engine zu bauen, auf die Jenkins X aufsetzen kann.

Eine grafische Oberfläche bringt das MVP zunächst einmal nicht mit, diese könne später ergänzt werden. Dann vermutlich aber als Cloud Native App, nicht als Plugin.

Schnellere Entwicklung von Jenkins 2

Neben der Cloud-Version soll das Projekt nach Vorstellung von Kawaguchi und weiteren Entwicklern Version 2 weiter voranbringen, dabei aber die Arbeiten deutlich beschleunigen. Man will sich notfalls auch von einigen Komponenten trennen, um künftig schneller zu entwickeln und eine höhere Stabilität zu erreichen.

Einige Kernentwickler denken über ein neues Release-Modell nach. Jenkins werde dann nicht mehr "für immer kompatibel" bleiben, sondern neue Major-Versionen einführen, die Upgrades erfordern. Zugleich will man helfen, existierende Jobdefinitionen und Freestyle-Jobs zu bewahren.

Weitere Vorschläge sehen vor, Configuration as Code stärker in den Vordergrund zu rücken und zu beschleunigen, die Entwicklererlebnisse durch automatisches Erkennen von Projekttypen zu verbessern und die Jenkins Pipeline weiter zu optimieren. Zugleich wolle das Entwicklerteam die angebotenen Funktionen sinnvoll und nach Absprache mit der Community reduzieren. Weitere Vorschläge und Details liefert der Blog-Eintrag von Kawaguchi.