it-swarm.com.de

GitLab CI gegen Jenkins

Was ist der Unterschied zwischen Jenkins und anderen CIs wie GitLab CI, drone.io, das mit der Git-Distribution geliefert wird? Bei einigen Nachforschungen 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?

108
Ravikiran763

Das ist meine Erfahrung:

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

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

TL; DR;

  • Jenkins ist einfacher zu benutzen/zu lernen, aber es birgt das Risiko, zur Hölle der Plugins zu werden
  • Jenkins hat eine GUI (dies kann bevorzugt werden, wenn es für andere 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 unkompliziert ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd und was hast du 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 Bedarf ein Vorteil oder ein Nachteil sein.

Jenkins ist aufgrund aller verfügbaren Plugins sehr konfigurierbar. Der Nachteil davon 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 diese nicht auf Ihrem Server verfügbar sind (davon wissen die anderen nichts).

Heutzutage ( Jenkins 2 unterstützt auch mehr "richtiges ci" mit dem Jenkinsfile und dem Pipline Plugin, das standardmäßig ab Jenkins 2 verfügbar ist), aber früher verwendet wurde weniger an das Repository gekoppelt als zB GitLab CI.

Die Verwendung von YAML-Dateien zur Definition Ihrer Build-Pipeline (und letztendlich die Ausführung von pure Shell/bat) ist sauberer.

Mit den für Jenkins verfügbaren Plug-Ins können Sie alle Arten von Berichten visualisieren, z. B. Testergebnisse, Abdeckung und andere statische Analysegeräte. 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 arbeite ich immer mehr mit GitLab CI. Bei GitLab machen sie einen wirklich tollen Job, damit die ganze Erfahrung Spaß macht. Ich verstehe, dass Leute Jenkins verwenden, aber wenn GitLab läuft und verfügbar ist, ist es wirklich einfach, mit GitLab CI zu beginnen. Es wird nichts geben, was sich so nahtlos integrieren lässt wie GitLab CI, auch wenn es einige Anstrengungen bei der Integration von Drittanbietern gibt.

  • 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).
  • Die Skalierung von Läufern ist einfach.
  • CI vollständig Teil Ihres Repository.
  • Jenkins Jobs/Views können chaotisch werden.

Einige Vorteile zum Zeitpunkt des Schreibens:

  • Nur Unterstützung für eine einzelne Datei in der Community Edition. Mehrere Dateien in der Enterprise Edition .
109
Rik

Ich stimme den meisten Anmerkungen von Rik zu, aber meiner Meinung nach ist das Gegenteil der Fall : GitLab erweist sich als großartiges Werkzeug für die Arbeit.

Der größte Teil der Leistung kommt von in sich geschlossenen und alles integrieren in demselben Produkt unter demselben Browser-Tab: aus dem Repository Browser, Issue Board oder Build-Verlauf für Bereitstellungstools und Überwachung .

Ich benutze es gerade, um zu automatisieren und zu testen, wie eine Anwendung auf verschiedenen Linux-Distributionen installiert wird, und es ist blitzschnell zu konfigurieren (versuchen Sie, eine zu öffnen komplexe Jenkins-Auftragskonfiguration in Firefox und warten Sie, bis das nicht reagierende Skript angezeigt wird, verglichen mit dem geringen Bearbeitungsaufwand für .gitlab-ci.yml).

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

Jenkins fühlt sich nach einigen Wochen als Power-User von GitLab CI mehr manuell , z. Duplizieren von Jobs pro Zweig, Installieren von Plugins für einfache Aufgaben wie das Hochladen von SCPs. Der einzige Anwendungsfall, mit dem ich konfrontiert bin, bei dem ich es vermisse, ist, wenn mehr als ein Repository beteiligt ist. das muss noch schön herausgefunden werden.

Übrigens schreibe ich gerade eine Serie über GitLab CI, um zu demonstrieren, wie einfach 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 und Unterschiede zu anderen Tools vor: Schnelle und natürliche kontinuierliche Integration mit GitLab CI

56
Alfageme

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

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

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

GitLab CI und Jenkins Stärken

GitLab CI

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

Diese Pipelines als Code können offensichtlich in der Codebasis gespeichert werden, wodurch die "Alles als Code" -Praxis (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 Lebenszyklusstatus der Anwendungen.
  • daher kann es als interaktives und betriebsbereites 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 (möglicherweise fehlerhafte) Dialogschnittstelle zwischen zwei Komponenten neu zu entwickeln.

Pipeline als Code ist auch mit groovyscripts verfügbar.

Mit GitLab CI und Jenkins zusammen

Anfangs mag es ein bisschen redundant klingen, aber die Kombination von GitLab CI und Jenkins ist ziemlich leistungsfähig.

  • GitLab CI orchestriert (Ketten, Läufe, Monitore ...) Pipelines und man kann von der 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 ist die lose Kopplung zwischen den Werkzeugen:

  • wir können alle Komponenten der Build Factory ersetzen, ohne den gesamten CI/CD-Prozess überarbeiten zu müssen
  • wir könnten eine heterogene Build-Umgebung haben, in der (möglicherweise mehrere) Jenkins, TeamCity, wie Sie es nennen, kombiniert werden und immer noch ein einziges Überwachungstool vorhanden ist.

Der Kompromiss

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

Aus diesem Grund empfehle ich eine solche Einrichtung nur dann

  • sie müssen mit vielen Tools von Drittanbietern umgehen. Dann ist Jenkins mit seinen vielen Plugins super praktisch.
  • sie müssen sich mit komplexen Anwendungen mit heterogenen Technologien auseinandersetzen, die jeweils eine andere Build-Umgebung aufweisen, und müssen dennoch über eine einheitliche Benutzeroberfläche für das Anwendungslebenszyklusmanagement 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 mir einen aussuchen müsste

Sowohl GitLab CI als auch Jenkins haben Vor- und Nachteile. Beides 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 Neuling in CI-Technologien sind, wählen Sie einfach eine aus und legen Sie los.

  • Wenn Sie GitLab verwenden und alles als Code beherrschen, 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 sich nicht sicher sind, ob sie dies auch weiterhin tun werden, müssen sich darüber im Klaren sein, dass die Auswahl von GitLab CI bedeuten würde, alle Ihre CI/CD-Pipelines zu verwerfen.

Das letzte Wort ist: Die Balance neigt aufgrund der vielen Plugins ein kleines Stück in Richtung Jenkins, aber die Chancen stehen gut, dass GitLab CI die Lücke schnell füllen wird.

13
avi.elkharrat

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 mag ich only Bedingungen, mit denen Sie grundsätzlich separate Pipelines für merge_request Oder Push erstellen können (die vollständige Liste ist hier )

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

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

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

Stellen Sie sie in ein öffentliches Repository und fügen Sie sie in die Hauptpipeline ein:

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

Und benutze 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 netten Graphen mit Deckung usw. zeichnen, aber insgesamt ist es wirklich ordentlich Werkzeug!

Edit (2019-02-23): hier ist mein Beitrag über Dinge, die ich in GitLab CI liebe. Es wurde in der Ära 11.7 geschrieben. Wenn Sie also diese Antwort lesen, hat GitLab CI wahrscheinlich viel mehr Funktionen.

Edit (2019-07-10): Gitlab CI unterstützt jetzt mehrere extends, z.

extends:
 - .pieceA
 - .pieceB

In der offiziellen Dokumentation finden Sie weitere Informationen zu mehrfach erweitert

6
Stepan Vrany