Sprint 2 - Implementierung | TBZ-ITCNE26-Semesterarbeit1

Implementierung des zweiten Sprints

Im zweiten Sprint wurde der funktionale MVP-Kern aus Sprint 1 zu einem robusten und benutzerfreundlichen MMP ausgebaut. Statt neuer Dateien wurde das bestehende Skript source/main.sh gezielt erweitert und refactored. Damit bleibt die im Architekturteil definierte Vorgabe “Monolith mit interner Modularisierung” erhalten: Jede neue Fähigkeit wurde als eigene, klar benannte Funktion ergänzt.

Die zu implementierenden Inhalte entsprachen den fünf User Stories des Sprint-Backlogs:

US.5: Fehlerbehandlung & Validierung
US.6: Output-Zusammenfassung
US.7: Interaktive Menü-Auswahl
US.8: Standardwerte (Defaults)
US.10: Human-Readable Inputs / Auswahl

Neu hinzugekommene Funktionen sind parse_args, check_dependencies, prompt_with_default, select_environment, load_environment_defaults, select_instance_type sowie print_summary. Die bestehenden Funktionen get_user_input und deploy_instance wurden entsprechend angepasst.

US.5 - Fehlerbehandlung & Validierung

Ziel der User Story

Der Nutzer soll eine saubere Fehlerbehandlung erhalten, falls AWS-Credentials fehlen oder Parameter falsch sind, damit das Skript nicht unkontrolliert abstürzt.

Implementierung

Die neue Funktion check_dependencies() prüft vorab mit command -v aws, ob die aws-CLI überhaupt installiert ist. Fehlt sie, bricht das Skript mit einer verständlichen Meldung und einem Link zur Installationsanleitung ab.
Der eigentliche API-Aufruf in deploy_instance() wird neu über if ! run_output=$(aws ec2 run-instances ... 2>&1) ausgeführt. Dadurch wird ein API-Fehler (z. B. falsche Region oder ungültige AMI) abgefangen, die Original-Fehlermeldung von AWS ausgegeben und ein Hinweis auf die häufigsten Ursachen ergänzt.
Über parse_args() steht neu ein optionaler Dry-Run-Modus (--dry-run) zur Verfügung. Dieser ruft aws ec2 run-instances --dry-run auf und wertet die von AWS bewusst zurückgegebene DryRunOperation-Meldung aus. So lassen sich die Parameter ohne Kostenfolge validieren.

Damit sind alle drei Akzeptanzkriterien erfüllt: CLI-Vorabprüfung, abgefangene API-Fehler und ein optionaler Dry-Run-Modus.

US.8 - Standardwerte (Defaults)

Ziel der User Story

Der Power-User soll passende Standardwerte vorgeschlagen bekommen, um den Prozess zu beschleunigen.

Implementierung

Die Hilfsfunktion prompt_with_default() zeigt den Default-Wert in Klammern an (z. B. AWS Region [us-east-1]:). Eine leere Eingabe (Enter) übernimmt den Default automatisch über die Bash-Konstruktion ${input:-$default_value}.

Die Defaults stammen aus der Datei /.admin/Standards_AbyssInc.md und werden in load_environment_defaults() je nach gewählter Umgebung gesetzt:

Prod: AMI ami-091138d0f0d41ff90, Type t2.small, Subnet subnet-019c94b4fbc0c5059, Securitygroup sg-0cf71c3fee7dd4c65
Int: AMI ami-091138d0f0d41ff90, Type t2.micro, Subnet subnet-0cfdbfffbca7e9597, Securitygroup sg-00e6f10c1cec51fb6
Dev: AMI ami-091138d0f0d41ff90, Type t2.nano, Subnet subnet-0591ccb2b9b1e4f29, Securitygroup sg-00f2d84fca11da2ca

