22 .gitlab-ci.yml: Aufbau und Struktur

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.

22.1 Grundlegende Struktur einer .gitlab-ci.yml-Datei

Eine typische .gitlab-ci.yml-Datei besteht aus den folgenden Hauptelementen:

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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/
  6. 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/
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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'
  13. 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