GitLab CI vs. Jenkins [geschlossen]

129

Was ist der Unterschied zwischen Jenkins und anderen CIs wie GitLab CI, drone.io, die mit der Git-Distribution geliefert werden? Bei einigen Recherchen konnte ich nur feststellen, dass die GitLab Community Edition das Hinzufügen von Jenkins nicht zulässt, die GitLab Enterprise Edition jedoch. Gibt es noch andere signifikante Unterschiede?

Ravikiran Butti
quelle
5
GitLab hat jetzt auch einen Vergleich von GitLab CI mit Jenkins zusammengestellt: about.gitlab.com/comparison/gitlab-vs-jenkins.html
bbodenmiller
2
Neuer Link ist: about.gitlab.com/comparison/pdfs/gitlab-vs-jenkins.pdf
Guillaume Husta

Antworten:

122

Das ist meine Erfahrung:

Bei meiner Arbeit verwalten wir unsere Repositorys mit GitLab EE und es läuft ein Jenkins-Server (1.6).

In der Basis machen sie so ziemlich das Gleiche. Sie führen einige Skripte auf einem Server / Docker-Image aus.

TL; DR;

  • Jenkins ist einfacher zu bedienen / zu lernen, aber es besteht das Risiko, dass es zur Hölle der Plugins wird
  • Jenkins hat eine GUI (dies kann bevorzugt werden, wenn es für andere Personen zugänglich / wartbar sein muss)
  • Die Integration mit GitLab ist geringer als mit GitLab CI
  • Jenkins können von Ihrem Repository getrennt werden

Die meisten CI-Server sind ziemlich einfach ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd und was haben Sie sonst noch ? Mit ihnen können Sie Shell / Bat-Skripte aus einer YAML-Dateidefinition ausführen. Jenkins ist viel steckbarer und verfügt über eine Benutzeroberfläche. Dies kann je nach Ihren Anforderungen entweder ein Vorteil oder ein Nachteil sein.

Jenkins ist aufgrund aller verfügbaren Plugins sehr konfigurierbar. Der Nachteil dabei ist, dass Ihr CI-Server zu einer Spaghetti von Plugins werden kann.

Meiner Meinung nach ist das Verketten und Orchestrieren von Jobs in Jenkins (aufgrund der Benutzeroberfläche) viel einfacher als über YAML (Aufrufen von Curl-Befehlen). Außerdem unterstützt Jenkins Plugins, die bestimmte Binärdateien installieren, wenn sie auf Ihrem Server nicht verfügbar sind (für die anderen wissen Sie nichts darüber).

Heutzutage ( Jenkins 2 unterstützt auch mehr "korrektes ci" mit dem Jenkinsfileund dem Pipline- Plugin, das standardmäßig ab Jenkins 2 verfügbar ist ), war jedoch früher weniger an das Repository gekoppelt als GitLab CI.

Die Verwendung von YAML-Dateien zum Definieren Ihrer Build-Pipeline (und letztendlich das Ausführen von Pure Shell / Bat) ist sauberer.

Mit den für Jenkins verfügbaren Plug-Ins können Sie alle Arten von Berichten wie Testergebnisse, Abdeckung und andere statische Analysegeräte visualisieren. Natürlich können Sie jederzeit ein Tool schreiben oder verwenden, um dies für Sie zu tun, aber es ist definitiv ein Plus für Jenkins (insbesondere für Manager, die diese Berichte zu sehr schätzen).

In letzter Zeit habe ich immer mehr mit GitLab CI gearbeitet. Bei GitLab machen sie einen wirklich tollen Job und machen die ganze Erfahrung Spaß. Ich verstehe, dass Leute Jenkins verwenden, aber wenn GitLab ausgeführt wird und verfügbar ist, ist es wirklich einfach, mit GitLab CI zu beginnen. Es wird nichts geben, das sich so nahtlos integrieren lässt wie GitLab CI, obwohl die Integration von Drittanbietern einige Anstrengungen erfordert.

  • Ihre Dokumentation sollte Ihnen in kürzester Zeit den Einstieg erleichtern.
  • Die Schwelle für den Einstieg ist sehr niedrig.
  • Die Wartung ist einfach (keine Plugins).
  • Das Skalieren von Läufern ist einfach.
  • CI ist vollständig Teil Ihres Repositorys.
  • Jenkins Jobs / Ansichten können chaotisch werden.

