Wer Software entwickelt oder testet, braucht eine Plattform, die nicht nur Code speichert, sondern den gesamten Lieferzyklus orchestriert: von der ersten Codezeile über Tests bis zur produktiven Freigabe. Für viele Teams ist GitHub die Default-Antwort. Doch GitLab ist mehr als eine Alternative: Es bündelt Repository, CI/CD, Security-Scanning, Issue-Tracking und Container-Registry auf einer Plattform.
Im DevOps-Alltag zählt vor allem die Frage: Wie schnell kommen wir vom Commit zur produktionsreifen Software, und wie zuverlässig prüfen wir Qualität dabei? GitLab adressiert genau diese Pipeline-Frage. Quality Gates, automatisierte Tests, Security-Scans und Compliance-Reports laufen integriert, statt verteilt über mehrere Tools.
Dieser Artikel zeigt Ihnen aus QA- und Testmanagement-Sicht, was GitLab kann, wo es sich von GitHub unterscheidet, wie eine CI/CD-Pipeline mit Test-Stage aufgebaut ist und welche Edition für Ihr Team passt.
Inhaltsverzeichnis
- Was ist GitLab und wie funktioniert es?
- GitLab vs. GitHub: Vergleich für Entwicklungs- und QA-Teams
- GitLab CI/CD: Pipeline-Stages und Test-Integration
- Quality Gates und Test-Reporting in GitLab
- GitLab für DevSecOps: Security-Scanning in der Pipeline
- Anwendungsfälle: GitLab im QA-Alltag
- Erste Schritte: GitLab-Pipeline mit Test-Stage einrichten
- GitLab-Editionen und Preise (Free, Premium, Ultimate)
- Fazit: Wann GitLab, wann GitHub?
- FAQ: Häufige Fragen zu GitLab
Was ist GitLab und wie funktioniert es?
GitLab ist eine integrierte DevOps-Plattform, die alle Phasen der Softwareentwicklung auf einer Oberfläche zusammenbringt: Planung, Source-Code-Management, Code-Review, Continuous Integration, Continuous Delivery, Security, Monitoring und Compliance. Im Zentrum steht ein webbasierter Git-Repository-Manager, der seit 2011 (Gründung in der Ukraine durch Dmitriy Zaporozhets) zu einer vollständigen All-in-One-Plattform gewachsen ist.
Während klassische Tool-Stacks Jira für Issues, GitHub für Code, Jenkins für CI/CD und Veracode für Security kombinieren, deckt GitLab diese Bereiche aus einer Hand ab. Das reduziert Schnittstellen, vereinfacht Berechtigungen und macht Reporting konsistent. Für QA-Teams bedeutet das: Testergebnisse, Coverage-Reports und Quality Gates leben im selben Werkzeug wie der Code.
GitLab vs. GitHub: Vergleich für Entwicklungs- und QA-Teams
Beide Plattformen bauen auf Git und decken die Kern-Workflows ab. Die Unterschiede liegen im Reifegrad der integrierten Funktionen und im Preismodell. Für Entwicklungs- und QA-Teams sind drei Achsen entscheidend: Funktionsumfang ohne Add-ons, Self-Hosting und Security-Tiefe.
| Funktion | GitLab | GitHub |
|---|---|---|
| Git-Repositories | Integriert | Integriert |
| Issues und Boards | Integriert (Epics, Roadmaps) | Integriert (Projects) |
| CI/CD | GitLab CI/CD nativ | GitHub Actions (Marketplace) |
| Security-Scanning (SAST, DAST, Container) | Integriert ab Ultimate | GitHub Advanced Security (Add-on) |
| Container-Registry | Inkludiert (Free) | Inkludiert (Free) |
| Self-Hosting | Self-Managed (alle Editionen) | GitHub Enterprise Server (Enterprise) |
| Compliance-Reports | Integriert ab Premium | Add-on über Advanced Security |
| Test-Reporting (JUnit, Coverage) | Integriert (Free) | Über Actions-Marketplace |
| Free-Tier | Privat + öffentlich, 400 CI-Minuten/Monat | Privat + öffentlich, 2.000 CI-Minuten/Monat (Free) |
| Marktanteil DACH | Stark in Mittelstand und reguliertem Umfeld | Stark bei OSS und Cloud-Startups |
Für Teams in regulierten Branchen (Banken, Versicherungen, Healthcare) ist GitLab oft erste Wahl: Self-Managed-Installation auf eigener Infrastruktur, lückenlose Audit-Trails und integrierte Compliance-Frameworks decken Anforderungen ab, für die GitHub Zusatzlizenzen braucht. Wer überwiegend Open-Source-Workflows nutzt und nahtlos in Cloud-Services integriert, bleibt mit GitHub schneller. Den Begriff im Detail erläutert unser Artikel Was ist GitHub? Plattform, Repositories und Funktionen erklärt. Eine grundsätzliche Einordnung der drei Begriffe bietet unser Beitrag Was ist Git, GitHub und GitLab?.
GitLab CI/CD: Pipeline-Stages und Test-Integration
GitLab CI/CD basiert auf einer Konfigurationsdatei .gitlab-ci.yml im Repository-Root. Jeder Commit triggert eine Pipeline, die in Stages organisiert ist. Stages laufen sequenziell, Jobs innerhalb einer Stage parallel. Diese Trennung erlaubt es, schnelle Smoke-Tests früh laufen zu lassen und teure End-to-End-Tests erst nach erfolgreichem Build.
Eine typische Test-Pipeline für ein Web-Backend besteht aus vier Hauptstages: Build, Test, Security und Deploy. Jede Stage hat klare Quality Gates: Fällt ein Job aus, stoppt die Pipeline und blockiert den Merge in den Hauptbranch.
| Stage | Aufgabe | Quality Gate |
|---|---|---|
| Build | Code kompilieren, Artefakt erzeugen (Docker-Image, JAR, npm-Bundle) | Build-Job grün, Artefakt vorhanden |
| Test | Komponententests (Unit-Test) und Integrationstests parallel ausführen, JUnit-Report sammeln | Coverage ≥ 80 Prozent, 0 fehlgeschlagene Tests |
| Security-Scan | SAST, Dependency-Scan und Container-Scan | 0 Findings mit Severity Critical oder High |
| E2E-Test | Deploy auf Staging-Umgebung, End-to-End-Tests (E2E) und Smoke-Tests | Alle Smoke-Tests grün, Performance-Budget eingehalten |
| Deploy | Release auf Production (Manual-Approval oder Auto-Deploy) | Manueller Approve durch Release-Manager oder automatisch bei tag-basiertem Trigger |
Die Test-Stage selbst lässt sich nach Test-Pyramide gliedern: Unit-Tests (schnell, breite Coverage), Integrationstests (Service-Schicht, mittlere Laufzeit), Komponententests (Unit-Test) und End-to-End-Tests (E2E) für kritische Nutzerflüsse. GitLab Runner führt Jobs auf Docker-Containern, Kubernetes-Pods oder dedizierten Maschinen aus. Verwandte Konzepte finden Sie in unserem Artikel zu Agiles Testmanagement in CI/CD.
Quality Gates und Test-Reporting in GitLab
Quality Gates sind die Sollbruchstelle zwischen Code und Produktion. In GitLab konfigurieren Sie sie auf zwei Ebenen: über Pipeline-Jobs (technische Gates wie Test-Coverage, Statische Code-Analyse, Security-Scan-Findings) und über Merge-Request-Regeln (organisatorische Gates wie Reviewer-Pflicht, Approval-Anzahl, Codeowner-Zustimmung).
GitLab parst JUnit-XML-Reports automatisch und zeigt fehlgeschlagene Tests direkt im Merge-Request, inklusive Diff der Test-Ergebnisse zum Zielbranch. Coverage-Reports landen als Badge im Repository und können als harte Schwelle konfiguriert werden: Sinkt die Test-Coverage unter 80 Prozent, blockiert GitLab den Merge. Dieselbe Mechanik gilt für Performance-Reports (Browser-Performance, Load-Tests) und Accessibility-Scans.
Für Testmanager liefert GitLab zwei Sichten, die das Reporting an Stakeholder vereinfachen: das Test-Pipeline-Dashboard (Trends über Pipelines hinweg) und den Test-Cases-Bereich (manuelle Tests in Premium und Ultimate). Mehr zum Aufbau eines konsistenten Test-Reportings finden Sie in unserem Beitrag zum Testkonzept.
Wie Sie Linting als verbindliches Quality-Gate in dieser Pipeline-Logik verankern, beschreibt der Praxis-Guide Linting & Quality-Gate: Code-Qualität in der CI/CD-Pipeline.
GitLab für DevSecOps: Security-Scanning in der Pipeline
GitLab integriert Security-Scanning direkt in die Pipeline. Ab Ultimate-Edition stehen vier Scanner ohne Zusatzlizenz zur Verfügung: SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), Dependency-Scanning für Bibliotheks-Schwachstellen und Container-Scanning für Docker-Images. Findings erscheinen als Befunde im Merge-Request, mit Severity-Klassifikation und Empfehlung zur Behebung.
Der Shift-Left-Ansatz wird damit konkret umsetzbar: Eine Security-Schwachstelle, die heute in einer SAST-Stage gefunden wird, kostet ein Vielfaches weniger als dieselbe Schwachstelle in Produktion. Die GitLab Vulnerability-Database enthält Pattern für gängige Sprachen (Java, Python, JavaScript, Go, .NET) und Container-Frameworks. Compliance-Frameworks (DSGVO, ISO 27001, SOC 2) lassen sich über Compliance-Pipelines erzwingen.
In regulierten Branchen ist das DevSecOps-Modul oft der entscheidende Differenzierer gegenüber GitHub. Statt Findings aus einem separaten Tool zu importieren, leben sie im selben Merge-Request, in dem das Feature gebaut wird. Das verkürzt den Feedback-Loop von Tagen auf Minuten.
Anwendungsfälle: GitLab im QA-Alltag
Drei Szenarien zeigen, wie QA- und Testmanagement-Teams GitLab im Tagesgeschäft einsetzen:
- Test-Reporting-Konsolidierung: Ein Versicherer mit 40 Microservices nutzte zuvor Jira, Jenkins und SonarQube. GitLab löst das Reporting-Patchwork ab: JUnit, Coverage und Security-Findings landen pro Merge-Request, der Testmanager sieht Pipeline-Health auf Group-Ebene ohne Tool-Wechsel.
- Cross-Team-Code-Reviews mit Quality Gates: Ein Healthcare-Anbieter konfigurierte Codeowner-Regeln so, dass bei Änderungen am Patient-Data-Service automatisch das Security- und das Compliance-Team als Reviewer hinzugezogen werden. Quality Gates blockieren Merges bei Test-Coverage unter 85 Prozent oder DAST-Findings mit Severity High.
- Compliance-Audit-Trail: Eine Bank dokumentiert mit GitLab-Compliance-Pipelines lückenlos, welcher Code-Stand zu welchem Zeitpunkt produktiv ging und welche Tests, Reviews und Approvals dem vorausgingen. Auditoren erhalten den Trail direkt aus GitLab statt aus mehreren Tools.
Erste Schritte: GitLab-Pipeline mit Test-Stage einrichten
Eine minimale CI/CD-Pipeline mit Test-Stage entsteht in drei Schritten. Voraussetzung: Sie haben ein Projekt auf gitlab.com oder einer Self-Managed-Instanz angelegt und Maintainer-Rechte.
- Datei
.gitlab-ci.ymlim Repository-Root anlegen. GitLab erkennt sie automatisch beim nächsten Push und startet die Pipeline. Definieren Sie zunächst zwei Stages (buildundtest) und einen Job pro Stage. - Test-Job mit JUnit-Reporter konfigurieren. Der Job ruft Ihr Test-Framework auf (z. B.
npm test -- --reporter=junit --outputFile=test-results.xml) und meldet das XML als Artifact mitreports.junit. GitLab parst es und zeigt Ergebnisse im Merge-Request. - Merge-Request-Regel für grüne Pipeline aktivieren. In den Projekt-Einstellungen den Schalter "Pipelines must succeed" aktivieren. Damit lassen sich Branches nur mergen, wenn alle Jobs grün sind.
Erweitern Sie die Pipeline anschließend um Security-Scans (Auto-DevOps-Templates), E2E-Tests in einer eigenen Stage und Coverage-Gates. Für E2E-Setups mit Playwright oder Cypress siehe unser Tutorial zu GitHub Actions. Die Pipeline-Konzepte sind weitgehend übertragbar.
GitLab-Editionen und Preise (Free, Premium, Ultimate)
GitLab gibt es in vier Editionen, jeweils als SaaS (gitlab.com) oder Self-Managed (eigene Infrastruktur). Die Wahl hängt an drei Fragen: Welche Compliance-Anforderungen gelten? Wie viele CI-Minuten brauchen Sie pro Monat? Brauchen Sie integriertes Security-Scanning?
| Edition | Kernfeatures | Preisniveau (pro Nutzer/Monat) | Zielgruppe |
|---|---|---|---|
| Free | Git-Repo, Issues, CI/CD (400 Min.), Container-Registry | kostenlos | Solo-Entwickler, Open-Source, Lern-Projekte |
| Premium | Free + Code-Quality, Multi-Branch-Pipelines, Approval-Regeln, Roadmaps, Support | ca. 29 USD | Mittelständische Teams mit Quality-Gate-Bedarf |
| Ultimate | Premium + SAST/DAST/Dependency/Container-Scanning, Compliance-Frameworks, Value-Stream-Analytics | ca. 99 USD | Regulierte Branchen, DevSecOps-Teams, Enterprise |
| Dedicated | Ultimate als Single-Tenant-SaaS auf AWS | auf Anfrage | Banken, Versicherungen, Behörden |
Faustregel: Für Teams bis zehn Entwickler ohne Compliance-Druck reicht Free oft aus, gegebenenfalls mit Self-Managed-Installation für höhere CI-Minuten. Premium lohnt sich, sobald formale Merge-Approval-Workflows nötig werden. Ultimate ist Pflicht, wenn Security-Scanning und Compliance-Reports vom Kunden oder Regulator gefordert sind.
Fazit: Wann GitLab, wann GitHub?
GitLab und GitHub adressieren beide den modernen DevOps-Workflow, setzen aber unterschiedliche Schwerpunkte. GitHub bleibt der Standard für Open-Source-Communities, Cloud-native Setups und Teams, die mit GitHub Actions schnell loslegen wollen. GitLab spielt seine Stärken aus, wenn Self-Hosting, integrierte Security und Compliance-Reports zur Pflicht werden, oder wenn das Team ein All-in-One-Werkzeug einem Patchwork aus Spezial-Tools vorzieht.
Für QA- und Testmanagement-Teams empfehlen wir GitLab in zwei Szenarien: Erstens, wenn Test-Reporting, Coverage-Gates und Security-Scans in einem Tool laufen sollen. Zweitens, wenn die Pipeline-Konfiguration als Code im selben Repository wie der Anwendungscode liegen soll, statt verteilt über Jenkins-Jobs und externe Konfigurationsdateien. Brauchen Sie Unterstützung beim Aufbau einer GitLab-CI/CD-Pipeline mit integrierten Quality Gates und Test-Reporting? Wir bringen Ihre Pipeline auf den Punkt.
FAQ: Häufige Fragen zu GitLab
Was ist GitLab und wofür wird es verwendet?
GitLab ist eine DevOps-Plattform, die Source-Code-Management, CI/CD, Security-Scanning, Issue-Tracking und Container-Registry auf einer Oberfläche bündelt. Sie wird vor allem für die Entwicklung, das Testen und das Ausliefern von Software eingesetzt, häufig in regulierten Branchen, weil Self-Hosting und Compliance-Reports integriert sind. Weitere Tools finden Sie in unserem Vergleich der Testmanagement-Tools.
Ist GitLab kostenlos oder kostenpflichtig?
GitLab hat eine kostenlose Free-Edition mit Repository, Issues, CI/CD (400 Minuten pro Monat) und Container-Registry. Premium (ca. 29 USD pro Nutzer/Monat) ergänzt Multi-Branch-Pipelines und Approval-Workflows. Ultimate (ca. 99 USD) bringt SAST, DAST und Compliance-Frameworks dazu.
Was ist der Unterschied zwischen GitLab und GitHub?
GitLab ist eine integrierte All-in-One-Plattform inklusive CI/CD, Security-Scanning und Compliance-Funktionen. GitHub ist stärker bei Open-Source und Cloud-Integration, ergänzt Security und Advanced-Features aber über kostenpflichtige Add-ons. Self-Managed-Installationen sind bei GitLab ab Free möglich, bei GitHub erst ab Enterprise Server.
Was ist ein GitLab Runner und warum ist er wichtig?
Ein GitLab Runner ist ein Agent-Prozess, der CI/CD-Jobs ausführt. Er kann auf Docker, Kubernetes, virtuellen Maschinen oder bare-metal-Hosts laufen. Sie skalieren Pipelines, indem Sie weitere Runner anhängen. Auf gitlab.com sind Shared Runner verfügbar; Self-Managed-Setups nutzen meist eigene Runner für vollständige Kontrolle und kürzere Job-Laufzeiten.
Wie unterscheidet sich GitLab CI/CD von Jenkins oder GitHub Actions?
GitLab CI/CD ist nativ in die Plattform integriert: Pipeline-Konfiguration liegt als .gitlab-ci.yml im Repository, Ergebnisse erscheinen direkt im Merge-Request. Jenkins ist ein eigenständiges Tool mit eigener UI und Plugin-Ökosystem. GitHub Actions kombiniert Plattform-Integration mit einem großen Marketplace. Für reine GitHub-Setups bleibt Actions naheliegender; für integrierte Security plus Self-Hosting punktet GitLab.
Kann ich GitLab für Software-Tests nutzen?
Ja, GitLab eignet sich für alle Test-Ebenen: Komponententests (Unit-Test), Integrationstests, End-to-End-Tests (E2E), Performance- und Security-Tests. JUnit-Reports werden automatisch geparst, Coverage-Schwellen als Quality Gates konfiguriert. Für komplexe Test-Pipelines siehe unsere Praxis zu agilem Testmanagement in CI/CD.
Wie sicher ist GitLab?
GitLab erfüllt SOC 2 Type II, ISO 27001 und DSGVO-Anforderungen. Ab Ultimate-Edition liefert es integriertes Security-Scanning (SAST, DAST, Dependency-Scanning, Container-Scanning) und Compliance-Pipelines. Self-Managed-Installationen erlauben volle Kontrolle über Datenhaltung, Backup und Audit-Logs. Das ist Standard in Banken und Behörden.