GitLab CI/CD: Pipelines und Jobs

GitLab CI/CD ist neben GitHub Actions die zweite große CI-Plattform am Markt. Während GitHub Actions oft bei Open-Source-Projekten und kleineren Teams glänzt, ist GitLab das DevOps-Schwergewicht für Enterprise und Self-Hosting. Es bietet eine alles-in-einem-Lösung: Git-Repo, CI/CD, Container-Registry, Issue-Tracking, Wiki – alles aus einer Hand.

Diese Lektion zeigt dir den GitLab-CI-Workflow mit der Datei .gitlab-ci.yml: Stages, Jobs, Variables, Rules, Artifacts, Cache, GitLab Runner. Wenn du L3 GitHub Actions kannst, wirst du viele Parallelen sehen – die Konzepte sind ähnlich, die Syntax leicht anders.

1) Was unterscheidet GitLab von GitHub?

Beide Plattformen sind sich auf den ersten Blick sehr ähnlich. Aber es gibt strukturelle Unterschiede, die GitLab gerade für Unternehmen attraktiv machen:

GitHub Actions vs. GitLab CI/CD im Vergleich

GitHub Actions

Workflow-Files .github/workflows/*.yml ✓

Mehrere Workflow-Files möglich ✓

Marketplace mit 20k+ Actions ✓

Self-Hosted Runner ✓

On-Premise / Self-Hosted Server eingeschränkt (GHE)

Container-Registry integriert ✓ ghcr.io

Built-in DAST/SAST ✗ extra

GitLab CI/CD

Eine zentrale Datei .gitlab-ci.yml ✓

Includes für Modularität ✓

Templates statt Marketplace ✓

Shared/Group/Project Runner ✓

Self-Hosted (CE/EE) frei verfügbar ✓✓

Container-Registry integriert ✓

Built-in DAST/SAST/Security ✓ Ultimate

Der größte Unterschied in der Praxis: GitLab ist komplett self-hostable. Du kannst die ganze Plattform auf eigenem Server installieren (GitLab Community Edition oder Enterprise Edition). Für Firmen mit hohen Compliance-Anforderungen ist das wichtig. GitHub geht das nur mit GitHub Enterprise.

2) Die zentrale Datei: .gitlab-ci.yml

Während GitHub mehrere Workflow-Files erlaubt, hat GitLab eine zentrale Datei: .gitlab-ci.yml im Repo-Wurzelverzeichnis. Das ist Konvention – über include: kannst du sie in Module aufteilen.

.gitlab-ci.ymlGitLab YAML

1# Stages global definieren – Reihenfolge wichtig!
2stages:
3  - build
4  - test
5  - deploy
6
7# Globale Variablen für alle Jobs
8variables:
9  NODE_VERSION: "20"
10
11# Erster Job: build-frontend
12build-frontend:
13  stage: build
14  image: node:20-alpine
15  script:
16    - npm ci
17    - npm run build
18  artifacts:
19    paths: [dist/]
20
21# Zweiter Job: test in Stage test
22unit-tests:
23  stage: test
24  image: node:20-alpine
25  script: npm test

Beachte zwei wichtige Unterschiede zu GitHub Actions:

image:: GitLab definiert standardmäßig in welchem Docker-Image der Job läuft (z.B. node:20-alpine). Bei GitHub steht runs-on: ubuntu-latest – ohne Container-Konzept
Job-Name als Top-Level: build-frontend: ist gleichzeitig der Job-Name UND der Schlüssel. In GitHub gibt's jobs.build-frontend als verschachtelte Struktur

3) Stages und Jobs visualisiert

So sieht eine typische GitLab-Pipeline im UI aus. Stages als Spalten, Jobs als Boxen darin:

GitLab Pipeline-Ansicht (Mockup)

build

✓build-frontend

45s

✓build-backend

1m 20s

test

✓unit-tests

2m 10s

✓integration-tests

3m 30s

✓lint

25s

deploy

✓deploy-staging

1m 5s

⏸deploy-prod

manual

Die Pipeline-View zeigt sehr klar was läuft. Jeder Punkt steht für einen Job mit Status (✓ erfolgreich, ✗ fehlgeschlagen, ⏸ wartet auf manuelle Aktion). Klick auf einen Job zeigt die kompletten Logs.

4) GitLab Runner: das ausführende Element

Wie GitHub Actions braucht GitLab CI/CD Runner – Server die die Jobs ausführen. Es gibt drei Arten:

GitLab Runner-Typen

Shared Runner

Von GitLab.com kostenlos zur Verfügung gestellt. Geteilt mit allen Nutzern. Für kleine Projekte ausreichend.

Standard auf gitlab.com

Group Runner

Eigene Runner für eine ganze Group/Organisation. Alle Projekte der Gruppe können sie nutzen.

Enterprise / Self-Hosted

Project Runner

Dediziert für ein einziges Projekt. Höchste Kontrolle, aber meist Overkill.

Speziell-Anforderungen

Self-Hosted Runner werden mit dem Binary gitlab-runner registriert. Es gibt verschiedene Executor: Shell, Docker (am häufigsten), Kubernetes, VirtualBox. Mit Docker-Executor läuft jeder Job in einem frischen Container – isoliert und reproduzierbar.

5) Variablen: lokal, global, secret

Variablen können auf verschiedenen Ebenen definiert werden – mit klarer Priorität. Job-spezifische überschreiben globale, und Secrets aus der GitLab-UI haben höchste Priorität:

variables.ymlYAML

1# Globale Variablen für alle Jobs
2variables:
3  DB_HOST: "db.example.com"
4  NODE_VERSION: "20"
5
6deploy-job:
7  stage: deploy
8  # Job-spezifische Variable überschreibt global
9  variables:
10    DB_HOST: "prod-db.example.com"
11  script:
12    - echo "Deploy zu $DB_HOST"     # prod-db.example.com
13    - echo "Mit Token $API_TOKEN"   # aus Secret-Variable

Zusätzlich gibt's Secret-Variablen im GitLab-UI unter Settings → CI/CD → Variables. Hier hinterlegst du API-Tokens, Passwörter usw. – sie tauchen niemals in Logs auf und sind im Klartext nicht abrufbar. Praktisch: man kann sie als „Protected" markieren – dann nur in Pipelines von protected branches verfügbar. „Masked" bewirkt zusätzlich, dass die Variable in Logs durch [MASKED] ersetzt wird.

6) Rules: wann läuft welcher Job?

Historisch nutzte GitLab only: und except: für Filter. Heute ist rules: empfohlen – mächtiger und ausdrucksstärker:

Alte vs. neue Syntax

only/except (alt)

rules (modern)

deploy-prod:
  stage: deploy
  script: ./deploy.sh
  rules:
    # Bei Tag → manuell deploybar
    - if: '$CI_COMMIT_TAG'
      when: manual
    # Bei main-Branch → automatisch
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_success
    # Sonst gar nicht
    - when: never

Reichere Logik: prüfe Variablen, Branches, Tags. when: manual braucht Mensch-Klick. when: never = Job läuft nicht. Reihenfolge der Rules ist wichtig – erste matchende gewinnt.

7) Artifacts und Cache: was bleibt zwischen Jobs?

Zwei Konzepte zum Datenfluss zwischen Jobs, die oft verwechselt werden. Wichtig den Unterschied zu kennen, sonst funktioniert die Pipeline nicht wie erwartet:

Konzept	Zweck	Lebensdauer
Artifacts	Build-Output (JAR, dist/, Reports) für nachfolgende Stages	Standard 30 Tage
Cache	Dependencies (node_modules, .m2/) für nachfolgende Pipelines	Persistent, bis manuell geleert

art-cache.ymlYAML

1build:
script: npm run build
# Artifacts: an nachfolgende Jobs weiterreichen
artifacts:
  paths:
    - dist/
    - coverage/
  expire_in: "1 week"
  when: on_success
10
# Cache: für schnellere nachfolgende Pipelines
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

Faustregel: Artifacts sind „Output von diesem Job", Cache ist „Material das ich beim nächsten Mal wieder brauche". Bei artifacts:reports: kann GitLab spezielle Reports auswerten (Test-Coverage, JUnit, Container-Scanning) und im UI integrieren.

8) Includes und Templates: Wiederverwendung

Statt eine 500-Zeilen-yml-Datei zu pflegen, kannst du sie aufteilen mit include:. Das ist eines der Features, das in der Praxis viel Zeit spart und Wartung erleichtert:

.gitlab-ci.ymlYAML

1include:
# Aus eigenem Repo
- local: .gitlab/ci/build.yml
- local: .gitlab/ci/test.yml
5
# GitLab-Templates für Standardaufgaben
- template: Security/SAST.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml
9
# Aus anderem GitLab-Projekt
- project: "my-org/ci-templates"
  file: "deploy.yml"

Templates sind besonders wertvoll: GitLab liefert vorgefertigte Templates für Security-Scans (SAST, DAST, Dependency-Scanning), Code-Quality, License-Compliance. Mit einer Zeile include: template: ... aktivierst du komplexe Funktionalität.

9) Environments und Auto DevOps

GitLab hat ein eingebautes Konzept für Environments – mehr als nur Stage-Namen. Environments sind eigenständige Entitäten mit Deploy-History, URL und Rollback-Möglichkeit:

env.ymlYAML

1deploy-staging:
stage: deploy
script: ./deploy.sh staging
environment:
  name: staging
  url: https://staging.app.de
7
8deploy-production:
stage: deploy
script: ./deploy.sh production
environment:
  name: production
  url: https://app.de
when: manual

GitLab zeigt dann in der Web-UI ein Dashboard mit allen Environments, der aktuell deployten Version, Deploy-Historie und Rollback-Button. Sehr nützlich für Operations-Teams. Mehr zu Deployment-Strategien in K56.

Auto DevOps ist eine GitLab-Spezialität: mit einem Klick aktivierst du eine vorgefertigte Pipeline, die dein Projekt automatisch baut, testet, scannt und auf Kubernetes deployt – ohne dass du ein einziges YAML schreiben musst. GitLab erkennt den Projekt-Typ (Node, Java, Python, etc.), baut ein Docker-Image, läuft Tests, macht Security-Scans und deployed auf einen konfigurierten Cluster. Für 80% der Projekte funktioniert das ohne Anpassung.

10) Vordefinierte CI/CD-Variablen

GitLab stellt viele vordefinierte Variablen bereit, die in Pipelines unschätzbar wertvoll sind. Hier die wichtigsten, die du oft brauchen wirst:

Variable	Inhalt
`$CI_COMMIT_SHA`	Vollständige Git-Commit-SHA
`$CI_COMMIT_SHORT_SHA`	Kurze Commit-SHA (8 Zeichen) – für Image-Tags
`$CI_COMMIT_BRANCH`	Branch-Name (nur bei branch-Push verfügbar)
`$CI_COMMIT_TAG`	Tag-Name (nur bei Tag-Push verfügbar)
`$CI_COMMIT_REF_NAME`	Branch- oder Tag-Name (immer verfügbar)
`$CI_COMMIT_REF_SLUG`	Sanitisierte Version (für URLs/Cache-Keys)
`$CI_PIPELINE_ID`	Eindeutige Pipeline-ID
`$CI_PROJECT_NAME`	Name des aktuellen Projekts
`$CI_REGISTRY_IMAGE`	URL zum Container-Registry-Repository
`$CI_JOB_TOKEN`	Token zum Authentifizieren gegen GitLab API

Typisches Beispiel-Nutzung: Docker-Image taggen mit Commit-SHA:

docker-build.ymlYAML

1build-image:
stage: build
script:
  - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
  - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

11) Komplettes Beispiel

Zum Abschluss eine realistische Pipeline mit allen wichtigen Konzepten – Build, Test, Docker-Image, Deploy auf zwei Umgebungen:

.gitlab-ci.ymlYAML

1stages:
- build
- test
- package
- deploy
6
7variables:
NODE_VERSION: "20"
9
10build-app:
stage: build
image: node:$NODE_VERSION-alpine
cache:
  key: $CI_COMMIT_REF_SLUG
  paths: [node_modules/]
script:
  - npm ci
  - npm run build
artifacts:
  paths: [dist/]
21
22unit-test:
stage: test
image: node:$NODE_VERSION-alpine
script: npm test -- --coverage
coverage: '/All files.*?\s+(\d+\.?\d*)/'
27
28build-image:
stage: package
image: docker:24
services: [docker:24-dind]
script:
  - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
  - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
35
36deploy-staging:
stage: deploy
script: ./deploy.sh staging $CI_COMMIT_SHORT_SHA
environment: staging
rules:
  - if: '$CI_COMMIT_BRANCH == "main"'
42
43deploy-production:
stage: deploy
script: ./deploy.sh production $CI_COMMIT_TAG
environment: production
rules:
  - if: '$CI_COMMIT_TAG'
    when: manual

Diese Pipeline deckt vier Stages ab: Build mit Cache, Test mit Coverage-Extraction, Docker-Image-Build mit Docker-in-Docker, Deploy auf Staging automatisch bei main-Push, Deploy auf Production manuell bei Tag. Realistisch für ein mittleres Web-Projekt.

12) Praktische Tipps

Aus der Praxis: kleine Tricks die viel Zeit sparen können:

CI Lint-Tool: GitLab hat unter Build → Pipeline Editor einen Live-Validator. Tippfehler sofort erkennen.
before_script: Code der vor jedem Job läuft (auf Job- oder globaler Ebene). Spart Duplikation.
YAML Anchors (& und *): für sich wiederholende Konfiguration – pure YAML-Feature, sehr mächtig.
Manual Approvals mit when: manual: Mensch entscheidet bevor heikle Aktionen laufen
Allow Failure: allow_failure: true für Jobs deren Fehlschlag nicht die Pipeline brechen soll (Linting, Optional-Features)
Trigger: ein Job kann andere Pipelines triggern – Multi-Repo-Workflows möglich
Parent-Child Pipelines: dynamisch generierte Sub-Pipelines für komplexe Monorepos
Merge Request Pipelines: laufen nicht auf Branch sondern auf gemergedem Code – findet Konflikte vor Merge

Zusammenfassung

GitLab CI/CD ist die zweite große CI/CD-Plattform am Markt, besonders stark bei Enterprise und Self-Hosting. Pipeline in .gitlab-ci.yml mit globalen stages und Jobs als Top-Level-Keys. Jeder Job läuft in einem Docker-image. Runner-Typen: Shared (gitlab.com), Group, Project, Self-Hosted mit Docker-Executor. Variablen auf mehreren Ebenen, Secrets via GitLab-UI mit Protected/Masked. Rules (modern) statt only/except (alt) für Conditional Execution. Artifacts für Job-zu-Job-Output (30 Tage), Cache für persistente Dependencies. Includes und Templates für Wiederverwendung – GitLab liefert Security-Templates frei Haus. Environments als first-class Citizens mit Deploy-History und Rollback. Auto DevOps für vorgefertigte Pipelines ohne YAML. Vordefinierte Variablen wie $CI_COMMIT_SHORT_SHA sehr nützlich. Wer GitHub Actions kann, lernt GitLab CI in einem Tag.