Einige Vorteile zum Zeitpunkt des Schreibens:

  • Unterstützung nur für eine einzelne Datei in der Community Edition. Mehrere Dateien in der Enterprise Edition .
Rik
quelle
13
Jenkins kann jetzt eine schönere GUI dank Blue Ocean
Ayoub Kaanich
3
Ab Gitlab 9.3 wird die Unterstützung von Multiprojekt-Pipelines hinzugefügt. Dies war für mich einer der Hauptgründe, bei Jenkins zu bleiben. Derzeit mache ich einen PoC, um zu überprüfen, ob ich mit Gitlab zurechtkomme, da sie sich jetzt eindeutig auch darauf konzentrieren und sich viel schneller entwickeln. Außerdem liebe ich die Benutzeroberfläche und wie sie sich im Laufe der Zeit entwickelt hat.
Rik
4
Das Beste an den yaml-Dateien ist, dass Sie Ihre Änderungen an der Pipeline direkt dort dokumentieren, wo sie sein sollten. Im Repository als Teil des Quellcodes. Sie können also Zweige mit unterschiedlichen Yaml-Dateien für verschiedene Release-Zweige haben. Sicher, Yaml-Zusammenführung könnte ein Chaos sein :) Wenn man sich vorstellt, zwei Piplelines in Jenkins zusammenzuführen, ist das eine viel schwierigere Aufgabe.
Christian Müller
Jenkins bieten viel mehr Werkzeuge als Gitlab CI. gitlab / jenkins Zusammen ist die Integration möglich und für den Benutzer wirklich transparent, wenn sie gut eingerichtet ist. Mit Jenkinsfile in Ihrem Repository ist es einfach, zwei Piplelines in jenkins zusammenzuführen. Sie benötigen gitlab- und gitlab-Quellzweig-Plugins
sancelot
1
Was bedeutet "Nur Unterstützung für eine einzelne Datei in der Community Edition. Mehrfache Dateien in der Enterprise Edition". ? Entschuldigung, ich habe versucht, die beigefügte Ausgabe zu lesen, konnte mich aber nicht darauf beziehen.
Lester
62

Ich stimme den meisten Notizen von Rik zu, aber meine Meinung, welche einfacher ist, ist das Gegenteil : GitLab erweist sich als ein großartiges Werkzeug, mit dem man arbeiten kann.

Der größte Teil der Leistung besteht darin, in sich geschlossen zu sein und alles in dasselbe Produkt auf derselben Browser-Registerkarte zu integrieren: vom Repository-Browser über das Issue Board oder den Build-Verlauf bis hin zu Bereitstellungstools und Überwachung .

Ich verwende es gerade, um zu automatisieren und zu testen, wie eine Anwendung auf verschiedenen Linux-Distributionen installiert wird, und die Konfiguration ist blitzschnell (versuchen Sie, eine komplexe Jenkins-Jobkonfiguration in Firefox zu öffnen, und warten Sie, bis das nicht reagierende Skript angezeigt wird . wie leicht zu bearbeiten ist .gitlab-ci.yml).

Der Zeitaufwand für die Konfiguration / Skalierung von Slaves ist dank der Runner-Binärdateien erheblich geringer . plus die Tatsache, dass Sie in GitLab.com ziemlich anständige und kostenlose gemeinsame Läufer erhalten.

