Environments

Ein Environment in GitHub bündelt Werte für eine bestimmte Zielumgebung (z. B. staging oder production), und kann Repository-Werte überschreiben.

Aufgabe 1: Environment staging anlegen

Ziel: Verstehen, wie unterschiedliche Zielumgebungen (z. B. Staging vs. Production) getrennt konfiguriert werden können.

Beschreibung:

1. Gehe zu Settings → Environments → New environment.
2. Nenne es staging.
3. Hinterlege dort andere Werte als im Repository, aber mit denselben Namen (API_KEY = workshop-secret-456, API_ENV_NAME = staging-environment).

Warum diese Werte?

Gleiche Namen wie in Block 3 sind hier absichtlich gewählt: GitHub überschreibt bei gleichem Namen automatisch die Repository-Werte durch die Environment-Werte, sobald der Job an das Environment gebunden ist.

Der Sinn der Aufgabe:

In echten Projekten läuft eine Anwendung fast nie nur in einer einzigen Konfiguration, es gibt typischerweise mindestens "Staging" (Testumgebung) und "Production" (echte Nutzer), oft mit unterschiedlichen Datenbanken, Keys oder Endpunkten. Diese Aufgabe bildet dieses reale Szenario nach und zeigt, wie man solche Umgebungen sauber voneinander trennt, ohne den Code selbst zu verändern.

Aufgabe 2: Job an das Environment binden

Ziel: Die Override-Wirkung eines Environments direkt im Pipeline-Ergebnis beobachten.

Beschreibung:

1. Ergänze in .github/workflows/ci.yml im Job api-tests die Zeile environment: staging.