Deploy to Abgabe

Zielvorstellung

Studierende gegen ihren Code per Pull-/Merge-Request ab. Dies triggert eine CI-Pipeline, die einerseits inhaltliche Richtigkeit prüft (Tests) und andererseits Metriken zum Code-Style etc. erhebt. Daraus resultieren dann Punkte für das jeweilige Team.

Zu beachten: Datenschutz!

• Github als Angebot, interner Gitlab als Fallback (Pflicht)
• "Welt" sollte die Lösungen der Studis und Ergebnisse der CI-Pipeline nicht sehen können
• Studis sollte die Lösungen der anderen Teams und deren Ergebnisse der CI-Pipeline nicht sehen können
• Auf GH sollte keine Punkte/Noten berechnet werden

Ideen (Ablauf)

• Das Vorgaberepo wird als private Kopie für jedes Studi-Team durch die TA bereitgestellt (keinen Fork, da dieser wieder public ist -- stattdessen manuelles Anlegen der Repos und Pushen des Vorgabe-Codes)
  • TA sind Admin, Studis bekommen nur Developer-Rechte (können nur Feature-Branches und PR/MR aufmachen)
• Die CI-Pipelines sind im Vorgaberepo konfiguriert und damit in der Team-Kopie verfügbar und durch die Studi-Teams aktivierbar
• Pull-/Merge-Requests gehen gegen die Master-Branches der Team-Repos => Studis bekommen unmittelbares Feedback in ihrem eigenen Repo
  • Falls möglich: Feedback durch TA in den Pull-/Merge-Requests(?)
• Bei Deadline: Pull-/Merge-Requests werden von TA "akzeptiert" (gemergt), dabei läuft noch einmal die CI-Pipeline
• Lokal: Skript, welches die Ergebnisse der CI-Pipelines aus den Team-Repos extrahiert und lokal als CSV/JSON/XML ablegt (relevante Aspekte, anonyme User-Namen)
  • Punkte können auch manuell von TA in Excel-Tabelle übertragen werden
  • Ergebnisse (Log, Artefakte) bleiben im PR/MR erhalten => Speicherdauer hochdrehen im GH/GL
  • Tabelle/Maßstab für Übersetzung Tests+Metriken => Punkte für TA
• Lokal: Tabelle mit Übersetzung von anonymen User-Namen zu Studi (erst bei Anmeldung der Studis zur Prüfung?)

Diese Lösung funktioniert sowohl mit Github-Repos als Repos im internen Gitlab und (mit Einschränkungen) sogar mit einer Abgabe über ILIAS.

Zur Not kann man zur Bewertung auch die Repos lokal clonen, die CI-Scripte lokal laufen lassen und damit die Bewertung komplett lokal erzeugen.

Technisch

• Vorgaben von JUnit-Testsuiten

  • (+) etablierter Mechanismus nutzbar
  • (-) detaillierte Vorgabe von Schnittstellen, schränkt Kreaktivität teilweise sehr ein

• Vorgaben von Input-/Output-Paaren

  • (+) einfacher Mechanismus zum Prüfen von innerem Verhalten ohne Vorgabe von Schnittstellen o.ä.
  • (-) Mechanismus muss selbst aufgebaut werden
  • (-) Studis müssen ggf. Build-Skripte mitliefern

  => Framework von Nelson oder "code freak" (paper, github)

• Erheben von Metriken mit Checkstyle, PMD und anderen Tools (vgl. Dietz et al.: "Teaching Clean Code", http://ceur-ws.org/Vol-2066/isee2018paper06.pdf)