Einführung in GitLab CI/CD

Was passiert zwischen git push und dem fertigen Deployment? Dieses Modul klärt die Begriffe Continuous Integration, Continuous Delivery und Continuous Deployment anhand konkreter Beispiele. Sie legen Ihr erstes GitLab-Projekt an, machen sich mit Merge Requests, der Container Registry und der Pipeline-Ansicht vertraut. Am Ende wissen Sie, wo CI/CD in den Entwicklungsalltag passt und wie GitLab die einzelnen Schritte abbildet.

Sie schreiben Ihre erste .gitlab-ci.yml von Grund auf: Jobs, Stages und Scripts bilden das Grundgerüst. Sie definieren ein image, nutzen before_script für Setup-Schritte und beobachten live, wie GitLab die Pipeline ausführt. Danach erweitern Sie die Pipeline um einen Test-Job und sehen, wie GitLab bei einem Fehler die Ausführung stoppt.

Nicht jeder Job soll bei jedem Push laufen. Sie arbeiten mit CI/CD Variables (project, group, instance), schützen Secrets über masked und protected Flags und steuern die Pipeline-Logik mit rules. Warum sind die alten only/except-Keywords und die workflow:rules-Templates deprecated? Sie sehen den Unterschied in der Praxis und bauen eine Pipeline, die je nach Branch und Merge-Request-Status unterschiedliche Jobs ausführt.

Wo laufen Ihre Jobs eigentlich? Sie lernen den Unterschied zwischen Shared, Group und Project Runnern, konfigurieren Tags zur gezielten Job-Zuweisung und vergleichen die Executors Shell, Docker und Kubernetes. Im Hands-on registrieren Sie einen eigenen Runner. Dann sehen Sie, wie der Kubernetes Executor bei Bedarf automatisch Pods hochfährt und nach dem Job wieder abbaut: Autoscaling ohne manuelles Eingreifen.

Artifacts und Cache klingen ähnlich, lösen aber unterschiedliche Probleme. Sie speichern Build-Ergebnisse als Artifacts und machen sie für nachfolgende Stages verfügbar. Dann richten Sie einen Cache für node_modules oder Maven-Repositories ein, damit Pipelines nicht bei jedem Lauf alle Dependencies neu laden. Mit dem needs-Keyword brechen Sie die starre Stage-Reihenfolge auf und lassen unabhängige Jobs parallel laufen.

Sie bauen ein Docker Image direkt in der Pipeline und pushen es in die GitLab Container Registry. Dabei vergleichen Sie zwei Ansätze: Docker-in-Docker (dind) und den Socket-Mount. Wann ist welcher Ansatz sinnvoll, und welche Sicherheitsimplikationen hat privileged mode? Am Ende taggen Sie Images automatisch mit der Git-Referenz und nutzen Multi-Stage Builds für schlanke Produktions-Images.

Ein Image ohne Scan ist ein Risiko. Sie integrieren Trivy als Job in Ihre Pipeline und lassen es automatisch nach CVEs in Base Images und Dependencies suchen. Dann aktivieren Sie GitLabs eingebautes SAST (Static Application Security Testing) und sehen die Ergebnisse direkt im Merge Request. Sie definieren Schwellenwerte, ab denen die Pipeline blockiert, und entscheiden so früh im Prozess, ob ein Build produktionsreif ist.

Gleiche Pipeline-Logik in zehn Projekten pflegen? Das skaliert nicht. Sie arbeiten mit include und extends, um Jobs zentral zu definieren. Dann gehen Sie einen Schritt weiter: Mit dem CI/CD Component Catalog veröffentlichen Sie wiederverwendbare Pipeline-Bausteine mit versionierten Inputs, die andere Teams direkt einbinden. Sie bauen eine eigene Component, publizieren sie im Catalog und binden sie in ein zweites Projekt ein.

Code, der nur lokal funktioniert, bringt nichts. Sie konfigurieren Environments (staging, production) mit eigenen Variablen und Schutzregeln. Dann richten Sie ein Deployment ein, das bei jedem Merge in main automatisch ausrollt. Das Highlight: Review Apps, die für jeden Merge Request eine eigene Vorschau-Umgebung hochfahren und nach dem Merge wieder abbauen. So sieht jeder Reviewer die Änderungen live.

Pipelines scheitern, und dann zählt Geschwindigkeit. Sie nutzen den CI Lint zur Syntax-Prüfung vor dem Push, aktivieren debug logging für detaillierte Ausgaben und analysieren typische Fehlerbilder (Runner-Timeout, Image-Pull-Fehler, Permission-Probleme). Zum Abschluss: eine Checkliste mit Best Practices für den Alltag, darunter interruptible Jobs, Job-Token-Permissions nach dem Least-Privilege-Prinzip und die Strukturierung großer Pipelines mit Parent-Child Pipelines.