GitLab — Grundlagen, Funktionen und CI/CD

Was ist GitLab?

GitLab — ist eine voll ausgestattete Open-Source-DevOps-Plattform unter der MIT-Lizenz. Im Gegensatz zu GitHub, das verschiedene Dienste über Integrationen kombiniert, bietet GitLab ein einziges Tool für den gesamten Entwicklungslebenszyklus: von Codeverwaltung und Code-Review bis hin zu CI/CD, Überwachung, Sicherheit und Bereitstellung. Die Plattform benötigt für die meisten DevOps-Aufgaben keine Drittanbieterdienste.

Die Geschichte von GitLab begann 2011 als internes Projekt ukrainischer Entwickler. Die erste öffentliche Version wurde im September 2011 veröffentlicht, und 2015 wurde GitLab das erste Projekt auf GitLab.com und startete Cloud-Hosting. 2017 führte GitLab einen schmerzhaften, aber lehrreichen Migrationsprozess durch — die Verlagerung der gesamten Infrastruktur von Azure zu Google Cloud, die live durchgeführt und in einer Reihe von Blogbeiträgen dokumentiert wurde.

Die Architektur von GitLab besteht aus drei Hauptkomponenten: GitLab Rails (Webanwendung auf Ruby on Rails), GitLab Shell (Abwicklung von Git-Operationen über SSH) und Gitaly (gRPC-Server für den Zugriff auf Git-Daten). CI/CD wird über GitLab Runner bereitgestellt — eine separate Anwendung, die auf Build-Servern installiert wird und Jobs in isolierten Umgebungen (Docker, Kubernetes, VirtualBox) ausführt.

GitLab CI/CD: Pipelines und Runner

GitLab CI/CD — ist ein integriertes System für kontinuierliche Integration und Bereitstellung, das ein entscheidender Vorteil der Plattform ist. Im Gegensatz zu GitHub Actions wurde GitLab CI/CD von Anfang an in die Architektur integriert und erfordert keine separate Einrichtung: Jedes Projekt erhält automatisch CI/CD, sobald die Datei .gitlab-ci.yml zum Repository-Root hinzugefügt wird.

Eine Pipeline besteht aus Stufen, die sequenziell oder parallel ausgeführt werden: build → test → deploy. Jede Stufe enthält einen oder mehrere Jobs, die auf Runnern ausgeführt werden. Wenn ein Job in einer Stufe fehlschlägt, wird die gesamte Stufe als fehlgeschlagen markiert, und nachfolgende Stufen werden standardmäßig nicht ausgeführt. Nachfolgend finden Sie ein Beispiel für eine Pipeline für ein mobiles Projekt:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner unterstützt mehrere Executors: Docker (empfohlen), Kubernetes, SSH, VirtualBox und Parallels. Die beliebteste Option ist der Docker-Executor, der jeden Job in einem separaten Container ausführt. Ein Runner kann als projektspezifisch oder als gemeinsam (shared) für eine gesamte Gruppe registriert werden. GitLab.com bietet kostenlose Shared Runner mit einem Limit von 2000 Minuten pro Monat.

Erweiterte CI/CD-Funktionen

GitLab CI/CD unterstützt manuelle Auslöser (when: manual), verzögerte Auslöser (when: delayed), parallele Ausführung (parallel: 5), Matrizen, dynamische Pipelines (Child Pipelines) und mehrstufige Pipelines (Parent-Child). Dies ermöglicht die Erstellung komplexer Szenarien: zum Beispiel die dynamische Generierung einer Pipeline für jedes Modul in einem Monorepo oder die parallele Ausführung von Builds für verschiedene Android-Architekturen (arm64, x86_64).

GitLab vs GitHub: Hauptunterschiede

GitLab und GitHub — sind die beiden Hauptkonkurrenten auf dem Markt für Git-Plattformen, aber ihre Philosophie und Architektur unterscheiden sich grundlegend. GitHub konzentriert sich auf offene Community, ein Ökosystem von Integrationen und soziale Funktionen (Forks, Stars). GitLab konzentriert sich auf einen umfassenden DevOps-Zyklus und bietet alle Tools aus einer Hand: von der Planung bis zur Überwachung.

Der Hauptunterschied in der Architektur: GitLab — ist eine einzelne monolithische Anwendung, die der Entwickler als Ganzes installiert. Alle Funktionen (CI/CD, Container Registry, Security Scanning, Pages) sind integriert und funktionieren sofort nach der Installation. GitHub ist eine Plattform mit API, bei der die meisten Funktionen durch Integration mit Drittanbieterdiensten implementiert werden: Travis CI, CircleCI, Jenkins, SonarQube. Die folgende Tabelle vergleicht die wichtigsten Merkmale:

Die Wahl zwischen GitLab und GitHub hängt von den Bedürfnissen des Teams ab. Wenn Priorität schnelle Bereitstellung mit Nullkonfiguration und eine offene Community ist — wählen Sie GitHub. Wenn Sie vollständige Kontrolle über die Infrastruktur, selbstgehostete Bereitstellung und integrierte Sicherheit benötigen — ist GitLab vorzuziehen. Laut einer Stack Overflow-Umfrage (2024) nutzen 90% der Entwickler GitHub, 33% nutzen GitLab (häufig beide Plattformen gleichzeitig).

Self-Managed GitLab: Installation auf Ihrem eigenen Server

