Warum GitLab gut ist
(whileforloop.com)- Vorstellung von Erfahrungen aus der langjährigen Nutzung von GitLab mit Fokus auf die Verwaltung persönlicher Projekte und die CI/CD-Integration
- Anfangs war die Bereitstellung kostenloser privater Repositories gegenüber GitHub der wichtigste Vorteil; danach hat sich der Workflow vollständig etabliert
- Die Funktion Container Registry wird am häufigsten genutzt; Images lassen sich speichern, ohne ein separates Docker-Hub-Konto oder Token verwalten zu müssen
- Als wichtigste Stärken werden die dateibasierte Pipeline von GitLab CI, kostenlose Shared Runner und die umfangreiche Dokumentation genannt
- Als Nachteile werden jedoch die langsame Weboberfläche und der Funktionsüberfluss genannt; am effizientesten ist es, GitHub und GitLab je nach Zweck parallel zu nutzen
Hintergrund zur GitLab-Nutzung
- Mit der Nutzung von GitLab wurde zu einer Zeit begonnen, als GitHub für private Repositories Gebühren verlangte und GitLab kostenlose private Repositories anbot
- Mehrere experimentelle Projekte konnten verwaltet werden, ohne sie öffentlich zu machen
- Später führte GitHub zwar ein kostenloses Modell ein, doch CI-Pipelines, Docker-Images und Deployment-Skripte waren bereits auf GitLab ausgerichtet aufgebaut, sodass kein Bedarf mehr an einem Wechsel bestand
Docker-Registry-Funktion
- Zu jedem GitLab-Projekt gehört standardmäßig eine Container Registry
- Ein einfacher Ablauf: Images lokal oder in CI bauen, pushen und bei Bedarf andernorts pullen und verwenden
- Kein separates Docker-Hub-Konto oder Token-Management nötig, keine Sorge wegen Pull-Limits
- Für persönliche Projekte ist der Funktionsumfang völlig ausreichend, und auch das 10-GB-Limit ist in der Praxis kein Problem
- Durch das Bereinigen alter Tags und die gemeinsame Nutzung von Layern bleibt die Speichernutzung effizient
CI/CD-Umgebung
- GitLab CI hat das Konzept „dateibasierte CI“ schon früh umgesetzt
- Sobald nur die Datei
.gitlab-ci.ymlhinzugefügt wird, läuft die Pipeline automatisch an - Die Konfiguration steht unter Versionskontrolle, sodass sich frühere Pipeline-Zustände nachvollziehen lassen
- Sobald nur die Datei
- Die Standard-Pipeline besteht aus Image-Build, Push und optionalem Deployment
- Der Deployment-Schritt kann über einen manuellen Trigger gesteuert werden
- Shared Runner sind kostenlos, aber langsam; bei Bedarf lässt sich ein eigener Runner unkompliziert auf einem VPS installieren
- Die CI/CD-Dokumentation ist sehr umfangreich; sobald man die Muster einmal verinnerlicht hat, lässt sich durch Kopieren und Wiederverwenden bestehender Konfigurationen effizient arbeiten
Unbequeme Punkte
- Die Geschwindigkeit der Weboberfläche ist langsam; beim Wechsel zwischen Merge Requests, Pipelines und Logs entstehen Wartezeiten
- In letzter Zeit scheint es etwas besser geworden zu sein, ist aber immer noch langsamer als GitHub
- Es gibt ein Problem mit Funktionsüberfluss
- Es gibt viele Funktionen wie Issue-Tracking, Wiki, Package Registry und Security Scanning, tatsächlich genutzt werden davon aber nur rund 10 %
- Wenn man sie braucht, besteht allerdings auch der potenzielle Vorteil, dass diese Funktionen bereits integriert sind
Kosten und Workflow
- Rund 12 persönliche Projekte werden kostenlos betrieben, von aktiven Projekten bis hin zu eingestellten Experimenten
- GitLab wird als privater Arbeitsbereich, GitHub als Bereich zum Teilen öffentlicher Projekte genutzt
- GitHub eignet sich jeweils für Zusammenarbeit und Sichtbarkeit, GitLab für Experimente und das Management von Automatisierung
- Die parallele Nutzung beider Plattformen funktioniert als Ansatz, um Balance und Effizienz im Workflow aufrechtzuerhalten
3 Kommentare
GitLab wird ja nachgesagt, dass sein CI/CD gut ist.
Aber wegen der Einschränkungen beim kostenlosen Konto greife ich, selbst wenn Koreanisch unterstützt würde, am Ende doch eher zu GitHub.
Forgejo und seine Basis Gitea fühlen sich für mich wie GitHub-Klone an, deshalb greife ich auch nicht dazu.
Wir verwenden Gitea; wegen des ähnlichen Images war die Lernkurve gering, daher haben wir es eingeführt.
Zu GitLab gab es viel Feedback, dass es wegen der zu vielen Funktionen schwierig und schwergewichtig ist..
Hacker-News-Kommentare
Ansprechpartner im Kundensupport sind verschwunden, alle Anfragen müssen über das Vertriebsteam laufen, und die meisten Funktionen sind an den teuren Ultimate-Tarif gebunden
Funktionen, die nichts mit „AI“ zu tun haben, leiden seit Jahren unter denselben Problemen und werden trotzdem vernachlässigt
Deshalb spiele ich inzwischen bei jeder Vertriebs-Mail das Spiel: „Wann werden wir wohl wieder das Entwicklungstempo von früher sehen?“
Um 2015 bis 2020 herum habe ich es gern benutzt, aber alle Funktionen wirkten unfertig, und der Fokus lag eher darauf, Feature-Checklisten abzuhaken als auf einem ausgereiften Produkt
Für ein kleines Team, das mit Großkonzernen konkurrieren will, war das vielleicht unvermeidlich
Auch nach 10 Jahren ist das noch so, während Gitea oder Forgejo deutlich schneller sind und mit Go 1.26 wohl noch besser werden
Vor allem die Suche in Issues ist so langsam, dass ich es nie wieder nutzen will
Ich bin 2018 von Bitbucket und Confluence zu GitLab Cloud gewechselt, und die Produkte von Atlassian waren deutlich langsamer und komplexer
GitLab fühlte sich leichtgewichtig und schnell an, und auch heute funktioniert das meiste gut
Als ich kürzlich Jira Cloud benutzt habe, war das viel langsamer und unbequemer
Das ist wirklich bemerkenswert
Der Stromverbrauch des Servers ist um 10 % gesunken, und bei GitLab haben zu viele unnötige Funktionen die UI träge gemacht
Forgejo ist schlicht und erlaubt es, Funktionen pro Projekt auszublenden
Allerdings gibt es keine automatischen Updates, der Reifegrad ist geringer, und manche Funktionen arbeiten nicht richtig
Ich weiß nicht, ob es ein Jekyll-Theme war oder selbst gebaut, aber schon das Navigieren hat Spaß gemacht
Das Nötige wie CI und Issue-Tracking bleibt erhalten, aber die Oberfläche lädt sofort, und überflüssige Funktionen gibt es nicht
Die GitLab-CI-Syntax gefiel mir besser, aber die API von Forgejo ist weniger ausgereift
Trotzdem kann man das durch direkten Zugriff auf die DB mit eigenen Skripten lösen
Man startet einen Kubernetes-Cluster und verbindet Forgejo mit Argo, um Tests durchzuführen
Ich bin mir nicht sicher, ob es richtig ist, statt Microsoft die Ressourcen von Codeberg zu nutzen
CI scheint von einem Projekt namens Woodpecker übernommen zu werden; mich würde der Vergleich mit GitLab CI interessieren
GitLab unterstützt zwar nicht so gut wie Gerrit, aber immerhin gestapelte MRs, und Kommentare bleiben auch nach einem Force-Push sichtbar
Ich denke, die GitHub-artige Kultur rund um große PRs schadet Produktivität und Review-Kultur
Bei Verwaltungsfunktionen wie der Einrichtung der LDAP-Synchronisierung gibt es noch Verbesserungsbedarf, aber die CI/CD-Syntax ist im Großen und Ganzen praktisch
Ich habe es von 2021 bis 2024 täglich benutzt und sogar ein eigenes Bug-Tagebuch geführt
Meine Erfahrungen dazu habe ich in einem früheren Kommentar hinterlassen
Der schlichte Issue-Tracker von GitHub ist viel einfacher zu benutzen
Projektmanager mögen GitLab vielleicht, aber aus Nutzersicht ist GitHub besser
Jetzt nutze ich GitHub, und es ist viel einfacher und effizienter
Ich hasse GitLab wirklich
Bei Docker-Images gibt es nur ein Limit pro Layer, die Gesamtkapazität kann also deutlich größer sein
Relevante Dokumente: Storage Usage Quotas, Container Registry Issue
Ich würde gern einen 70-GB-Interstellar-REMUX hochladen
Das Muster „etwas tun wollen → Fehler → suchen → offiziellen Bug-Report von vor 3 bis 8 Jahren finden“ wiederholt sich ständig
Viele Funktionen bleiben auf einem 80/20-Reifegrad stehen, und die MR-Ansicht ist so langsam, dass sie quälend ist
Ich habe das in einem früheren Kommentar beschrieben
Ich mag, dass sich Maven-, NPM- und Python-Paket-Registries in die CI-Pipeline integrieren lassen
Aber es gibt zu viele Funktionen, und jeder Bildschirm ist doppelt so langsam
Danach wurde auf Azure DevOps umgestellt, das langsam ist und schwache Quality Gates hat
Der Build-Server wurde in eine VM verlagert, wodurch Builds wegen IOPS-Beschränkungen langsam wurden
Ich würde gern zu GitLab zurückkehren und wäre auch bereit, zur Leistungsverbesserung beizutragen