Jenkins fühlt sich nach einigen Wochen als Power-User von GitLab CI manueller , z. B. beim Duplizieren von Jobs pro Zweig, Installieren von Plugins für einfache Aufgaben wie das Hochladen von SCP. Der einzige Anwendungsfall, mit dem ich konfrontiert bin, wo ich ihn heute vermisse, ist, wenn mehr als ein Repository beteiligt ist. das muss noch gut herausgefunden werden.

Übrigens schreibe ich gerade eine Reihe über GitLab CI, um zu demonstrieren, wie schwierig es ist, Ihre Repository-CI-Infrastruktur damit zu konfigurieren. Das erste Stück, das letzte Woche veröffentlicht wurde, stellt die Grundlagen, Vor- und Nachteile sowie Unterschiede zu anderen Tools vor: Schnelle und natürliche kontinuierliche Integration mit GitLab CI

Alfageme
quelle
5
Ich stimme dir in Bezug auf Gitlab voll und ganz zu. Zum Zeitpunkt des Schreibens war gitlab nicht so vollständig wie heute. Ich mag Gitlab als Werkzeug sehr und schätze die ganze Arbeit, die die Jungs in es stecken, sehr.
Rik
1
@alfageme: Ich werde Ihre Berichte auf der genannten Seite überprüfen. Wie auch immer: Vielen Dank an alle Ihre Erklärungen. In diesem Moment werde ich entscheiden, ob wir gitlabCI oder Jenkins für unser CI-Zeug verwenden.
Max Schindler
3
@Rik Ich mag Gitlab CI, aber ich höre Argumente von der anderen Seite, dass es schwierig ist, Yaml-Dateien zu verwalten, da es keine Wiederverwendbarkeit gibt, da viele der Yaml-Dateien in einer Pipeline der gleichen Struktur folgen und Templating nicht als überlegene Option angesehen wird jenkinsfile weil jenkinsfile groovy verwendet. Es geht also nur um Code und Konfiguration für die Wiederverwendbarkeit. Kannst du bitte deine Gedanken dazu teilen?
user1870400
1
@ user1870400 Ich bin mir nicht ganz sicher, was du mit Templating meinst. Denn soweit ich es sehen kann, ist es nur eine Datei in Ihrem Repository. Und das ist nicht anders als bei Ihnen Jenkinsfile. Sie haben Recht, dass JenkinsfileSie Groovy (+ zusätzliche Java-Bibliotheken) zum Ausführen von Code zur Verfügung haben, wobei die .gitlab-ci.yamlDatei hauptsächlich Shell unterstützt, jedoch (abhängig vom Standort des Läufers). Auf der anderen Seite können Sie all dies auch über ein Shell-Skript aufrufen, aber der Nachteil ist, dass Sie Maschinenabhängigkeiten erstellen (die meiner Meinung nach nicht sehr transparent sind).
Rik
1
@Alfageme - Ich habe auch angefangen, Gitlab CI zu verwenden und mich von Jenkins zu entfernen. Ich verwende es im Moment zum automatischen Erstellen, Hochladen auf Nexus, Bereitstellen in DEV env und Ausführen von Komponententests. Eine solche Sequenz wird auf Projektebene (Standard) ausgeführt. Nach DEV muss ich auch die Bereitstellung mehrerer Projekte (Gitlab-Gruppe) verwalten. Ich habe eine GUI erstellt, die Gitlab, Nexus-APIs usw. verwendet, in der Sie die neueste TAG des zu implementierenden Projekts auswählen und die neuesten Tags für Gruppenprojekte ebenfalls bereitstellen (naiv). Ich arbeite an einer Erweiterung zur Unterstützung der Versionsmatrixdefinition (projec1v1.1 ist kompatibel mit project2v3.2). Ich werde hierfür eine Funktionsanforderung bei gitlab stellen.
Kensai
22

Erstens kann die GitLab Community Edition ab heute vollständig mit Jenkins kompatibel sein. Keine Frage.

Im Folgenden gebe ich ein Feedback zu einer erfolgreichen Erfahrung, bei der Jenkins und GitLab CI kombiniert wurden. Ich werde auch diskutieren, ob und aus welchem ​​Grund Sie beide oder nur einen von ihnen verwenden sollten.

