Tutorial: Erstellen einer komplexen GitLab CI/CD Pipeline

In diesem Tutorial wird Schritt für Schritt gezeigt, wie du eine zunehmend komplexere CI/CD-Pipeline in GitLab erstellst. Dabei wird eine einfache Pipeline konfiguriert, die im Laufe des Tutorials um zusätzliche Funktionalitäten erweitert wird. Am Ende hast du ein voll funktionsfähiges Projekt auf GitLab.com mit einer funktionierenden Dokumentationswebsite, die mit Docusaurus erstellt wurde.

24.1 Voraussetzungen

24.2 Schritte

24.2.1 Erstelle ein Projekt für Docusaurus

Zuerst musst du ein GitLab-Projekt erstellen, das die Docusaurus-Dateien enthält.

git clone git@gitlab.com:my-username/my-pipeline-tutorial-project.git pipeline-tutorial
cd pipeline-tutorial
npm init docusaurus

Der Docusaurus-Wizard erstellt die Seite im Verzeichnis website/. Bewege die Dateien in das Stammverzeichnis und lösche den Ordner website:

mv website/* .
rm -r website

Aktualisiere die Konfigurationsdatei docusaurus.config.js, um die URL und das Basisverzeichnis deines Projekts anzupassen.

24.2.2 Initiale CI/CD-Konfiguration

Erstelle eine einfache .gitlab-ci.yml Datei, um sicherzustellen, dass CI/CD aktiviert ist und die Runner verfügbar sind.

test-job:
  script:
    - echo "This is my first job!"
    - date

Füge diese Datei in das Stammverzeichnis des Projekts ein und committe die Änderungen. Die Pipeline startet automatisch und zeigt die Ergebnisse des Jobs im GitLab-Interface an.

24.2.3 Build-Job hinzufügen

Ein häufiges Szenario in CI/CD ist das Bauen des Projekts. Erstelle einen Build-Job für die Docusaurus-Website.

build-job:
  image: node
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - "build/"

Die Build-Dateien werden im Verzeichnis build/ gespeichert und als Artefakte verwendet.

24.2.4 Deploy-Job hinzufügen

stages:
  - build
  - deploy

build-job:
  stage: build
  image: node
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - "build/"

pages:
  stage: deploy
  script:
    - mv build/ public/
  artifacts:
    paths:
      - "public/"

GitLab Pages wird verwendet, um die statische Seite zu hosten. Nachdem die Pipeline abgeschlossen ist, kann die Website unter der URL deines GitLab-Pages-Projekts aufgerufen werden.

24.2.5 Test-Jobs hinzufügen

lint-markdown:
  stage: test
  image: node
  script:
    - npm install markdownlint-cli2 --global
    - markdownlint-cli2 "blog/**/*.md" "docs/**/*.md"
  allow_failure: true

test-html:
  stage: test
  image: node
  script:
    - npm install --save-dev htmlhint
    - npx htmlhint build/

Der Markdown-Linting-Job prüft die Formatierung der Markdown-Dateien, und der HTML-Linting-Job überprüft den erzeugten HTML-Code.

24.2.6 Verwendung von Merge-Request-Pipelines

Ein idealer Workflow beinhaltet das Arbeiten mit Feature-Branches und Merge Requests. Verwende Regeln, um sicherzustellen, dass der Deploy-Job nur für den Standard-Branch ausgeführt wird.

build-job:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

pages:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

24.2.7 Reduzieren von Duplikationen

Vermeide redundante Konfigurationen durch den Einsatz von extends und default. Füge eine standardisierte Regel ein, die von mehreren Jobs wiederverwendet wird.

default:
  image: node

.standard-rules:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

build-job:
  extends: .standard-rules
  stage: build
  script:
    - npm install
    - npm run build

pages:
  image: busybox
  stage: deploy
  script:
    - mv build/ public/

24 Tutorial: Erstellen einer komplexen GitLab CI/CD Pipeline