Sobald der Deployment-Prozess mit Jenkins mehrere Stufen annimmt und zusätzlich noch automatisierte Tests in größeren Projekten dazukommen, muss man sich mit dem Thema Skalierung auseinandersetzen. Erschwerend kann hinzukommen, dass mehrere Teams mit Jenkins arbeiten und die fertigen Applikationen für mehrere Kunden in unterschiedlichen produktiven Umgebung bereitstellen sollen. Eine Möglichkeit, Jenkins zu skalieren, ist der Aufbau eines Jenkins-Clusters.

Vor zehn Jahren begann die „DevOps-Revolution“. Was damals noch absolutes Neuland und mehr ein Gedankenexperiment war, ist heute bereits zum Normalfall geworden. Ein wichtiges Tool in dem Zusammenhang ist das Continous-Integration-Werkzeug Jenkins. Sacha Labourey, CEO von CloudBees, spricht im Interview über die aktuellen Entwicklungen im Bereich Jenkins, blickt gemeinsam mit uns auf das vergangene Jahrzehnt von DevOps zurück und gibt einen Ausblick auf die Zukunft des CI-Tools Jenkins und der DevOps-Kultur.

Weiter geht es mit unserer beliebten Quiz-Reihe! Dieses Mal geht es um Jenkins, den freundlichen Butler, der Devs und Ops zusammenbringt. Wir haben wieder ein paar knifflige und weniger knifflige Fragen bereitgestellt. Wie viel wisst ihr über den Anbieter für automatisierte Softwarelösungen?

Continuous Delivery bzw. Integration komplett in der Cloud? Ja, das geht, wie Clemens Utschig-Utschig, CTO und Head of Engineering bei der BI X GmbH, auf der DevOpsCon 2018 in Berlin zeigen wird. Im Interview sprach er darüber, warum gerade auf die Kombination auf OpenShift mit Kubernetes, Jenkins und AWS gesetzt wurde und welche Probleme bei der Etablierung der CI-Pipeline auftraten.

Es gibt viele Services für Continuous Integration, Jenkins ist allerdings noch immer einer der meistgenutzten in vielen Programmiersprachen. In seiner Session von der DevOps Conference 2017 in Berlin erklärt Gianluca Arbezzano, Software Engineer bei InfluxData, wie bei Currency Fair ein Team aus 40 Entwicklern die Software Delivery mit GitHub, Jenkins, Hubot und Slack auf verschiedenen Umgebungen managt.

Das Major-Release von Jenkins im April 2016 machte die Entwicklung von Delivery-Pipelines zur Kernfunktion. Pipelines lassen sich jetzt als Code implementieren, um die Automatisierung der Strecke vom Commit bis ins Produktionssystem besser zu unterstützen. Anfang dieses Jahres sind weitere Neuerungen erschienen, die die Funktionalität ausbauen: eine deklarative Pipelinesyntax und eine moderne Oberfläche, das Blue Ocean UI. Wir beleuchten die neuen Möglichkeiten zur Pipelineentwicklung genauer und berichten, wie sie sich in der Praxis bewähren.

Knapp ein Jahr ist es her, seit das Team von Jenkins mit dem Projekt Blue Ocean eine Revolution der User Experience auf den Weg gebracht hat. Gestern war es schließlich soweit: Mit Blue Ocean 1.0 wird bei Jenkins, zumindest in Sachen UX, die Zukunft von Continuous Delivery eingeläutet.

Wenn um das Thema Continuous Delivery geht, kommt man um den Build-Server Jenkins nicht herum. Halil-Cem Gürsoy (adesso) hielt auf der W-JAX 2016 einen Einführungsvortrag zu Jenkins 2.0. Dabei zeigte er auch auf, das nicht alles Gold ist, was Jenkins heißt.

Die Jenkins-Entwickler haben angekündigt, dass das Continuous Integration Tool bald nur noch auf Java 8 laufen wird. Gründe seien der End of Life von Java 7 und die neuen Sprach-Features von Java 8.

Beim Thema Continuous Integration gehört Jenkins nach wie vor zu den Besten. Aber den Takt geben immer öfter andere an. Wir geben ihm den Groove zurück. Wir zeigen, wie man mit der Groovy-Job-DSL Builds erstellt und komplexe Abläufe mit der Groovy-Workflow-DSL beschreibt. So let’s get groovy!

Der Knigge der offenen Softwareentwicklung sieht vor, nach diversen Alpha- und Beta-Versionen Kandidaten für das finale Release zu präsentieren. Folge leistet der populäre Continuous-Integration-Server Jenkins, der nach der Beta-Version letzte Woche nun den ersten Release-Kandidaten für Jenkins 2.0 vorlegt und – das mag für viele die wichtigere Meldung sein – dabei Hinweise auf das Veröffentlichungsdatum der finalen Version preis gegeben hat.

Joel Spolskys im Jahr 2000 erschienener Joel Test schlug die tägliche Erzeugung von teamweiten Builds vor. Als Continuous-Integration-Server bezeichnete Systeme lösen dieses Problem automatisch – sie kompilieren die von ihnen verwalteten Elemente – nomen est omen – permanent. Doch was können die einzelnen CI-Server, und welcher ist der richtige für mein Projekt?