Kontakt


Wir verwenden HubSpot CRM, um Kontakt- und Informationsanfragen zu bearbeiten und zu verwalten. Bitte akzeptiere die "Funktionalen Cookies" und lade die Seite erneut, um das Kontaktformular zu laden.

Insights / Blog / Tech

Die wichtigsten Schlussfolgerungen von der Jenkins User Conference

07. Oktober 2015
Autor:in Stefan RotschStefan RotschSenior Solution Architect

Tomas Norre Mikkelsen und ich hatten vor Kurzem die Gelegenheit, die Jenkins User Conference U.S. West in Santa Clara, Kalifornien zu besuchen.

Die Konferenz an der US-Westküste ist die weltweit größte Zusammenkunft von Anwendern und Entwicklern des Continuous Integration-Systems Jenkins, welches eine zentrale Komponente der Softwareentwicklung bei AOE darstellt. Aus diesem Grund war es spannend und wertvoll, Einblicke in die zukünftige Entwicklung des Projekts sowie Nutzungsszenarien bei großen Unternehmen wie Google oder Yahoo! gewinnen zu können.

Einige der Konzepte und Methoden, die sich wie ein roter Faden durch die zahlreichen Vorträge zogen, sollen im Folgenden kurz vorgestellt werden:

Jenkins ♥ Docker

Die wahrscheinlich am häufigsten beschriebenen Szenarien widmen sich dem Zusammenspiel von Jenkins und der Virtualisierungslösung Docker. Kernthema ist dabei das Erstellen von Containern mit Hilfe von Jenkins als Teil der Continuous Delivery-Pipeline. Darüber hinaus gewinnt jedoch auch das Ausführen von Jenkins selbst innerhalb eines Containers immer mehr an Bedeutung, stellt dies doch eine Voraussetzung für einfaches Skalieren und den Betrieb in der Cloud dar – einzelne Präsentationen berichteten in diesem Zusammenhang von Clustern mit mehreren hundert Jenkins Slave-Instanzen.

Nicht unerwähnt bleiben sollte an dieser Stelle, dass Jenkins gleichfalls eines der zentralen Themen der diesjährigen internationalen Docker-Konferenz DockerCon war.

Pets vs. Cattle

Von der einzelnen, handgepflegten Jenkins-Instanz (Pets) zum Cluster-Management (Cattle): im Kontext großer, lastabhängig skalierender Jenkins-Installationen stellt die Automatisierung aller beteiligten Prozesse eine große Herausforderung dar. Grundlage dessen bildet das Konzept „Everything as Code“, die programmatische Beschreibung von u. a. Infrastruktur, Konfiguration und Buildprozess. Vorgestellt wurde in diesem Zusammenhang beispielsweise das Jenkins Workflow Plugin, oder aber auch das von Jenkins unabhängige Blazemeter Taurus zum vereinfachten Erstellen von Performance-Tests auf Basis von Apache JMeter.

Rapid Feedback

Jenkins wird häufig nicht nur zur Build-, sondern auch zur Testautomatisierung eingesetzt. Dabei ist entscheidend, allen Projektbeteiligten schnelles Feedback über die Auswirkungen von Änderungen und neuen Features auf Performance und Stabilität des Gesamtprodukts zu geben. Als wichtig wird hier unter anderem das kontinuierliche Erfassen von Metriken an den verschiedenen Stellen des Build-Prozesses erachtet, um automatisiert „gute“ von „schlechten“ Builds unterscheiden zu können. Diese können entsprechend verworfen oder promoted werden und die weitere Delivery Pipeline bis hin zum Produktionssystem durchlaufen.

Zusammenfassung

Abschließend hervorzuheben ist der Vortrag von Fabrizio Branca, der nicht nur mit gewohnt fundierten Einblicken in den Entwicklungs- und Continuous Delivery-Workflow bei AOE zu überzeugen wusste, sondern durch die Präsentation kreativer Eigenentwicklungen aus dem Bereich „Internet of Things“ viele positive Reaktionen der Teilnehmer hervorrief.

Nicht zuletzt aufgrund des Veranstaltungsorts im Herzen des Silicon Valley und zahlreiche Teilnehmer und Referenten von dort ansässigen Unternehmen war es eine spannende Konferenz, deren Besuch mir großen Spaß gemacht hat. Ich freue mich sehr darauf, die neu gewonnenen Erkenntnisse im Rahmen meiner täglichen Arbeit einbringen und umsetzen zu können.