lab/spring-petclinic
Watch
2
0
Fork
You've already forked spring-petclinic
 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions 3

Übung: Schlechte Pipeline reparieren #1

New issue
Open
opened 2026-11-02 11:56:06 +00:00 by trainer · 0 comments
trainer commented 2026-11-02 11:56:06 +00:00
Owner
Copy link

Übung: Schlechte Pipeline reparieren

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

Ausgangslage

Die CI-Pipeline (Jenkinsfile) wurde „mal schnell" umgebaut und sieht
jetzt deutlich schlechter aus als die Referenz-Pipeline auf main.
Erster Eindruck: sie „läuft" — aber sie ist 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 (-DskipTests) — Build gibt keine
      Qualitätsgarantie
    • Credentials (admin:admin) im Klartext im Pipeline-Code
    • SonarQ-Call ohne TLS, ohne echtes Token, mit Debug-Output (-X)
      — Secret-Leckage-Risiko im Log
    • Kein dediziertes Test-Stage, kein Test-Report (JUnit)
    • Kein Build-Agent-Pin (node('any')), keine Build-Optionen
      (Timestamps, Concurrent-Blocking)
  3. Fix: Pipeline an die Referenz auf main anlehnen (Stages
    Build → Test → SonarQ, Token über Jenkins-Credentials, keine
    Secrets im Code).
  4. Review-Agenten laufen lassen, Findings abarbeiten, PR fertig
    reviewen. Merge erst nach Freigabe durch den Trainer.

Erwartetes Learning

  • Was eine Referenz-Pipeline leistet (deterministisch, sekurig,
    mit Test-Report) und 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 und sieht jetzt deutlich schlechter aus als die Referenz-Pipeline auf `main`. Erster Eindruck: sie „läuft" — aber sie ist 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 (`-DskipTests`) — Build gibt keine Qualitätsgarantie - Credentials (`admin:admin`) im Klartext im Pipeline-Code - SonarQ-Call ohne TLS, ohne echtes Token, mit Debug-Output (`-X`) — Secret-Leckage-Risiko im Log - Kein dediziertes Test-Stage, kein Test-Report (JUnit) - Kein Build-Agent-Pin (`node('any')`), keine Build-Optionen (Timestamps, Concurrent-Blocking) 3. Fix: Pipeline an die Referenz auf `main` anlehnen (Stages Build → Test → SonarQ, Token über Jenkins-Credentials, keine Secrets im Code). 4. Review-Agenten laufen lassen, Findings abarbeiten, PR fertig reviewen. Merge erst nach Freigabe durch den Trainer. ## Erwartetes Learning - Was eine Referenz-Pipeline leistet (deterministisch, sekurig, mit Test-Report) und 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 Branch/Tag specified
Branches Tags
main
exercise/bad-pipeline
exercise/sql-injection
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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/spring-petclinic#1
No description provided.