it-swarm.com.de

Job DSL Plugin Vs Pipeline Plugin

Was ist der Hauptunterschied zwischen Job DSL Plugin und Pipeline Plugin

  1. beides ermöglicht die programmatische Schaffung von Arbeitsplätzen
  2. welches ist das Beste, um voranzukommen und warum?
  3. wenn beide ähnliche Funktionen haben, haben sie unterschiedliche Anwendungsfälle?
  4. Bedeutet das, dass Jenkins 2.0 sich auf Pipelines als Code konzentriert, dass job-dsl keine Zukunft hat oder dass das Pipeline-Plugin der nächste Schritt im Job-DSL-Plugin ist?
55

Ich habe umfangreiche Erfahrung mit beiden. Eine prägnante Antwort ist, dass Job DSL schon viel länger existiert und Netflix Open Source-Lösung für das "Codieren" von Jenkins war. Es ermöglichte Ihnen, Logik und Variablen in die Skripterstellung Ihrer Jenkins-Jobs einzuführen, und normalerweise verwendete man diese Jobs, um eine Art "Pipeline" für ein bestimmtes Projekt zu erstellen. Dieses Plugin hat als gängige Methode zum Erstellen von Vorlagen und zum Erstellen von Skripten einiges an Unterstützung erhalten.

Jenkins Pipeline (2.0) ist eine neue Inkarnation eines Jenkins-Jobs, der vollständig auf DSL basiert und versucht, die Notwendigkeit zu beseitigen, mehrere Jobs zusammenzufügen, um eine einzige Pipeline zu füllen, die bei weitem die häufigste Verwendung von Job DSL war. Da Pipeline-DSL ursprünglich nicht viele der Funktionen bietet, die Job-DSL bietet, und wie oben erwähnt, können Sie mit Job-DSL Pipeline-Jobs erstellen, die zusammen zum Definieren einer Pipeline verwendet werden können.

Heutzutage gibt es laut IMO kaum einen Grund, Job DSL zu verwenden, da Pipeline der von Jenkins unterstützte Mechanismus zum Erstellen von Skripten für Jenkins-Pipelines ist und einen Großteil der Funktionen von Job DSL erfüllt oder übertroffen hat. Neue Plugins werden für Pipeline entwickelt, und solche, die von Jenkins-Entwicklern nicht ermutigt werden, sich in Pipeline zu integrieren. Und Pipeline hat mehrere Vorteile:

  • Es ist nicht erforderlich, Jobs mit Pipeline zu "seeden", wie dies bei Job DSL der Fall ist, da die Pipeline der Job selbst ist . Bei Job DSL ist es nur ein Skript, das andere Jobs erstellt .
  • Mit Pipeline verfügen Sie über Funktionen wie einen parametrisierten manuellen Eingabeschritt, mit dem Sie die Logik in der Pipeline festlegen können
  • Die Logik, die in einer Job-DSL enthalten sein kann, beschränkt sich auf die Erstellung der Jobs selbst; Mit Pipeline können Sie Logik direkt in den Job einbinden.
  • Job-DSL ist viel schwieriger zu erstellen, wenn Sie beispielsweise das Build Pipeline Plugin verwenden. Mit Pipeline wird Ihre Datei kleiner und die Syntax kürzer. Und wenn Sie Job DSL zum Erstellen von Pipeline-Aufträgen verwenden, habe ich angesichts der Vorlagenfunktionen, die bei Jenkins Pipeline standardmäßig verfügbar sind, keinen größeren Nutzen mehr gesehen.

Schließlich ist die Jenkins-Pipeline derzeit mit Abstand das am weitesten verbreitete Merkmal von Jenkins. Schauen Sie sich die Jenkins World 2016 Agenda an und Sie werden ca. sehen. 50% der Sitzungen beinhalten Pipeline. Keine für Job DSL.

62
Neil