Damit wird auch die Security Group neu pro Umgebung aus den Standards aufgelöst, statt wie bisher fix auf die Prod-Securitygroup gesetzt zu sein. Für die Umgebung Custom bleiben die Defaults bewusst leer, sodass alle Werte als Pflichtfeld manuell abgefragt werden.

Beide Akzeptanzkriterien sind damit erfüllt: Default-Anzeige in Klammern und Übernahme per Enter-Taste.

US.7 - Interaktive Menü-Auswahl

Ziel der User Story

Der Nutzer soll eine interaktive Auswahl statt reiner Texteingabe erhalten, sodass Tippfehler vermieden werden.

Implementierung

Für die Auswahl des Instance-Types wird neu das Bash-Builtin select verwendet (select_instance_type()). Statt Freitext wählt der User aus einer nummerierten Liste gängiger Instance-Types (t2.nano, t2.micro, t2.small, t3.micro, t3.small). Ungültige Eingaben werden in der Schleife abgefangen und führen zu einer erneuten Abfrage.

Da nur vorgegebene Listenwerte übernommen werden, sind Tippfehler systembedingt ausgeschlossen. Beide Akzeptanzkriterien sind erfüllt.

US.10 - Human-Readable Inputs / Auswahl

Ziel der User Story

Der 2nd Level Supporter soll eine Human-Readable Auswahl von Werten erhalten, sodass keine Liste mit IDs nötig ist, um das Produkt zu verwenden.

Implementierung

Die Funktion select_environment() bietet eine verständliche Auswahl der Ziel-Umgebung an: Produktion (Prod), Integration (Int), Entwicklung (Dev) und Custom (manuelle Eingabe). Der User muss damit keine AMI- oder Subnet-IDs auswendig kennen, sondern wählt seine Umgebung im Klartext aus. Die zugehörigen technischen Werte werden anschliessend über load_environment_defaults() automatisch hinterlegt.

Zusätzlich werden die Instanzen beim Deployment über die AWS-Tags Name und Environment ausgezeichnet (--tag-specifications). Dadurch sind die deployten EC2-Instanzen auch in der AWS-Konsole Human-Readable den korrekten Umgebungen zugeordnet.

Die Akzeptanzkriterien (korrekt hinterlegte Tags, Nutzung der Tags beim Deployment, verständliche Auswahl-Optionen) sind damit erfüllt.

US.6 - Output-Zusammenfassung

Ziel der User Story

Der Admin soll nach dem Deployment die Instanz-ID und die IP-Adresse angezeigt bekommen, um sofort weiterarbeiten zu können.

Implementierung

Die neue Funktion print_summary() wird nach einem erfolgreichen (nicht-Dry-Run) Deployment aufgerufen und gibt aus:

die InstanceId aus dem run-instances-Aufruf
die öffentliche (public) IP-Adresse, abgefragt via aws ec2 describe-instances. Da die IP nicht sofort verfügbar ist, wird in einer kurzen Schleife (max. 5 Versuche) gepollt, bis ein gültiger Wert vorliegt.
einen direkten Deep-Link zur AWS-Konsole für die neue Instanz (https://<region>.console.aws.amazon.com/ec2/home?region=<region>#InstanceDetails:instanceId=<id>)

Alle drei Akzeptanzkriterien sind damit erfüllt.

Zusammenfassung Sprint 2

Mit der Umsetzung von US.5 bis US.10 wurde aus dem MVP ein robuster, endbenutzertauglicher MMP:

Fehlertoleranz durch CLI-Prüfung, abgefangene API-Fehler und Dry-Run-Modus
Beschleunigte Bedienung durch umgebungsbasierte Standardwerte
Vermeidung von Tippfehlern durch Auswahlmenüs
Verständliche, Human-Readable Bedienung ohne ID-Wissen
Aussagekräftige Output-Zusammenfassung nach dem Deployment

Die Architekturvorgabe wurde eingehalten: Alle Erweiterungen erfolgten als zusätzliche Funktionen innerhalb des bestehenden Monolithen source/main.sh.