Ich hoffe, dies gibt Ihnen qualitativ hochwertige Informationen zu Ihren eigenen Projekten.

Stärken von GitLab CI und Jenkins

GitLab CI

GitLab CI ist natürlich in GitLab SCM integriert. Sie können Pipelines mithilfe von gitlab-ci.ymlDateien erstellen und über eine grafische Oberfläche bearbeiten.

Diese Pipelines als Code können offensichtlich in der Codebasis gespeichert werden, wodurch die Praxis "Alles als Code" (Zugriff, Versionierung, Reproduzierbarkeit, Wiederverwendbarkeit usw.) durchgesetzt wird.

GitLab CI ist ein großartiges visuelles Management-Tool:

  • Alle Mitglieder des Teams (einschließlich der nicht technischen) haben schnellen und einfachen Zugriff auf den Status des Anwendungslebenszyklus.
  • Daher kann es als interaktives und operatives Dashboard für das Release-Management verwendet werden.

Jenkins

Jenkins ist ein großartiges Build-Tool. Die Stärke liegt in den vielen Plugins. Insbesondere hatte ich großes Glück bei der Verwendung von Schnittstellen-Plugins zwischen Jenkins und anderen CI- oder CD-Tools. Dies ist immer eine bessere Option, als eine Dialogschnittstelle zwischen zwei Komponenten (möglicherweise schlecht) neu zu entwickeln.

Pipeline als Code ist auch mithilfe von groovySkripten verfügbar .

GitLab CI und Jenkins zusammen verwenden

Es mag zunächst etwas überflüssig klingen, aber die Kombination von GitLab CI und Jenkins ist ziemlich leistungsfähig.

  • GitLab CI orchestriert (Ketten, Läufe, Monitore ...) Pipelines und kann von seiner in GitLab integrierten grafischen Oberfläche profitieren
  • Jenkins führt den Job aus und erleichtert den Dialog mit Tools von Drittanbietern.

Ein weiterer Vorteil dieser Konstruktion besteht in einer losen Kopplung zwischen den Werkzeugen:

  • Wir könnten alle Komponenten der Build Factory ersetzen, ohne den gesamten CI / CD-Prozess überarbeiten zu müssen
  • Wir könnten eine heterogene Build-Umgebung haben, die (möglicherweise mehrere) Jenkins, TeamCity, wie Sie es nennen, kombiniert und dennoch ein einziges Überwachungstool hat.

Der Kompromiss

Natürlich muss für dieses Design ein Preis bezahlt werden: Die anfängliche Einrichtung ist umständlich und Sie müssen nur ein minimales Verständnis für viele Werkzeuge haben.

Aus diesem Grund empfehle ich eine solche Einrichtung nur, wenn Sie dies tun

  • Sie müssen mit vielen Tools von Drittanbietern umgehen. Dann ist Jenkins mit seinen vielen Plugins sehr praktisch.
  • Sie müssen sich mit komplexen Anwendungen mit heterogenen Technologien befassen, die jeweils eine andere Build-Umgebung haben, und dennoch über eine einheitliche Benutzeroberfläche für die Verwaltung des Anwendungslebenszyklus verfügen.

Wenn Sie sich in keiner dieser Situationen befinden, sind Sie wahrscheinlich mit nur einer der beiden besser dran, aber nicht mit beiden.

Wenn ich einen auswählen müsste

Sowohl GitLab CI als auch Jenkins haben Vor- und Nachteile. Beide sind mächtige Werkzeuge. Also welches soll man wählen?

Antwort 1

Wählen Sie die aus, in der Ihr Team (oder eine nahe stehende Person) bereits über ein bestimmtes Fachwissen verfügt.

Antwort 2

