30 Stages in GitLab CI

Stages sind ein zentrales Konzept in GitLab CI, da sie die Reihenfolge festlegen, in der Jobs ausgeführt werden. Jede Pipeline ist in verschiedene Stages unterteilt, und innerhalb jeder Stage können mehrere Jobs parallel ausgeführt werden. Erst wenn alle Jobs einer Stage erfolgreich abgeschlossen sind, wird die nächste Stage gestartet.

30.1 Definition und Verwendung von Stages

Mit dem stages-Keyword wird die Reihenfolge der Phasen in einer Pipeline definiert. Typischerweise hat eine Pipeline Phasen wie build, test, und deploy, die genau diese Schritte im Entwicklungsprozess widerspiegeln. Jede dieser Phasen besteht aus einem oder mehreren Jobs, die unabhängig voneinander in parallelen Runner-Umgebungen ausgeführt werden können.

Beispiel:

stages:
  - build
  - test
  - deploy

In diesem Beispiel besteht die Pipeline aus drei Stages: build, test und deploy. Die Jobs in der build-Stage werden zuerst ausgeführt. Sobald diese abgeschlossen sind, folgen die Jobs in der test-Stage, und schließlich die in der deploy-Stage.

30.2 Jobs zu Stages zuordnen

Jeder Job in der Pipeline muss einer Stage zugeordnet werden. Wenn keine Stage explizit für einen Job definiert wird, wird er automatisch der ersten Stage zugewiesen, die in der Pipeline definiert ist. Um einen Job einer spezifischen Stage zuzuweisen, verwendet man das stage-Keyword innerhalb des Job-Blocks.

Beispiel:

build_job:
  stage: build
  script:
    - echo "Building the project"

test_job:
  stage: test
  script:
    - echo "Running tests"

deploy_job:
  stage: deploy
  script:
    - echo "Deploying the project"

In diesem Beispiel haben wir drei Jobs: build_job, test_job und deploy_job. Jeder Job ist einer spezifischen Stage zugeordnet. Zuerst wird build_job in der build-Stage ausgeführt, danach test_job in der test-Stage, und schließlich deploy_job in der deploy-Stage.

30.3 Reihenfolge und Parallelität

Die Jobs innerhalb einer Stage werden parallel ausgeführt, wenn genügend Runner zur Verfügung stehen. Die Ausführung einer Stage beginnt jedoch erst, wenn alle Jobs der vorherigen Stage erfolgreich abgeschlossen wurden. Dies hilft, die Pipeline-Performance zu optimieren und sicherzustellen, dass bestimmte Schritte (wie Tests) nicht vorzeitig ausgeführt werden, bevor andere (wie der Build) abgeschlossen sind.

Weitere Informationen finden sich in der offiziellen GitLab-Dokumentation zu Stages.