Jenkins soll eine Cloud-Native-Version und schnellere Releases bekommen

Kohsuke Kawaguchi, Jenkins-Erfinder und CTO von CloudBees, hat neue Pläne für den Continuous-Integration-Server (CI) Jenkins vorgestellt. Genauer handelt es sich um zwei konkrete Ideen: Cloud Native Jenkins und ein schnellerer Entwicklungszyklus für Jenkins 2. Damit will Kawaguchi wohl vor allem das Interesse an Jenkins bei potenziellen Nutzern schüren, die sich bis jetzt wenig für den CI-Server interessiert haben. Er spricht davon, dass Jenkins zwar einen bemerkenswerten Weg hinter sich habe, im Moment jedoch in einem lokalen Optimum feststeckte, dass es zu durchbrechen gelte.

Kubernetes als Laufzeit

Bereits im Juli hatten die Jenkins-Macher eine Reihe von Special Interest Groups (SIG) gestartet, die die Entwicklung des CI-Servers vorantreiben sollen. Auf der Gruppe für Cloud Native aufbauend, möchte Kawaguchi jetzt laut seinem Blogbeitrag Cloud Native Jenkins als Unterprojekt etablieren. Wie das Projekt genau aussehen wird, ist zwar noch unklar, Kawaguchi hat allerdings bereits einige Vorschläge, die er als gegeben betrachtet. Demzufolge sollte Cloud Native Jenkins auf die Containerorchestrierung Kubernetes als Laufzeitumgebung nutzen. Dadurch sollte das Projekt auf Serverless beziehungsweise Function as a Service (FaaS) als Build-Ausführung setzen und einige Funktionen separat als Microservices deployt werden. Diese Designprinzipien sollen laut Kawaguchi wünschenswerte Effekte wie eine beliebig hohe Skalierbarkeit, Unveränderlichkeit und Bedienbarkeit ohne Ausfallzeit ermöglichen.

Darüber hinaus soll Cloud Native Jenkins einen neuen Mechanismus für Erweiterungen erhalten. Ein Aufbau auf Microservices beziehungsweise Container könnte das Instabilitätsproblem der Services lösen. Einen genauen Fahrplan bietet Kawaguchi allerdings noch nicht. Außerdem sollten die gespeicherten Daten weg vom Dateisystem in einen Datendienst mit Cloud-Zugriff wandern und Jenkins Configuration as Code einen größeren Stellenwert einnehmen. Cloud Native Jenkins soll so aufgebaut sein, dass es einfach mit Jenkins X zusammenarbeitet.

Ziel der Entwicklung soll sein, ein "Minimum Viable Product" auf die Beine zu stellen, dass eine FaaS-Build-Engine einsetzt und unter Jenkins X laufen kann. Es soll auf den Ansätzen von Jenkins Pipeline, Jenkins Evergreen, Jenkinsfile Runner und Jenkins Configuration as Code aufbauen. Ein grafisches Interface ist zunächst nicht vorgesehen.

Mehr Tempo für Jenkins 2

Mehr Infos

Jenkins auf der Continuous Lifecycle

Die vom 13. bis 16. November in Mannheim stattfindende Continuous Lifecycle bietet Vorträge und Workshops zum Thema Jenkins. Bis zum 21. September gilt der Frühbucherrabatt.

Während Cloud Native Jenkins auf die Zukunft in der Cloud setzt, soll Jenkins 2 jedoch nicht einfach wegfallen. Kawaguchi erklärt, dass Cloud Native Jenkins zu Beginn nicht von jedem Anwender gebraucht werden kann, weshalb sich Jenkins 2 ebenfalls weiterentwickeln muss – aber in erhöhter Geschwindigkeit.

Inspiriert vom neuen Releasezyklus von Java SE,soll Jenkins in Zukunft deutlich häufiger mit neuen Versionen aufwarten. Ziel ist es, Nutzern schneller wichtige neue Features zu liefern, auch wenn dies bedeutet, dass die bisher vorherrschende "Für immer kompatibel"-Mentalität keinen Bestand mehr hat. Anwender sollten sich auf Breaking Changes und häufigere Migrationen einstellen – auch wenn die Bedürfnisse der Nutzer im Vordergrund stehen sollten und jedes neue Release genug Mehrwert bieten sollte, um die Unannehmlichkeiten zu rechtfertigen. (bbo)