GitLab

Bild: Gabriel Mazetto, CC BY-SA 4.0, Wikimedia Commons

Kurz: Eine Plattform zum Hosten von Git-Repositories, funktional ähnlich zu GitHub, aber zusätzlich als selbst gehostete (“Self-Hosted”) Variante verfügbar.

Genauer: Bietet Pull-Request-Äquivalente (“Merge Requests”), integrierte CI/CD-Pipelines und Issue-Tracking. Die Möglichkeit, eine eigene GitLab-Instanz im eigenen Rechenzentrum zu betreiben, macht es besonders für Unternehmen mit strengen Datenschutz- oder Compliance-Anforderungen attraktiv.

Im Detail

”One DevOps Platform”-Philosophie

GitLab wurde von Anfang an stärker als “DevOps-Plattform” positioniert als GitHub: CI/CD-Pipelines, Container-Registry, Security-Scanning (statische Codeanalyse, Abhängigkeits-Scans auf bekannte Sicherheitslücken), Deployment-Tracking und sogar ein integriertes Wiki/Projektmanagement sind direkt Teil derselben Anwendung, statt (wie bei GitHub Actions) über ein separates Ökosystem an Marktplatz-Erweiterungen von Drittanbietern zusammengestellt zu werden. GitLabs eigenes Marketing nennt das “One DevOps Platform” — die Idee, den gesamten Software-Lebenszyklus (Planung, Code, Build, Test, Deploy, Monitoring) in einem einzigen Tool abzubilden, statt mehrere spezialisierte Tools zu verknüpfen.

Self-Hosting als strukturelles Alleinstellungsmerkmal

Der wichtigste strukturelle Unterschied ist die Self-Hosting-Option: eine Firma kann “GitLab Community Edition” (kostenlos, Open Source) oder “GitLab Enterprise Edition” (kostenpflichtig, mit Zusatzfeatures) auf eigener Infrastruktur betreiben, sodass Quellcode das eigene Netzwerk nie verlässt — relevant für Behörden, Banken, Rüstungsindustrie oder andere Organisationen mit strengen regulatorischen Auflagen, bei denen Cloud-gehostete Lösungen wie GitHub.com aus Compliance-Gründen grundsätzlich nicht infrage kommen. GitHub bietet mit “GitHub Enterprise Server” zwar mittlerweile ebenfalls eine On-Premise-Variante, historisch war GitLab hier aber deutlich früher am Markt und wird in stark regulierten Branchen bis heute häufiger eingesetzt.

CI/CD-Konfiguration im Vergleich

# .gitlab-ci.yml — GitLab-Pendant zu einem GitHub-Actions-Workflow
build:
  stage: build
  script:
    - npm install
    - npm run build
 
test:
  stage: test
  script:
    - npm test

Funktionale Annäherung

Funktional sind sich beide Plattformen mittlerweile sehr ähnlich, auch wenn die Begriffe unterschiedlich heißen: Merge Requests entsprechen GitHubs Pull Requests, GitLab CI/CD entspricht GitHub Actions, Issues/Boards decken ähnliches Kanban-artiges Projektmanagement ab. Der Unterschied liegt heute weniger in den Kernfunktionen als in Ökosystem-Größe (GitHub hat als Microsoft-Tochter und Standort der meisten Open-Source-Projekte deutlich mehr Netzwerkeffekt und Community) und eben der Self-Hosting-Reife.

Integriertes Security-Scanning

Ein oft hervorgehobenes GitLab-Feature ist das direkt in die Pipeline integrierte Security-Scanning: statische Codeanalyse (SAST — findet potenzielle Sicherheitslücken direkt im Quellcode, ohne ihn auszuführen), Abhängigkeits-Scans (bekannte Schwachstellen in genutzten Bibliotheken) und Container-Scanning (Sicherheitslücken in Docker-Images) laufen automatisch bei jedem Merge Request mit und zeigen Ergebnisse direkt in der Code-Review-Oberfläche an, statt als separates, oft vergessenes Extra-Tool.

Siehe auch: Git, GitHub, CI/CD-Pipeline