Was passiert, nachdem GitLab den Code heruntergeladen…

Nachdem GitLab den Code des Repositories in das Arbeitsverzeichnis heruntergeladen hat, beginnt die Ausführung der CI/CD-Pipeline, die in der Datei .gitlab-ci.yml definiert ist.

Analyse von .gitlab-ci.yml: GitLab Runner (oder GitLab selbst, wenn integrierte CI verwendet wird) liest die Konfiguration aus .gitlab-ci.yml. Diese Datei beschreibt die Phasen (stages) und Aufgaben (jobs) der Pipeline.
Initialisierung des Runners: Ein verfügbarer GitLab Runner wird zugewiesen, um die Pipeline auszuführen. Der Runner erhält Informationen über das Repository, den Commit, den Branch und die Konfiguration von .gitlab-ci.yml.
Erstellung der Ausführungsumgebung: Der Runner bereitet eine Umgebung vor, um die Aufgaben auszuführen. Dies kann sein:
- Virtuelle Maschine
- Container (Docker, Kubernetes)
- Dedizierter Server
- Shell
Ausführung der Phasen (stages): Die Pipeline wird sequenziell nach Phasen ausgeführt, die in .gitlab-ci.yml definiert sind. Aufgaben in einer Phase können parallel ausgeführt werden.
Ausführung der Aufgaben (jobs): Innerhalb jeder Phase werden die konfigurierten Aufgaben ausgeführt. Eine Aufgabe umfasst:
- Definition des Images oder Executors (Executor), falls nicht auf Pipeline- oder Variablenebene festgelegt.
- Klonen des Repositories (bereits von GitLab gemacht, aber der Runner kann git fetch oder git checkout für den benötigten Zustand ausführen).
- Wiederherstellung des Caches (falls konfiguriert), um den Build zu beschleunigen (z.B. Laden von Abhängigkeiten).
- Ausführung der Skripte (script): Der Hauptinhalt der Aufgabe, in dem Build-, Test-, Analyse- oder Deployment-Befehle ausgeführt werden.
- Hochladen von Artefakten (falls konfiguriert): Die Ergebnisse der Aufgabe (z.B. kompilierte Binärdateien, Berichte) werden für die spätere Verwendung oder den Download gespeichert.
- Speichern des Caches (falls konfiguriert), um zukünftige Ausführungen zu beschleunigen.
Statusbericht: Der Runner sendet den Status jeder Aufgabe (Erfolg, Fehler, Abbruch) zurück an GitLab. Der Benutzer sieht den Fortschritt und die Ergebnisse auf der Pipeline-Seite.
Wechsel zur nächsten Phase: Wenn alle Aufgaben in der aktuellen Phase erfolgreich abgeschlossen wurden (oder allow_failure konfiguriert ist), beginnt die nächste Phase. Wenn eine Aufgabe mit Fehler endet und allow_failure nicht gesetzt ist, wird die gesamte Pipeline abgebrochen.
Abschluss der Pipeline: Nach Abschluss aller Phasen (oder im Fehlerfall) endet die Pipeline. Ergebnisse und Artefakte sind über die GitLab-Weboberfläche zugänglich.

Beispiel für die Struktur der .gitlab-ci.yml:

// Definition der Phasen der Pipeline
stages:
  - build
  - test
  - deploy

// Build-Job in der build-Phase
build_job:
  stage: build
  image: docker:latest // Verwendung eines Docker-Images
  script:
    - echo "Baue die Anwendung..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA . // Baue das Docker-Image
  artifacts:
    paths:
      - myapp.tar // Speichere das Build-Artefakt

// Test-Job in der test-Phase
test_job:
  stage: test
  image: python:3.9 // Verwendung eines Python-Images
  script:
    - echo "Führe Tests aus..."
    - pip install -r requirements.txt
    - pytest // Führe Tests durch
  needs: ["build_job"] // Abhängigkeit vom erfolgreichen Abschluss von build_job

// Deploy-Job in der deploy-Phase
deploy_job:
  stage: deploy
  image: ubuntu:latest // Verwendung eines Ubuntu-Images
  script:
    - echo "Führe Deployment durch..."
    - echo "Hier kommt das Deployment-Skript..." // Deployment-Skript
  only: // Nur bei Commits auf master oder Tags ausführen
    - master
    - tags
  needs: ["test_job"] // Abhängigkeit vom erfolgreichen Abschluss von test_job

Das Herunterladen des Codes ist also nur der erste Schritt, gefolgt von einem komplexen automatisierten Build-, Test- und Deployment-Prozess, der auf der Konfiguration .gitlab-ci.yml basiert.

Was passiert, nachdem GitLab den Code heruntergeladen hat?