Die .gitlab-ci.yml
-Datei ist das zentrale
Konfigurationselement für die Definition von CI/CD-Pipelines in GitLab.
Diese Datei, die im YAML-Format geschrieben ist, bestimmt die Phasen
(Stages), Jobs und die Abfolge von Aktionen, die in der Pipeline
ausgeführt werden. Die Flexibilität dieser Datei ermöglicht es
Entwicklern, einfache oder komplexe Workflows zu gestalten, um den
Entwicklungs- und Bereitstellungsprozess zu automatisieren.
.gitlab-ci.yml
-DateiEine typische .gitlab-ci.yml
-Datei besteht aus den
folgenden Hauptelementen:
Stages (Phasen): Stages definieren die
verschiedenen Schritte in der Pipeline und legen fest, in welcher
Reihenfolge die Jobs ausgeführt werden. Typische Stages sind
build
, test
, und deploy
. Alle
Jobs innerhalb einer Stage werden parallel ausgeführt, aber eine Stage
kann erst abgeschlossen werden, wenn alle Jobs in der vorherigen Stage
erfolgreich abgeschlossen wurden.
Beispiel:
stages:
- build
- test
- deploy
Jobs: Ein Job ist eine einzelne Aufgabe, die im
Rahmen einer Stage ausgeführt wird. Ein Job enthält mindestens den
Abschnitt script
, in dem die Befehle definiert sind, die
der Runner ausführen soll. Jeder Job kann in einer separaten Umgebung
ausgeführt werden, z. B. in einem Docker-Container.
Beispiel:
build-job:
stage: build
script:
- npm install
- npm run build
Scripts: Der script
-Abschnitt eines
Jobs definiert die Abfolge von Befehlen, die ausgeführt werden. Es
handelt sich dabei um eine Liste von Anweisungen, die in der jeweiligen
Umgebung des Jobs, z. B. einem Docker-Container, ausgeführt werden.
Diese Anweisungen laufen so, als wären sie direkt auf der Kommandozeile
eingegeben worden.
Beispiel:
script:
- echo "Building the project"
- npm install
- npm run build
Images (Docker-Images): Der Abschnitt
image
gibt das Docker-Image an, das für die Ausführung des
Jobs verwendet wird. Der GitLab Runner lädt das angegebene Image
herunter, startet es und führt die im script
-Abschnitt
definierten Befehle in diesem Container aus.
Beispiel:
build-job:
image: node:latest
script:
- npm install
- npm run build
Artifacts: Artefakte sind Dateien, die während eines Jobs erzeugt werden und für nachfolgende Jobs in der Pipeline gespeichert werden. Ein typisches Beispiel ist das Kompilieren von Code, bei dem die binären Dateien als Artefakte gespeichert werden, um sie in nachfolgenden Test- oder Deploy-Jobs zu verwenden.
Beispiel:
build-job:
script:
- npm run build
artifacts:
paths:
- dist/
Caching: Der cache
-Abschnitt
ermöglicht das Speichern von Abhängigkeiten oder Zwischenergebnissen,
die in mehreren Jobs wiederverwendet werden können. Dies verbessert die
Geschwindigkeit der Pipeline, da wiederkehrende Aufgaben wie das
Herunterladen von Abhängigkeiten nicht in jedem Job neu durchgeführt
werden müssen.
Beispiel:
cache:
paths:
- node_modules/
Variablen: Mit CI/CD-Variablen können bestimmte
Werte an Jobs übergeben werden, z. B. API-Schlüssel oder
Umgebungsvariablen. Diese Variablen können direkt in der
.gitlab-ci.yml
-Datei definiert werden oder im Projekt, der
Gruppe oder der Instanzkonfiguration festgelegt werden.
Beispiel:
variables:
NODE_ENV: production
Stages und Parallelität: Wie bereits erwähnt, sind Stages dazu da, eine klare Reihenfolge in der Ausführung von Jobs zu gewährleisten. Innerhalb einer Stage werden alle Jobs parallel ausgeführt, sofern genügend Runner verfügbar sind. Dies fördert eine effizientere Nutzung der Ressourcen.
Beispiel:
stages:
- build
- test
- deploy
Branch-basierte Jobs: Die only
- und
except
-Schlüsselwörter erlauben es, Jobs nur unter
bestimmten Bedingungen auszuführen. Diese Bedingungen können
beispielsweise branch-abhängig sein. Ein Job kann so konfiguriert
werden, dass er nur auf dem main
-Branch läuft oder
bestimmte Branches ausschließt.
Beispiel:
test-job:
stage: test
script:
- npm test
only:
- main
Deployment und Umgebungen: GitLab CI/CD
unterstützt das Deployment in verschiedene Umgebungen wie
staging
, production
oder benutzerdefinierte
Umgebungen. Der Abschnitt environment
in der
.gitlab-ci.yml
Datei legt fest, in welche Umgebung der Job
deployt wird.
Beispiel:
deploy-prod:
stage: deploy
script:
- echo "Deploying to production"
environment:
name: production
url: https://myapp.com
Trigger und Manuelle Jobs: Manchmal ist es
notwendig, Jobs manuell zu starten oder sie durch spezifische
Bedingungen auszulösen. Mit when: manual
kann ein Job so
konfiguriert werden, dass er nur nach manueller Bestätigung ausgeführt
wird.
Beispiel:
deploy-job:
stage: deploy
script:
- echo "Deploying application"
when: manual
Includes und Externes Laden von Konfigurationen:
Eine .gitlab-ci.yml
-Datei kann andere
CI/CD-Konfigurationsdateien einbinden. Dies ermöglicht die
Wiederverwendung von Konfigurationen über mehrere Projekte hinweg oder
die Modularisierung komplexer Pipelines.
Beispiel:
include:
- local: 'path/to/config.yml'
- project: 'my-group/my-project'
file: '/templates/.gitlab-ci-template.yml'
Pipelines optimieren mit extends
und
default
: Um Redundanz in der
Pipeline-Konfiguration zu vermeiden, können extends
und
default
verwendet werden. Mit extends
können
Jobs Konfigurationen von anderen Jobs übernehmen. Mit
default
können bestimmte Einstellungen auf alle Jobs
angewendet werden, es sei denn, sie werden überschrieben.
Beispiel:
default:
image: node:latest
.base-job:
script:
- echo "Base job"
build-job:
extends: .base-job
stage: build
script:
- npm run build