Implementierung des dritten Sprints
Im dritten Sprint wurde der robuste MMP aus Sprint 2 zum MLP veredelt. Im Zentrum standen kein neuer Funktionsumfang, sondern das “Loveable” – also ein angenehmeres Nutzungserlebnis – sowie die saubere Übergabe an den Betrieb. Wie schon in den vorherigen Sprints wurde dafür das bestehende Skript source/main.sh gezielt erweitert; die Architekturvorgabe “Monolith mit interner Modularisierung” bleibt damit unangetastet.
Die zu implementierenden Inhalte entsprachen den beiden verbleibenden User Stories des Sprint-Backlogs:
- US.9: Visuelle Fortschrittsanzeige
- US.11: Betriebsdokumentation & Übergabe
Neu hinzugekommen sind die beiden Funktionen spinner und run_with_spinner. Die bestehenden Funktionen generate_userdata, deploy_instance und print_summary wurden so angepasst, dass sie während der Wartezeiten Statusmeldungen und einen Spinner anzeigen.
US.9 - Visuelle Fortschrittsanzeige
Ziel der User Story
Der Nutzer soll während der Provisionierung in AWS eine visuelle Fortschrittsanzeige (Spinner/ProgressBar) sowie verständliche Statusmeldungen erhalten, sodass das Tool wertiger wirkt und das Warten nicht wie ein Absturz aussieht.
Implementierung
- Die neue Funktion
spinner()zeigt einen rotierenden Spinner (|/-\) an, solange ein im Hintergrund laufender Prozess (übergeben via PID) aktiv ist. Sobald der Prozess endet, wird die Zeile mit einem Häkchen[✓]sauber abgeschlossen. Übertput civis/tput cnormwird der Cursor während der Animation aus- und danach wieder eingeblendet. - Die Hilfsfunktion
run_with_spinner()kapselt das Muster “Befehl im Hintergrund starten, Spinner anzeigen, Exit-Code und Ausgabe einsammeln”. Die kombinierte Ausgabe landet in der globalen VariableSPINNER_OUTPUT, der ursprüngliche Exit-Code des Befehls wird unverändert zurückgegeben. Dadurch bleibt die bestehende Fehlerbehandlung aus Sprint 2 (inklusive derDryRunOperation-Logik) vollständig erhalten. - Die Statusmeldungen wurden an den drei wartezeit-relevanten Stellen ergänzt:
Generiere Template...ingenerate_userdata(),Sende Request an AWS...rund um denrun-instances-Aufruf indeploy_instance()sowieWarte auf Instanz-IP...während des IP-Pollings inprint_summary(). - Damit das Tooling auch in nicht-interaktiven Umgebungen (z. B. CI/Pipe) sauber bleibt, erkennt
spinner()über[[ -t 1 ]], ob eine echte Konsole vorliegt. Ist dies nicht der Fall, wird statt der Animation lediglich die Statusmeldung ausgegeben.
Beide Akzeptanzkriterien sind damit erfüllt: Während das Skript auf die AWS-API wartet, erscheint ein Spinner, und der Nutzer sieht durchgehend verständliche Statusmeldungen.
US.11 - Betriebsdokumentation & Übergabe
Ziel der User Story
Der ICT Server Supporter soll eine vollständige und strukturierte Betriebsdokumentation vorfinden, sodass er das System ohne langwierige Einführung eigenständig verwalten, warten und bei Fehlern entstören kann.
Implementierung
Die Betriebsdokumentation wurde nach demselben Konzept wie die restliche Projektdokumentation umgesetzt: Der eigentliche Inhalt liegt zentral als Include unter docs/_includes/betriebsdokumentation/content-betriebsdokumentation.md. Die Jekyll-Seite docs/betriebsdokumentation/betriebsdokumentation.md referenziert diesen Include lediglich, und die Stand-Alone-Datei userdocumentation.md im Repository-Root bindet denselben Include via ::include{...} ein. Dadurch existiert die Doku an einem zentralen, für das gesamte Support-Team zugänglichen Ort (Git-Repository), ohne dass Inhalte doppelt gepflegt werden müssen.
Inhaltlich deckt die Betriebsdokumentation die geforderten Kapitel ab:
- Struktur & Zugänglichkeit: Ablage im Git-Repository, durchgehend einheitliche Terminologie und eine Sprache, die kein implizites Vorwissen voraussetzt.
- Systemübersicht & Architektur: Ein Architektur-/Ablaufdiagramm (Mermaid) zeigt die Komponenten (Skript, Template, AWS-API, EC2) sowie die relevanten Abhängigkeiten und Ports.
- Daily Operations: Die Schritte zum Deployen von Prod-, Int- und Dev-Servern sind beschrieben, ebenso wo die Logfiles zu finden sind.
- Troubleshooting: Die drei häufigsten Fehlerszenarien sind als Runbooks inklusive Lösungsansätzen dokumentiert, und die Zuständigkeiten samt Eskalationspfad sind definiert.
Damit sind die Akzeptanzkriterien der User Story erfüllt: Die Dokumentation ist zentral abgelegt, strukturiert, verständlich und deckt Architektur, Normalbetrieb und Troubleshooting ab.
Zusammenfassung Sprint 3
Mit der Umsetzung von US.9 und US.11 wurde aus dem MMP ein abgerundetes MLP:
- Wertigeres Nutzungserlebnis durch Spinner und verständliche Statusmeldungen während der AWS-Wartezeiten
- Vollständige, strukturierte Betriebsdokumentation für die saubere Übergabe an den Betrieb
- Keine Verletzung der Architekturvorgabe: Alle Code-Erweiterungen erfolgten erneut als zusätzliche Funktionen innerhalb des bestehenden Monolithen
source/main.sh
Damit sind sämtliche für die Releases MVP, MMP und MLP vorgesehenen User Stories abgeschlossen.