- 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.yml hinzugefügt wird, läuft die Pipeline automatisch an
- Die Konfiguration steht unter Versionskontrolle, sodass sich frühere Pipeline-Zustände nachvollziehen lassen
- 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
Noch keine Kommentare.