Was bietet GitLab CI?
GitLab CI ist die integrierte CI/CD-Lösung der GitLab-Plattform. Der Vorteil: Code-Verwaltung, Pipelines, Container-Registry, Security-Scans und Deployment laufen auf einer einzigen Plattform, ohne dass verschiedene Tools zusammengeklebt werden müssen.
Jenkins, GitLab CI & Azure DevOps im VergleichGitLab CI/CD ist die in GitLab integrierte Continuous-Integration- und -Delivery-Engine, die Pipelines über eine .gitlab-ci.yml im Repository definiert und auf GitLab Runnern ausführt. Ihr zentraler Vorteil ist die Geschlossenheit: Repository, Issues, Container-Registry, Pipelines, Security-Scans und Deployment-Umgebungen leben in einer Plattform, die sich als Self-Managed-Instanz vollständig on-premise betreiben lässt. Jobs sind Stages zugeordnet und laufen auf Runnern, die als Shell-, Docker- oder Kubernetes-Executor konfiguriert werden. Wer Werkzeug-Sprawl vermeiden will, findet hier eine integrierte Antwort.
Für regulierte und air-gapped Umgebungen ist die Self-Managed-Variante ein Argument. Eine Instanz im eigenen Rechenzentrum mit Runnern in der Fertigungs-DMZ deckt den kompletten Software-Lifecycle ab, ohne dass Code oder Artefakte das Unternehmensnetz verlassen. Funktionen wie Merge-Request-Pipelines, Container-Scanning und Compliance-Frameworks unterstützen Nachweise für IEC 62443 oder ASPICE direkt aus dem Werkzeug heraus.
Stolpersteine liegen in der Runner-Architektur — Executor-Wahl, Tagging und Skalierung wollen geplant sein — sowie in komplexen Pipeline-Strukturen mit include, extends und Parent-Child-Pipelines, die schnell unübersichtlich werden. Die DAG-Steuerung über needs erlaubt zwar parallele, abhängigkeitsgetriebene Ausführung, erhöht aber die kognitive Last. KI-Assistenz wie Claude Code hilft, .gitlab-ci.yml zu generieren, zu refactoren und include-Strukturen zu entwirren.
Self-Managed-Instanz im KRITIS-Netz
Ein Energieversorger betreibt GitLab self-managed hinter der Firmen-Firewall mit Runnern in der OT-DMZ, sodass Pipeline, Registry und Deployment vollständig im regulierten Netz bleiben und keine externen Dienste benötigen.
Merge-Request-Pipeline mit Security-Gate
Jeder Merge Request triggert eine Pipeline mit Container-Scanning und SAST; nur bei grünem Sicherheitsbericht ist der Merge-Button aktiv — Compliance-Nachweise entstehen automatisch als Pipeline-Artefakt.
DAG-Pipeline per needs
Ein Monorepo nutzt needs, um unabhängige Build- und Test-Jobs parallel statt streng nach Stages laufen zu lassen, was die Gesamtlaufzeit deutlich verkürzt — die Struktur wurde mit Claude Code aus der vorherigen seriellen Pipeline abgeleitet.
- Was ist der Unterschied zwischen GitLab.com und GitLab self-managed?
- GitLab.com ist das SaaS-Angebot, self-managed ist die selbst betriebene Instanz im eigenen Rechenzentrum. Für regulierte, air-gapped oder datensouveräne Szenarien ist self-managed entscheidend, weil Code und Artefakte das eigene Netz nicht verlassen.
- Welche Runner-Executor-Typen gibt es und wann nutzt man welchen?
- Üblich sind Shell, Docker und Kubernetes als Executor. Docker bietet saubere Isolation pro Job und ist Standard für die meisten Builds; Kubernetes skaliert dynamisch in Cluster-Umgebungen; Shell eignet sich für Spezialfälle mit direktem Hardware- oder Tool-Zugriff auf dem Runner-Host.
- Wie strukturiert man große .gitlab-ci.yml-Dateien wartbar?
- Über include lassen sich Teile in separate Dateien oder Templates auslagern, extends reduziert Duplikate durch Vererbung von Job-Definitionen, und Parent-Child-Pipelines zerlegen sehr große Pipelines in beherrschbare Einheiten. So bleibt die Konfiguration auch bei vielen Jobs übersichtlich.
- GitLab CI oder GitHub Actions — was passt für Industrieumgebungen?
- Beide bieten selbstgehostete Runner für OT-Anbindung. GitLab CI punktet mit einer vollständig self-managed betreibbaren All-in-one-Plattform inklusive Registry, Security-Scans und Compliance-Frameworks aus einer Hand — ein Vorteil für air-gapped und datensouveräne Szenarien. GitHub Actions ist enger ans GitHub-Ökosystem und seinen Marketplace gebunden und stark, wenn Code dort ohnehin liegt. Für streng regulierte OT-Netze ist die Geschlossenheit von GitLab self-managed meist das ausschlaggebende Argument.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance