GitLab Pipelines · Workshop Lektion 10 / Environments

Environments & Deployments

Wohin deployt wird, manuelle Freigaben – und GitLab Pages als greifbares Ziel.

Warum das zählt
Bisher endet die Pipeline beim Bauen. Jetzt schliesst sich der Kreis: Wir deployen. GitLab Environments machen sichtbar, welche Version wo läuft, und when: manual gibt dir den Finger auf dem Auslöser für Produktion. Als sichtbares Beispiel deployen wir die Coverage-Reports nach GitLab Pages.

Kurzer Rückruf

Was erzeugt eine Matrix mit 2 × 3 Werten?

Environment: ein benanntes Ziel

Das Keyword environment markiert einen Job als Deployment in eine benannte Umgebung. GitLab führt darüber Buch: In der UI siehst du unter Operate → Environments, welcher Commit gerade auf staging bzw. production läuft – inklusive Roll­back-Knopf. 

deploy-staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.tasks.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: deploy
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://tasks.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual          # Produktion nur auf Knopfdruck

when: manual macht aus dem Job einen Play-Button in der Pipeline – nichts geht nach Prod, bis ein Mensch klickt.

Greifbar: Deploy nach GitLab Pages

GitLab Pages hostet statische Dateien gratis. Die Regel: ein Job namens pages, dessen Artifact einen Ordner public/ enthält. Wir veröffentlichen den HTML-Coverage-Report: 

pages:
  stage: deploy
  script:
    - pip install -r requirements.txt pytest pytest-cov
    - pytest --cov=app --cov-report=html:public   # HTML-Report nach public/
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Nach dem Lauf ist der Report unter der Pages-URL deines Projekts erreichbar – sichtbares Ergebnis, das im Workshop immer zündet.

Dein Win Du hast die Pipeline vom ersten Lint bis zum echten Deploy geführt – mit manueller Freigabe für Produktion.

Besonderheiten & Stolperfallen

Pages: Job-Name und public sind Pflicht Der Job muss pages heissen und die Dateien müssen im Ordner public/ als Artifact liegen. Heisst der Ordner site/ oder der Job deploy-docs, passiert nichts.
Manuelle Jobs: blockierend oder nicht Ein when: manual-Job ist standardmässig nicht blockierend (die Pipeline gilt auch ohne Klick als erfolgreich). Soll Prod ein echtes Gate sein, kombiniere mit allow_failure: false – dann wartet die Pipeline auf die Freigabe.
Environments ermöglichen Rollback Weil GitLab jedes Deployment einer Umgebung zuordnet, kannst du in der UI auf einen früheren erfolgreichen Stand zurückrollen – ohne neuen Commit. Das ist der eigentliche Mehrwert gegenüber „einfach ein Deploy-Skript".
Dynamische Umgebungen pro Branch Mit environment: name: review/$CI_COMMIT_REF_SLUG bekommt jeder Feature-Branch eine eigene Review-Umgebung. Mächtig – aber bewusst einsetzen, sonst sammeln sich viele Umgebungen an.

Übung für Teilnehmende

Übung 1 · Fehler finden

Szenario: Ein Job deploy-docs legt HTML in site/ und nichts erscheint auf Pages. Zwei Fehler?

Lösung anzeigen

(1) Der Job muss pages heissen. (2) Der Output muss als Artifact im Ordner public/ liegen, nicht site/.

Übung 2 · Gate bauen

Aufgabe: Mach das Production-Deploy zu einem echten Gate, das die Pipeline blockiert, bis jemand freigibt.

Lösung anzeigen 
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual
      allow_failure: false

allow_failure: false macht den manuellen Job blockierend – die Pipeline wartet.

Übung 3 · Verstehen

Frage: Wozu die url: im environment-Block?

Lösung anzeigen

GitLab zeigt sie als anklickbaren „View deployment"-Link in MR und Environments-Ansicht – direkter Sprung zur laufenden Umgebung. Reine Bequemlichkeit, aber im Alltag sehr nützlich.

Kurz prüfen (aus dem Kopf)

Was macht when: manual mit einem Job?

Was braucht ein GitLab-Pages-Deploy zwingend?

Primärquelle zum Lesen GitLab Docs – Environments and deployments und GitLab Pages.
Frag deinen Teacher. Willst du Review-Apps pro Branch durchspielen? Sag Bescheid.
← Lektion 9 Lektion 11 · needs & DAG →