GitLab CI vs. Jenkins [geschlossen]

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?

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 .

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

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.

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

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