Mein Gefühl ist der ideale Ansatz, beides zu nutzen. Pipeline ist die neue native Jenkins-Funktion, um Jobs als Code zu haben. Wenn Sie Jenkins jedoch von Grund auf neu erstellen, müssen diese Jobs noch erstellt werden. Dies bedeutet, dass Jenkins nicht zu 100% aus Code erstellt werden kann.

Sie können JOB DSL verwenden, um die Grundstruktur aller Jobs zu erstellen, und dann die Pipeline für die Implementierung der Jobs verwenden. Auf diese Weise können Sie zu 100% Jenkins-Skripts erstellen, abzüglich des ersten zu erstellenden Startjobs.

Vielleicht können wir Jenkins (Sicherheit, Konfiguration und sogar Plugins) mit Pipeline vollständig steuern. Aber bis dahin halte ich es für einen guten Ansatz, DSL und Pipeline zu verwenden.

21
CodyK

Es gibt einen wichtigen Unterschied, der hier noch nicht erwähnt wurde: Testen. Mit job-dsl können Sie den DSL-Code testen, bevor Sie ihn an SCM senden: https://github.com/sheehan/job-dsl-gradle-example - Dies ermöglicht eine lokale Testsuite auf DSL-Code ausgeführt werden, sowie in Jenkins, bevor der Code ausgeführt wird. Soweit mir bekannt ist, gibt es im nativen Pipeline-Ansatz kein Äquivalent.

2
Andrew

Meine vorläufige Antwort basiert auf sehr begrenzten Erfahrungen:

  • Jeder verwendet eine andere Groovy DSL.
  • Mit Job DSL können Sie andere Jobs gemäß einem Groovy-Skript erstellen. Wenn Sie also eine Reihe von X-bezogenen Jobs (z. B. eine Pipeline) möchten, erstellen Sie einen Job-DSL-Job, schreiben das Skript, führen diesen Job aus und haben dann diese X-Jobs sowie den Job, der diese Jobs erstellt . Zu diesem Zeitpunkt wurde nur der Job ausgeführt, den Sie direkt erstellt haben, die von diesem Job erstellten jedoch noch nicht. OOTB, diese Jobs sind nicht ausgeblendet, wie Maven-Module in einem Maven-Job mit mehreren Modulen ausgeblendet sind, aber ich verstehe, dass es zumindest eine Möglichkeit zum Erstellen gibt einen blick werfen und die jobs dort festhalten.
  • Pipeline DSL hängt nur auf unbestimmte Zeit in den 2 sehr unterschiedlichen Umgebungen, in denen ich es ausprobiert habe. : '(Dies ist, wie ich verstehe, ein bekannter Showstopper-Fehler. Suchen Sie und Sie werden einige offene Bug-Tickets finden. Wenn Sie den von Ihnen erstellten Pipeline-Job ausführen, wird die Pipeline tatsächlich ausgeführt, und es werden keine Jobs wie der Job-DSL generiert Trigger zum Ausführen des Pipeline-Jobs sind also Trigger zum Ausführen der Pipeline und nicht nur zum Aktualisieren der von ihr definierten Jobs.
  • Nach den Download-Zahlen scheint die Pipeline weiter verbreitet zu sein. Natürlich ist Pipeline eine Standardfunktion von Jenkins 2.0, die möglicherweise den jüngsten Anstieg der Downloads berücksichtigt. Die Betreuer von Jenkins möchten sicher, dass Sie es verwenden .

Um es noch einmal zusammenzufassen: Das DSL von Job DSL dient zum Erstellen von Jobs, die eine Pipeline bilden. Das DSL von Pipeline Plugin definiert die Pipeline selbst.

Und um Ihre Frage (n) zu beantworten: Pipeline sollte in Zukunft umfassender unterstützt werden, sieht für mich einfacher aus (der Job ist ein Job, kein Metajob) und scheint mehr Funktionen (einschließlich Workflow) zu haben. Ich würde es benutzen, wenn Sie nicht den oben genannten Showstopper-Bug von Doom treffen und keinen Fix/Workaround finden.

2
Jason Young