Was ist GitLab CI?
GitLab CI ist die in GitLab integrierte CI/CD-Engine. Pipelines werden als .gitlab-ci.yml im Repository definiert und auf GitLab Runnern ausgeführt. Der Vorteil: Code-Verwaltung, Pipelines, Container-Registry, Security-Scans und Deployment laufen auf einer einzigen Plattform — self-managed auch vollständig on-premise im eigenen Rechenzentrum.
Ist GitLab CI bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
GitLab CI — oft auch GitLab CI/CD genannt — 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 und GitLab CI?
- GitLab ist die gesamte DevOps-Plattform — Repository-Verwaltung, Issues, Container-Registry, Deployment-Umgebungen. GitLab CI ist der darin integrierte CI/CD-Teil, der Pipelines aus der .gitlab-ci.yml ausführt. Eine separate Installation gibt es nicht: Wer GitLab betreibt, hat GitLab CI bereits an Bord und muss lediglich Runner registrieren.
- Ist GitLab CI kostenlos?
- In den Grundzügen ja: Die Free-Stufe von GitLab.com enthält GitLab CI mit einem monatlichen Kontingent an Compute-Minuten; eigene Runner laufen ohne Minutenlimit. Self-managed steht die Community Edition unter Open-Source-Lizenz bereit. Funktionen wie Compliance-Frameworks oder Security-Dashboards erfordern die kostenpflichtigen Premium- bzw. Ultimate-Stufen.
- 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.
Wo steht Ihr Team bei GitLab CI?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
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