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. Als Self-Managed-Installation steht sie auch vollständig on-premise im eigenen Rechenzentrum.
Auch bekannt als: GitLab CI/CD · gitlab-ci.yml · GitLab Pipelines
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.
Sobald jemand pusht oder einen Merge Request öffnet, liest GitLab die .gitlab-ci.yml im Repository und legt daraus eine Pipeline an. Jobs gehören zu Stages wie build, test und deploy. Die Stages laufen nacheinander, die Jobs innerhalb einer Stage parallel. Ausgeführt werden die Jobs von GitLab Runnern, kleinen Agent-Programmen, die sich beim GitLab-Server melden und Arbeit abholen. Jeder Runner nutzt einen Executor, meist Docker, Kubernetes oder die Shell des Hosts. GitLab CI wird oft auch GitLab CI/CD genannt und ist Teil derselben Plattform wie Repository, Issues und Container-Registry.
Gegenüber Jenkins liegt der Unterschied in dieser Geschlossenheit. Jenkins ist ein eigener Server, der mit einem separaten Git-Server und Plugins zusammenarbeitet. GitLab bringt Code-Verwaltung, Pipelines, Registry, Security-Scans und Deployment-Umgebungen in einer Installation mit. Wer den Werkzeugpark klein halten will, spart damit Integrationsarbeit, verzichtet aber auf die fast beliebige Erweiterbarkeit von Jenkins.
Für regulierte und air-gapped Umgebungen spricht die Self-Managed-Variante. Eine Instanz im eigenen Rechenzentrum mit Runnern in der Fertigungs-DMZ deckt den gesamten Software-Lifecycle ab, ohne dass Code oder Artefakte das Unternehmensnetz verlassen. Merge-Request-Pipelines, Container-Scanning und Compliance-Frameworks liefern Nachweise für IEC 62443 oder ASPICE direkt aus dem Werkzeug.
Die Stolpersteine liegen in der Runner-Architektur und in wachsenden Pipeline-Dateien. Executor-Wahl, Tagging und Skalierung der Runner wollen geplant sein. Konstrukte wie include, extends und Parent-Child-Pipelines machen eine .gitlab-ci.yml schnell unübersichtlich. Mit needs lassen sich Jobs abhängigkeitsgetrieben parallel starten statt streng nach Stages, das spart Laufzeit, macht die Pipeline aber schwerer lesbar. Claude Code hilft, .gitlab-ci.yml zu erzeugen, umzubauen und verschachtelte include-Strukturen zu entwirren.
Self-Managed-Instanz im KRITIS-Netz
Ein Energieversorger darf Quellcode seiner Leittechnik nicht zu einem SaaS-Anbieter geben. Er betreibt GitLab self-managed hinter der Firmen-Firewall, die Runner stehen in der OT-DMZ. Pipeline, Registry und Deployment bleiben vollständig im regulierten Netz, ohne einen externen Dienst.
Merge-Request-Pipeline mit Security-Gate
Sicherheitsprüfungen liefen bisher einmal vor dem Release, Befunde kamen zu spät. Jetzt startet jeder Merge Request eine Pipeline mit Container-Scanning und SAST (statischer Code-Analyse), und gemergt wird erst bei grünem Bericht. Der Bericht bleibt als Pipeline-Artefakt für den Audit liegen.
Serielle Pipeline per needs entzerrt
Die Pipeline eines Monorepos lief streng Stage für Stage, obwohl die meisten Jobs voneinander unabhängig waren. Mit Claude Code leitet das Team aus den tatsächlichen Abhängigkeiten eine needs-Struktur ab. Unabhängige Build- und Test-Jobs starten nun gleichzeitig, und die Gesamtlaufzeit sinkt spürbar.
GitLab CI — schon im Haus oder Wechsel?
GitLab CI kann SCM, Pipelines und Security aus einer Hand — wie Sie einsteigen, hängt daran, wie Sie GitLab heute nutzen. Zwei Klicks geben die Richtung.
Wie nutzen Sie GitLab heute?
- Was ist der Unterschied zwischen GitLab und GitLab CI?
- GitLab ist die gesamte DevOps-Plattform mit Repository-Verwaltung, Issues, Container-Registry und 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 nur Runner registrieren.
- Was sind die Unterschiede zwischen Jenkins und GitLab CI?
- Jenkins ist ein eigenständiger Automatisierungsserver, GitLab CI ist fest in die GitLab-Plattform eingebaut. Jenkins-Pipelines stehen als Jenkinsfile in Groovy und werden über Plugins erweitert, GitLab-Pipelines als YAML ohne Plugin-Verwaltung. Jenkins arbeitet mit jedem Git-Server und bindet fast jede Hardware als Agent an. GitLab CI bringt dafür Registry, Security-Scans und Merge-Request-Integration ohne Zusatzaufwand mit.
- Kann GitLab CI lokal laufen?
- Ja, in zwei Bedeutungen: GitLab lässt sich als Self-Managed-Instanz komplett auf eigenen Servern betreiben, und Runner laufen auf jedem Rechner im eigenen Netz. Einzelne Jobs auf dem Entwickler-Laptop auszuführen, ist dagegen nur eingeschränkt möglich. Der Befehl gitlab-runner exec ist seit GitLab 15.8 als veraltet markiert, weil er viele Pipeline-Funktionen nicht abbildet. Die Syntax prüft der Pipeline-Editor in GitLab, für lokale Testläufe greifen viele Teams zum Community-Projekt gitlab-ci-local.
- 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 Stufen Premium oder Ultimate.
- Welche Runner-Executor-Typen gibt es und wann nutzt man welchen?
- Üblich sind Shell, Docker und Kubernetes als Executor. Docker isoliert jeden Job in einem eigenen Container und ist der Standard für die meisten Builds. Kubernetes skaliert Jobs dynamisch in einem Cluster, Shell eignet sich für Spezialfälle mit direktem Zugriff auf Hardware oder Tools des Runner-Hosts.
- Wie strukturiert man große .gitlab-ci.yml-Dateien wartbar?
- Mit include lagern Sie Teile in separate Dateien oder Templates aus, extends vermeidet Duplikate, indem Jobs Definitionen erben. Parent-Child-Pipelines zerlegen sehr große Pipelines in kleinere Einheiten, die jeweils eine eigene Datei haben. So bleibt die Konfiguration auch bei vielen Jobs lesbar.
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.
Weiterführende Primärquellen zu GitLab CI: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01GitLab DocsGitLab CI/CD(externe Seite, öffnet in neuem Tab)
Offizieller Einstieg in Pipelines, Jobs, Umgebungen und Freigaben.
- /02GitLab Docsgitlab-ci.yml Referenz(externe Seite, öffnet in neuem Tab)
Alle Schlüsselwörter der Pipeline-Definition mit Beispielen.
- /03GitLab DocsGitLab Runner(externe Seite, öffnet in neuem Tab)
Installation und Betrieb eigener Runner, auch im abgeschotteten Netz.
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