Wenn Sie alle ein absoluter Neuling in CI-Technologien sind, wählen Sie einfach eine aus und legen Sie los.

  • Wenn Sie GitLab verwenden und ein Händchen für alles als Code haben, ist es absolut sinnvoll, GitLab CI zu wählen.
  • Wenn Sie mit vielen anderen CI / CD-Tools in Dialog treten müssen oder diese GUI unbedingt benötigen, um Ihre Jobs zu erstellen, entscheiden Sie sich für Jenkins.

Diejenigen unter Ihnen, die GitLab verwenden und nicht sicher sind, ob sie dies weiterhin tun werden, müssen dennoch bedenken, dass die Auswahl von GitLab CI bedeuten würde, alle Ihre CI / CD-Pipelines in den Papierkorb zu werfen.

Das letzte Wort ist: Das Gleichgewicht neigt sich aufgrund seiner vielen Plugins ein wenig zu Jenkins, aber es besteht die Möglichkeit, dass GitLab CI die Lücke schnell schließt.

avi.elkharrat
quelle
@ Peter Mortensen: THX!
avi.elkharrat
6

Ich möchte einige Erkenntnisse aus meinen jüngsten Experimenten mit GitLab CI hinzufügen. Die Funktionen von 11.6 und 11.7 sind einfach fantastisch!

Insbesondere liebe ich onlyBedingungen, die es Ihnen grundsätzlich ermöglichen, separate Pipelines für merge_requestoder zu bauen push(die vollständige Liste finden Sie hier ).

Außerdem gefällt mir das Fehlen von Plugins sehr gut. Wenn ich komplexere Funktionen benötige, schreibe ich einfach ein benutzerdefiniertes Docker-Image, das die erforderlichen Funktionen verarbeitet (es ist das gleiche Konzept wie in drone.io ).

Wenn Sie sich über DRY wundern , ist dies heutzutage absolut möglich! Sie können Ihre "Vorlagen" schreiben

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

Legen Sie sie in einem öffentlichen Repository ab und fügen Sie sie in die Hauptpipeline ein:

include:
  - remote: https://....

Und nutzen Sie sie, um einen Job zu verlängern:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

Ich liebe GitLab CI so sehr! Ja, es kann (bis jetzt) ​​keine schönen Grafiken mit Abdeckung usw. zeichnen, aber insgesamt ist es ein wirklich nettes Werkzeug!

Bearbeiten (23.02.2019): Hier ist mein Beitrag über Dinge, die ich in GitLab CI liebe. Es wurde in 11.7 "Ära" geschrieben. Wenn Sie diese Antwort lesen, hat GitLab CI wahrscheinlich viele weitere Funktionen.

Bearbeiten (2019-07-10): Gitlab CI unterstützt jetzt mehrere extendsz

extends:
 - .pieceA
 - .pieceB

Weitere Informationen zu mehreren Erweiterungen finden Sie in der offiziellen Dokumentation

Stepan Vrany
quelle
0

Wenn Ihre Build- / Publish- / Deployment- und Testjobs nicht sehr komplex sind, hat die Verwendung von gitlab ci natürliche Vorteile.

Da gitlab-ci.yml in jedem Zweig neben Ihrem Code vorhanden ist, können Sie Ihre ci / cd-Schritte, insbesondere Tests (die sich je nach Umgebung unterscheiden), effektiver ändern.

Zum Beispiel möchten Sie Unit-Tests für jeden Check-in-Dev-Zweig durchführen, während Sie möglicherweise vollwertige Funktionstests für den QS-Zweig durchführen möchten und eine begrenzte Anzahl von Tests nur für die Produktion erhalten möchten. Dies kann mit gitlab ci problemlos erreicht werden.

Der zweite Vorteil neben der großartigen Benutzeroberfläche ist die Möglichkeit, Docker-Images zum Ausführen einer beliebigen Phase zu verwenden, wodurch der Host-Runner intakt bleibt und somit weniger fehleranfällig ist.

Darüber hinaus würde gitlab ci automatisch für Sie einchecken und Sie müssen Jenkins Master nicht separat verwalten

Rajanikant Patel
quelle