Self-Managed GitLab (früher On-Premises) ermöglicht die Installation der Plattform auf Ihrem eigenen Server und die vollständige Kontrolle über Daten, Infrastruktur und Betriebszeit. Dies ist besonders wichtig für Organisationen mit Compliance-Anforderungen: Finanzsektor, Behörden, medizinische Einrichtungen, bei denen Daten nicht auf Servern Dritter gespeichert werden dürfen.

Die GitLab-Installation wird unter Ubuntu, Debian, CentOS und über Docker unterstützt. Das offizielle Omnibus-Paket enthält alle Komponenten: Webserver (NGINX), Datenbank (PostgreSQL), Cache (Redis), Git-Handler (Gitaly) und Hintergrundprozesse. Mindestanforderungen: 4 GB RAM und 2 CPU für Teams bis zu 100 Personen. Für große Installationen mit hoher Last wird empfohlen, die Komponenten auf separate Server zu verteilen.

# GitLab CE auf Ubuntu über Omnibus installieren
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Paket installieren
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Status anzeigen
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab hat keine CI/CD-Minutenbegrenzung — alle Runner gehören der Organisation und ihre Leistung wird nur durch Ihre eigene Hardware begrenzt. Ebenfalls verfügbar sind Geo-Replikation für Regionen, Audit-Logs, IP-Sperrung und Integration mit Unternehmens-LDAP/SAML-Anbietern. GitLab veröffentlicht jeden Monat (am 22.) Updates mit neuen Funktionen und Sicherheitskorrekturen.

Integrierte GitLab-Sicherheitstools

Sicherheit in GitLab ist auf Plattformebene integriert und umfasst mehrere Scanner, die in jeder Phase der Pipeline arbeiten. SAST (Static Application Security Testing) analysiert den Quellcode auf Schwachstellen, ohne die Anwendung auszuführen, und unterstützt über 15 Sprachen, darunter Java, Kotlin, Swift, Python und JavaScript. DAST (Dynamic Application Security Testing) testet laufende Webanwendungen von innen auf Schwachstellen.

Zusätzliche Tools: Container Scanning prüft Docker-Images auf Schwachstellen in den Basisschichten; Dependency Scanning analysiert Projektabhängigkeiten und warnt vor bekannten CVEs; Secret Detection findet versehentlich committete API-Schlüssel, Passwörter und Tokens; Fuzz Testing führt automatisierte Tests mit fehlerhaften Daten durch, um nicht offensichtliche Fehler zu finden. Alle Scanergebnisse werden in einem einheitlichen Security Dashboard angezeigt.

GitLab bietet auch Compliance-Tools zur Einhaltung gesetzlicher Anforderungen. Das Compliance Dashboard zeigt den Compliance-Status aller Projekte, Audit Events protokolliert jede Aktion von Administratoren und Entwicklern, und Compliance Frameworks ermöglichen die verbindliche Anwendung von Konfigurationsrichtlinien für bestimmte Projektgruppen. Dies macht GitLab zu einer beliebten Wahl in Unternehmensumgebungen mit strengen Sicherheitsanforderungen.

Container Registry und Dependency Proxy

GitLab Container Registry — ist eine integrierte Docker-Registry, die mit CI/CD verbunden ist. Nach dem Erstellen eines Docker-Images in einer Pipeline kann es sofort mit den Umgebungsvariablen CI_REGISTRY und CI_REGISTRY_USER in der Registry veröffentlicht werden. Die Registry unterstützt Pull-Through-Caching, Tagging, Bereinigungsrichtlinien und Schwachstellenscans direkt in der Registry.

Dependency Proxy — ein Caching-Mechanismus für Container und Images aus externen Registries (Docker Hub, Quay, GCR). Wenn eine Pipeline ein Image wie ubuntu:latest anfordert, überprüft GitLab zunächst seinen Cache — wenn das Image bereits heruntergeladen wurde, wird es nicht erneut abgerufen. Dies reduziert die Last auf externen Registries, beschleunigt Pipelines und schützt vor den Ratenbegrenzungen von Docker Hub.

Für mobile Entwickler bietet GitLab GitLab Pages zum Hosten von Dokumentation und Testberichten. Nach dem Ausführen von Tests können Artefakte (HTML-Berichte, Screenshots, Logs) als Pages veröffentlicht und ein Link mit dem QA-Team geteilt werden. Dies ist bequemer als das Hochladen von Berichten in Cloud-Speicher, da alles innerhalb desselben GitLab-Projekts bleibt.

GitLab API und Webhooks

GitLab API (REST und GraphQL) bietet Zugriff auf alle Ressourcen der Plattform: Projekte, Benutzer, Pipelines, Merge Requests, Registry. Die API wird für die Automatisierung verwendet: Erstellen eines Projekts aus einer Vorlage, Zuweisen eines Reviewers, Abrufen des Pipeline-Status. Webhooks ermöglichen das Senden von HTTP-Benachrichtigungen an externe Systeme bei Ereignissen: Push, Merge, Issue-Erstellung. Webhooks integrieren sich mit Mattermost, Slack, Telegram und internen Überwachungssystemen.

GitLab Pages für mobile Dokumentation

GitLab Pages veröffentlicht automatisch statische Websites aus einem Repository. Für mobile Projekte sind Pages praktisch zum Hosten von API-Dokumentation, Testabdeckungsberichten und Lint-Analyseergebnissen. Die Veröffentlichung erfolgt automatisch nach einer erfolgreichen Pipeline — fügen Sie einfach einen Deploy-Schritt mit Pages-Veröffentlichung in .gitlab-ci.yml hinzu. Das Ergebnis ist unter https://namespace.gitlab.io/project-name verfügbar.