Jenkins 2.0 wird zum vollwertigen Continuous-Delivery-Werkzeug

Inhaltsverzeichnis

CloudBees hat offiziell die Verfügbarkeit des CI-Servers (Continuous Integration) Jenkins 2.0 bekanntgegeben, der zunächst als Alpha seit Anfang März öffentlich erhältlich ist. Die Schritte über Beta- und Release-Candidate gingen zügig voran und konzentrierten sich auf Feinschliff.

Die wesentliche Neuerung in Jenkins 2.0 ist die Integration einer Delivery-Pipeline, mit der Jenkins den Schritt zum Continous-Delivery-Werkzeug macht, das die Software nicht nur kontinuierlich baut, sondern sie auch in verschiedene Umgebungen verteilt. Das Konzept einer Pipeline war ursprünglich nicht in der Software vorgesehen, aber es existieren einige Plug-ins. Bei Wettbewerbern im CI/CD-Umfeld wie Concourse und dem von ThoughtWorks entwickelte Go, das inzwischen wie Jenkins Open Source ist, gehören die Pipelines zum Lieferumfang.

Eigene Programmiersprache zur Steuerung

Zur Durchführung der Prozesse setzt Jenkins auf eine DSL (domain-specific language), mit der Entwickler die Delivery-Pipeline in einem Jenkinsfile speichern, das sie zusammen mit dem Quellcode des Projekts in einem Versionsverwaltungssystem ablegen können. Jenkins verwaltet unterschiedliche Pipelines für verschiedene Git-Branches. Die Software erkennt zudem Team-Repositories (Organisations) auf GitHub und BitBucket und automatisiert den Bau von dort gespeicherten Jenkinsfile-Dateien. Eine Stage View gibt eine Übersicht darüber, wie lange die einzelnen Phasen benötigt haben und ob sie erfolgreich waren.

Kurz vor der Ankündigung von Jenkins 2.0 sprach heise Developer mit Kohsuke Kawaguchi, der die Software ursprünglich bei Sun Microsystems unter dem Namen Hudson entwickelte und jetzt CTO von CloudBees ist. Er begründet die erste Hauptversion seit 1.0 vor allem mit den geänderten Voraussetzungen: "Wir haben Jenkins ursprünglich als Werkzeug zur Automatisierung von Tests entwickelt, aber jetzt wird es auch für den ganzen Prozess der Produktion verwendet". Im vergangenen Jahr habe sich das Team deshalb überlegt, dass es Zeit sei, die Software entsprechend umzugestalten. Daher habe man sich entschieden, eine neue Hauptversion von Jenkins zu veröffentlichen, statt wie bisher das Konzept der regelmäßigen Updates fortzuführen.

Vorhandene und neue Nutzer

Ein wichtiger Schritt dabei sei aber die Rückwärtskompatibilität gewesen. "Alle Plug-ins sind kompatibel zu 2.0", so Kawaguchi, "nur so können wir die Nutzer dazu bekommen, zur neuen Version und dem neuen Pipline-Modell zu wechseln". Der direkte Austausch durch ein Update soll problemlos möglich sein. Gleichzeitig denke man an neue Nutzer, denen die Macher den Einstieg erleichtern wollen: "Die vorhandene Mentalität setzte auf einen minimalen Kern plus individuelle Plug-ins. Der Ansatz für 2.0 ist, dass wir ein Produkt mit genügend Funktionen ausliefern, sodass die Anwender direkt produktiv sein können", sagte Kawaguchi. Zwar setzt Jenkins weiterhin auf Plug-ins, aber hilft neuen Nutzern mit einer optionalen Installation von Erweiterungen, die von der Community empfohlen werden.

Eine kurze Historie

Kohsuke Kawaguchi hat 2005 als Entwickler bei Sun Microsystems das Projekt Hudson ins Leben gerufen. Die Idee hinter dem Werkzeug war die zentrale Verwaltung von Softwareänderungen, um Fehler schneller zu finden und Projekte besser zu integrieren. Die Übernahme durch Oracle führte wie bei anderen Projekten auch bei Hudson zu Unstimmigkeiten. Kawaguchi und ein großer Teil des Hudson-Teams verließen daraufhin Oracle und erstellten einen Fork der Software. Da die Namensrechte jedoch bei Oracle blieben, benannten sie ihre Variante in Jenkins um und behielten damit die Butler-Analogie bei. Kohsuke Kawaguchi ist inzwischen CTO der Firma CloudBees, die die Entwicklung von Jenkins maßgeblich vorantreibt und gleichzeitig eine kommerzielle Variante anbietet.

Weitere Details finden sich im Blog-Beitrag zur Veröffentlichung sowie der Übersicht über Jenkins 2.0. Dort steht die Software auch zum Herunterladen bereit. (rme)