Frage Gitlab CI gegen Jenkins


Kann mir jemand bitte sagen, was ist der Unterschied zwischen Jenkins und anderen CI wie Gitlab-CI, drone.io kommt mit GIT-Verteilung. Bei einigen Recherchen konnte ich nur feststellen, dass die Gitlab-Community-Edition es nicht erlaubt, Jenkins hinzuzufügen, sondern die Gitlab Enterprise-Edition. Gibt es noch andere signifikante Unterschiede?


76
2018-05-25 06:34


Ursprung


Antworten:


Das ist meine Erfahrung:

Bei meiner Arbeit verwalten wir unsere Repositories mit gitlab ee und wir betreiben einen Jenkins Server (1.6).

In der Basis machen sie ziemlich genau dasselbe. Sie werden einige Scripts auf einem Server / Docker-Image ausführen.

TL; DR; 

  • Jenkins ist einfacher zu verwenden / zu lernen, hat aber das Risiko, ein Plugin-Hölle zu werden
  • Jenkins hat eine GUI (dies kann bevorzugt werden, wenn es von anderen Personen zugänglich / wartbar sein muss)
  • Die Integration mit GitLab ist geringer als mit Gitlab-ci
  • Jenkins kann von deinem Repo getrennt werden

Die meisten CI-Server sind ziemlich einfach (concourse.ci, gitlab-ci, Kreis-ci, Travis-Ci, drone.io, Gocd und was hast du sonst noch). Sie erlauben es, Shell / Bat aus einer Yaml-Dateidefinition auszuführen. Jenkins ist viel mehr Pluggable und kommt mit einer Benutzeroberfläche. Je nach Bedarf kann dies ein Vor- oder Nachteil sein.

Jenkins ist sehr konfigurierbar, da alle Plugins verfügbar sind. Der Nachteil davon ist, dass Ihr CI-Server eine Spaghetti von Plugins werden kann.

Meiner Meinung nach ist das Verketten und Koordinieren von Jobs in Jenkins viel einfacher (wegen der UI) als über Yaml (Aufruf von curl-Befehlen). Außerdem unterstützt Jenkins Plugins, die bestimmte Binärdateien installieren, wenn sie nicht auf Ihrem Server verfügbar sind (wissen Sie nichts davon für die anderen).

Heutzutage (jenkins2 unterstützt auch mehr "richtige ci" mit der Jenkinsfile und das Pipline Plugin, das Standard wie aus Jenkins 2) kommt, aber früher weniger mit dem Repository gekoppelt als gitlab ci.

Die Verwendung von Yaml-Dateien zum Definieren Ihrer Build-Pipeline (und am Ende der Ausführung von pure shell / bat) ist sauberer.

BEARBEITEN: Was ich hier vergessen habe, sind die Plugins für Jenkins, mit denen Sie alle Arten von Berichten wie Testergebnisse, Abdeckung und andere statische Analysatoren visualisieren können. Natürlich können Sie immer ein Werkzeug schreiben oder verwenden, um dies für Sie zu tun, aber es ist definitiv ein Vorteil für Jenkins (besonders für Manager, die diese Berichte zu sehr schätzen)

EDIT2: In letzter Zeit arbeite ich mehr und mehr mit Gitlab-ci zusammen. Bei Gitlab machen sie eine wirklich gute Arbeit, die die ganze Erfahrung Spaß macht. Ich verstehe, dass Leute Jenkins benutzen, aber wenn Sie Gitlab laufen und verfügbar haben, ist es wirklich leicht mit Gitlab-ci anzufangen. Es wird nichts geben, was sich so nahtlos integrieren lässt wie Gitlab-ci, auch wenn sie einiges an Integration von Drittanbietern betreiben.

  • Ihre Dokumentation sollte Sie in kürzester Zeit beginnen
  • Der Einstiegsschwellenwert ist sehr niedrig
  • Wartung ist einfach (keine Plugins)
  • Skalierung von Läufern ist einfach
  • CI ist ein Teil Ihres Repositories
  • Jenkins Jobs / Ansichten können unordentlich werden

Einige Vergünstigungen zum Zeitpunkt des Schreibens

  • Nur Unterstützung für eine einzelne Datei, aber das wird sein Fest bald

80
2018-05-25 07:08



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

Die meiste Kraft kommt vom Sein in sich geschlossen und alles integrieren im selben Produkt unter der gleichen Browser-Registerkarte: vom Repository-Browser, Ausgabe-Board oder Build-Verlauf zu Bereitstellungstools und Überwachung.

Ich benutze es jetzt, um zu automatisieren und zu testen, wie eine Anwendung auf verschiedenen Linux-Distributionen installiert wird und es ist einfach blitzschnell zu konfigurieren (Versuchen Sie, eine komplexe Jenkins-Jobkonfiguration in Firefox zu öffnen, und warten Sie, bis das nicht reagierende Skript auftaucht und nicht mehr wie leicht zu bearbeiten ist .gitlab-ci.yml). Der Zeitaufwand für die Konfiguration / Scaling von Slaves ist dank der Läufer Binärdateien; plus die Tatsache, dass GitLab.com Du bekommst ganz anständige und kostenlose Mitläufer.

Jenkins fühlt mehr manuell nach einigen Wochen, in denen er ein Power-User von GitLab CI ist, z.B. Duplizieren von Jobs pro Zweig, Installieren von Plugins für einfache Aufgaben wie SCP-Upload. Der einzige Anwendungsfall, in dem ich es vermisse, wenn ich es heute vermisse, ist, wenn mehr als ein Repository involviert ist; das muss noch gut durchdacht sein.

Übrigens, ich schreibe gerade eine Serie über GitLab CI, um zu demonstrieren, wie einfach es ist, die Repository-CI-Infrastruktur damit zu konfigurieren. Veröffentlicht letzte Woche das erste Stück mit den Grundlagen, Vor- und Nachteilen und Unterschieden zu anderen Tools: https://solidgeargroup.com/gitlab_countinuous_integration_intro


34
2018-03-08 13:02