Übung: Schlechte Pipeline reparieren #1

Open
opened 2026-11-02 11:56:02 +00:00 by trainer · 0 comments
Owner

Übung: Schlechte Pipeline reparieren

Branch: exercise/bad-pipeline · Schwierigkeit: einfach ·
Thema: CI/CD-Qualität

Ausgangslage

Die CI-Pipeline (Jenkinsfile) wurde „mal schnell" umgebaut. Sie läuft —
ist aber aus mehreren Gründen unbrauchbar und unsicher.

Aufgabe

  1. PR von exercise/bad-pipeline auf main öffnen.
  2. Alle Probleme im Jenkinsfile finden und in einem Kommentar
    auflisten. Mindestens diese sind drin:
    • Tests werden übersprungen — der Build gibt keine Qualitätsgarantie
    • Zugangsdaten im Klartext (admin:admin, Datenbank-Passwort)
    • SonarQ ohne TLS, ohne Token, mit Debug-Output (-X) —
      Secret-Leckage im Log
    • npm install --force statt reproduzierbarer Installation
      (Lockfile ignoriert; das Projekt nutzt Bun)
    • Kein Lint, kein Test-Report, kein Security-Scan
    • Kein Build-Agent-Pin (node('any')), keine Optionen
      (Timestamps, Timeout, Concurrent-Blocking)
    • Ein „Deploy"-Schritt mit Produktions-Zugangsdaten in einer CI-Pipeline
  3. Fix: Pipeline an die Referenz auf main anlehnen
    (Lint → Test → Frontend → Trivy → SonarQ, Token über
    Jenkins-Credentials, keine Secrets im Code).
  4. Review-Agenten laufen lassen, Findings abarbeiten. Merge erst nach
    Freigabe durch den Trainer.

Erwartetes Learning

  • Woran man eine Quick-and-Dirty-Pipeline erkennt
  • Secret-Handling in CI: Credentials-Store statt Klartext
  • Wie Review-Agenten Pipeline-Qualität systematisch prüfen
# Übung: Schlechte Pipeline reparieren **Branch:** `exercise/bad-pipeline` · **Schwierigkeit:** einfach · **Thema:** CI/CD-Qualität ## Ausgangslage Die CI-Pipeline (`Jenkinsfile`) wurde „mal schnell" umgebaut. Sie läuft — ist aber aus mehreren Gründen unbrauchbar und unsicher. ## Aufgabe 1. PR von `exercise/bad-pipeline` auf `main` öffnen. 2. Alle Probleme im `Jenkinsfile` finden und in einem Kommentar auflisten. Mindestens diese sind drin: - Tests werden übersprungen — der Build gibt keine Qualitätsgarantie - Zugangsdaten im Klartext (`admin:admin`, Datenbank-Passwort) - SonarQ ohne TLS, ohne Token, mit Debug-Output (`-X`) — Secret-Leckage im Log - `npm install --force` statt reproduzierbarer Installation (Lockfile ignoriert; das Projekt nutzt Bun) - Kein Lint, kein Test-Report, kein Security-Scan - Kein Build-Agent-Pin (`node('any')`), keine Optionen (Timestamps, Timeout, Concurrent-Blocking) - Ein „Deploy"-Schritt mit Produktions-Zugangsdaten in einer CI-Pipeline 3. Fix: Pipeline an die Referenz auf `main` anlehnen (Lint → Test → Frontend → Trivy → SonarQ, Token über Jenkins-Credentials, keine Secrets im Code). 4. Review-Agenten laufen lassen, Findings abarbeiten. Merge erst nach Freigabe durch den Trainer. ## Erwartetes Learning - Woran man eine Quick-and-Dirty-Pipeline erkennt - Secret-Handling in CI: Credentials-Store statt Klartext - Wie Review-Agenten Pipeline-Qualität systematisch prüfen
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
lab/full-stack-fastapi#1
No description provided.