Jenkins 2.0: Glorreiche Gegenwart für das Standardwerkzeug in Continuous-Delivery-Szenarien

Continuous Delivery und DevOps ohne Jenkins? Kaum vorstellbar. Dass es dazu gekommen ist, ist gewissen Entscheidungen zum richtigen Zeitpunkt und einer ungemein großen Plug-in-Community zu verdanken. Ein Blick zurück und in die Gegenwart von Jenkins.

In Pocket speichern vorlesen Druckansicht
Jenkins 2.0: Glorreiche Gegenwart für Standardwerkzeug in Continuous-Delivery-Szenarien
Lesezeit: 5 Min.
Von
  • Alexander Neumann

Die gestern freigegebene Version 2.0 des Continuous-Integration-Servers Jenkins wird als erstes Hauptrelease nach 10 Jahren zelebriert. Damals hieß Jenkins allerdings noch Hudson und war ein von Sun Microsystems gefördertes Softwareprojekt. Das war zu einer Zeit, in der das Thema Continuous Integration beileibe noch nicht die Rolle von heute spielte, selbst wenn Grady Booch den Begriff schon Anfang der 90er-Jahre prägte und Kent Beck ihn als einen Bestandteil von Extreme Programming ausmachte.

Der Chef-Entwickler Kohsuke Kawaguchi entwickelte Hudson ursprünglich als Werkzeug zur Automatisierung von Tests, später wurde das Tool als Alternative zu dem von ThoughtWorks-Mitarbeitern entwickelten CruiseControl positioniert. Gerade in der Java-Community erhielt es schnell Zuspruch: Aufgrund zunehmender Verbreitung folgten Integration in nahezu alle maßgeblichen Werkzeuge des Softwareentwicklungsprozess, auf der JavaOne 2008 bekam Hudson dann den Duke's Choice Award.

Doch 2010 folgte die Sun-Übernahme durch Oracle, und wie viele bekannte Softwareentwickler zog es Kawaguchi vor, den neuen Java-Statthalter zu verlassen. Er plante, ein eigenes Unternehmen mit einem auf Hudson basierenden Geschäftsmodell zu starten, um dann Ende 2011 beim Start-up-Unternehmen CloudBees, einem Betreiber einer Platform as a Service mit Fokus auf Continuous Integration, einzusteigen.

Ungefähr zu der Zeit kam es dann zum Zerwürfnis zwischen der Hudson-Community aufgrund des Entwicklungsprozesses mit der Folge, dass Jenkins als Fork des CI-Servers geboren wurde. Hudson bekam schließlich viel zu spät eine Heimat bei der Eclipse Foundation und spielt seitdem nur noch eine vernachlässigbare Rolle. Für Jenkins ging es damals so richtig los, was auch daran lag, dass das Thema Continuous Integration zur zentralen Komponente des neuen Hypes Continuous Delivery wurde.

Die Technik kam mittlerweile nicht mehr nur in der Java-Entwicklung zum Einsatz, und die Community wuchs und wuchs: So zählten die Jenkins-Entwickler Anfang 2013 bereits mehr als 53.000 Installationen und gut 600 Plug-ins; etwas mehr als ein Jahr später waren es dann schon über 80.000 Installationen und gut 900 Plug-ins. Heute sind es über 1200 Plug-ins, so Sacha Labourey, Gründer von CloudBees, im Gespräch mit heise Developer. Hier zeigt sich auch schon das große Plus von Jenkins: die Möglichkeit, relativ einfach eigene Plug-ins schreiben oder auf einen großen Pool bereits bestehender frei verfügbarer Erweiterungen zugreifen zu können, was in Zeiten von Continuous Delivery, in denen alles mit allem integriert werden soll, eine wichtige Errungenschaft ist.

Jenkins entstand als Werkzeug für Java-Entwickler, ist aber schon länger in anderen Communitys zu Hause, wie die "2015 Jenkins Community Survey" zeigte.

Für CloudBees mit Kawaguchi als späterem CTO an Bord wurde das Thema Jenkins zum bestimmenden Geschäft, sodass man sich 2014 entschied, das bisherige Leitthema PaaS hintenan zu stellen beziehungsweise in Teilen gar aufzugeben und ganz auf das Thema Continuous Delivery mit Jenkins zu setzen. Seitdem scheint die Erfolgsgeschichte von CloudBees ungebrochen weitergegangen zu sein. Denn das Unternehmen hat etliche Millionen US-Dollar an Risikokapital einheimsen können und plant nun, sich stärker in Europa zu zeigen. Das bedeutet, man will an Personal zulegen und außerdem seine Marketing-Aktivitäten ausbauen. Denn die Erfahrung hat gezeigt, dass Jenkins sehr bekannt ist – Umfragen zufolge ist von mehr als 70 Prozent Verbreitung die Rede –, aber das maßgebliche Unternehmen dahinter wird nur bedingt wahrgenommen. Das zu ändern, ist vor dem Hintergrund, dass CloudBees gerade im Cloud-Kontext mit etlichen anderen Angeboten wie Travis CI, Circle CI, Snap CI und GitLab konkurriert, nachvollziehbar.

Die wesentliche Neuerung in Jenkins 2.0 ist die Integration einer Delivery-Pipeline, mit der das Tool den Schritt zum vollwertigen Continous-Delivery-Werkzeug machen soll. Mit ihr soll die Software nicht nur kontinuierlich gebaut, sondern auch in verschiedene Umgebungen verteilt werden. Hierfür gab es bislang nur externe Plug-ins, die nun aufeinander abgestimmt in Jenkins selbst zu finden sind. Hiermit folgt CloudBees auf die Konkurrenz von Concourse und Go, die ein solches Feature bereits implementiert haben, und natürlich darauf, dass Anwender mittlerweile genau solche Continuous-Delivery-Szenarien umsetzen müssen.

Um mit der Vielzahl an Erweiterungen zurechtzukommen, wurden nun außerdem aufgabenorientierte Plug-in-Pakete über die neue Quick-Start-Benutzeroberfläche bereitgestellt. Das ist ganz klar als weitere Professionalisierung zu sehen. Denn zwar konfigurieren sich viele Entwickler, vor allem im Open-Source-Umfeld, ihr Jenkins selbst, doch im Unternehmenskontext, gerade bei größeren Entwicklungsteams, sind solche vorkonfigurierten Einheiten willkommen.

Denn der gewinnbringende Einsatz von Jenkins ist davon abhängig, welche Plug-ins ein Team einsetzt und wie es die Installation aufzieht und wartet. Im Fall von Continuous Delivery ist das umso wichtiger, weil dabei zunehmend mehr Jobs, Aufgaben und Techniken zum Einsatz kommen. Darüber hinaus spielt der Kontext, in dem das System zum Einsatz kommt, eine große Rolle, ob Cloud oder On-premise. Da jedoch für nahezu alle erdenklichen Anwendungsfälle "Lösungen" existieren und viele Entwickler über entsprechendes Know-how verfügen, scheint für Jenkins die Zukunft auf noch lange Zeit gesichert zu sein.

Ob das dann bis zur Version 3.0 wieder 655 wöchentliche Releases sein müssen, steht auf einem anderen Tablett ... (ane)