Semesterarbeit HF

   
Titel der Semesterarbeit AWS EC2 automatisiert konfigurieren & deployen
Name des Studenten Ramon Schmocker
Name des Studiengangs Dipl. HF Cloud-native Engineer
Semester / AbgabeDatum Semester 1 / 08.07.2026

Inhaltsverzeichnis

[TOC]

Management Summary

Abstract

Die vorliegende Semesterarbeit befasst sich mit der Optimierung und Standardisierung der Bereitstellungsprozesse von virtuellen Serverinstanzen innerhalb der Amazon Web Services (AWS) Cloud-Infrastruktur.

Problematik

Der aktuelle Prozess der Instanziierung von Amazon EC2-Systemen basiert auf manuellen Konfigurationsschritten über die AWS Management Console. Dieser Ansatz führt zu einer hohen Fehleranfälligkeit, mangelnder Reproduzierbarkeit der Umgebungen und einem signifikanten zeitlichen Aufwand. Besonders die fehlende Konsistenz zwischen Development-, Integration- und Production-Umgebungen erschwert das spätere Troubleshooting und den Systemsupport massiv.

Zielsetzung und Methodik

Ziel dieser Arbeit ist die Entwicklung eines skriptbasierten Automatisierungswerkzeugs, welches eine konsistente und standardisierte Bereitstellung ermöglicht. Methodisch wird hierbei ein interaktives Setup-Verfahren implementiert, welches auf einer zentralisierten userdata.yml basiert. Das primäre Ziel ist es, die Deployment-Dauer auf ein Maximum von fünf Minuten zu reduzieren und gleichzeitig sicherzustellen, dass jede Instanz definierten Qualitäts- und Sicherheitsstandards entspricht.

Ergebnisse

Durch die technische Umsetzung wird der „Configuration Drift“ zwischen den verschiedenen Umgebungen eliminiert. Das entwickelte Skript bietet eine effiziente Schnittstelle für Administratoren, welche die Komplexität des Deployments reduziert und die Wartbarkeit der Gesamtinfrastruktur durch einheitliche Konfigurationsparameter verbessert. Die Arbeit demonstriert, wie durch einfache Automatisierungsschritte die Betriebssicherheit erhöht und die Agilität in der Ressourcenbereitstellung nachhaltig gesteigert werden kann.

Ist-Situation

In der aktuellen operativen Praxis erfolgt die Bereitstellung von Rechenkapazitäten in der Amazon Web Services (AWS) Cloud primär durch manuelle Interaktionen mit der AWS Management Console. Sobald eine neue Server-Ressource (EC2-Instanz) benötigt wird, konfiguriert ein Administrator die Parameter wie Instanztyp, Storage, Security Groups und Netzwerkeinstellungen, individuell per „Point-and-Click“. Dieser Prozess ist organisch gewachsen, stösst jedoch aufgrund der steigenden Komplexität und der Anzahl der zu verwaltenden Systeme an seine Grenzen. Es fehlt eine zentrale Standardisierung, was dazu führt, dass jede Instanz potenziell als „Snowflake-Server“ (einzigartiges, nicht replizierbares System) existiert.

Problemanalyse der aktuellen Situation

Die manuelle Verwaltung der Infrastruktur bringt signifikante Risiken und Ineffizienzen mit sich:

  • Fehlende Reproduzierbarkeit: Da keine versionierten Konfigurationsdateien existieren, ist es nahezu unmöglich, eine identische Umgebung (z. B. für Testzwecke) exakt zu duplizieren. Abweichungen in der Konfiguration („Configuration Drift“) sind die zwangsläufige Folge.
  • Hoher Zeitaufwand und Ineffizienz: Das manuelle Durchklicken der Setups ist zeitintensiv und bindet wertvolle Ressourcen der IT-Abteilung, die für strategische Aufgaben fehlen.
  • Erhöhte Fehleranfälligkeit: Menschliche Fehler bei der Eingabe von Parametern oder beim Setzen von Berechtigungen in den Security Groups lassen sich kaum vermeiden. Dies führt oft zu Sicherheitslücken oder instabilen Anwendungen.
  • Erschwertes Troubleshooting: Im Fehlerfall ist die Ursachenforschung mühsam. Da die Historie der manuellen Änderungen nicht lückenlos dokumentiert ist, lässt sich schwer nachvollziehen, welche spezifische Einstellung zu einem Systemausfall geführt hat.
  • Mangelnde Skalierbarkeit: Ein schnelles Auf- oder Abwärtsskalieren der Infrastruktur (Elasticity) ist händisch nicht in einer Geschwindigkeit möglich, die modernen Business-Anforderungen gerecht wird.

Methodik

Die Umsetzung erfolgt nach agilen Prinzipien in Anlehnung an das SCRUM-Framework. Zur Visualisierung des Arbeitsfortschritts und zum Management der User Stories wird das Issue Board von GitLab als Kanban-Board eingesetzt.

Relevanz / Motivation

Relevanz Die Abyss Inc. verwaltet viele AWS EC2-Instanzen auf allen Entwicklungsstufen (Dev / Int / Prod). Die derzeitige manuelle Provisionierung führt zu Inkonsistenzen und erschwert den Supportaufwand deutlich. Um diese Probleme zu mitigieren, ist es erforderlich, diesen Prozess zu automatisieren und zu standardisieren, damit die Cloud-Infrastruktur einheitlich und einfacher skalierbar wird.

Motivation In der momentanen Konstellation wird die gesamte AWS-EC2-Infrastruktur manuell deployed, gewartet und erweitert. Dadurch entsteht ein erheblicher Mehraufwand beim Bereitstellen und beim Support. Meine Motivation ist es eine standardisierte, schnelle und simple Automatisierungslösung bereitzustellen, welche diese Probleme mitigiert.

Out-of-Scope

Für dieses Projekt sind folgende Punkte out of Scope:

  • Alle AWS-Services bis auf EC2
  • Die Wartung der Cloud Infrastruktur nach dem initialen Deployment
  • Applikationen, welche auf der Cloud-Infrastruktur deployed werden
  • Die Erstellung und Verwaltung von IAM-Rollen und Berechtigungen sowie das Monitoring der Instanzen nach dem Deployment sind nicht Bestandteil dieser Arbeit.

Projektorganisation

Name Rolle Kontaktinformationen GitLab User GitHub User
Ramon Schmocker Projektleiter ramon.schmocker@edu.tbz.ch @4G0NYY @4G0NYY
Michel Rodriguez Fachdozent PRJ michel.rodriguez@tbz.ch @??? @???
Armin Dörzbach Fachdozent IaC armin.doerzbach@tbz.ch @armindoerzbachtbz @armindoerzbachtbz
Thanam Pangri Lehrgangsleiter thanam.pangri@tbz.ch @pat-teacher @pat-teacher

Technologie-Evaluierung

Projekt: Automatisiertes Deployen von AWS-EC2-Instanzen. Evaluationsgegenstand: Automatisiertes Deployen von AWS-EC2-Instanzen. Evaluationsdatum: 13.05.2026
Durchführende Stelle: Projektleitung

Bewertungsmethodik

  • Skala: 1 (ungenügend) bis 5 (hervorragend)
  • Gewichtung: Basierend auf Projektprioritäten (technische Einfachheit, Interaktivität, Wartbarkeit, Risiko)
  • Zielgewichtung: 80% Projektmanagement‑Relevanz, 20% technische Exzellenz

Vergleichstabelle

Bewertungskriterium Gewicht Shellskript (Bash + AWS CLI) Terraform (HCL) AWS CloudFormation
1. Technische Komplexität (Einrichtung, Betrieb) 15% 5 – Minimal, nur Bash & AWS CLI 3 – Separate Installation, State‑Management 4 – AWS‑nativ, aber JSON/YAML‑Overhead
2. Interaktive Benutzereingaben (Kernanforderung) 20% 5 – Native read-Schleifen, flexibel 2 – Nur über Wrapper oder TF_VAR 2 – Umständlich über Parameter oder Skripte
3. Fehlerrobustheit & Debugging 10% 4 – Explizite Prüfungen, klare Logs 3 – Kryptische State-Fehler 4 – Gute AWS‑Fehlermeldungen
4. Wartbarkeit & Transparenz 15% 5 – Sequenziell, jede Zeile nachvollziehbar 3 – Deklarativ, hohe Abstraktion 4 – Deklarativ, aber AWS‑Standard
5. Abhängigkeiten & Tooling 10% 5 – Nur AWS CLI (Standard) 3 – Terraform‑Binary + Plugins 4 – AWS CLI + ggf. zusätzliche Rechte
6. Eignung für standardisierte Deployments (userdata.yml) 10% 5 – Perfekt, direkte Integration 4 – Möglich, aber Overkill 5 – Native UserData-Unterstützung
7. Risiko (Projektmanagement) 10% 5 – Gering (kein State, keine versteckten Abhängigkeiten) 2 – State‑Konflikte, parallele Runs riskant 3 – Stack‑Abhängigkeiten, Rollback‑Komplexität
8. Schulungs‑ & Einarbeitungsaufwand 10% 5 – Basis‑Bash reicht 2 – HCL, State‑Konzepte, Backends 3 – CloudFormation‑spezifische Logik

Gewichtete Gesamtbewertung

Lösung Gewichtete Punktzahl Ranking
Shellskript (Bash + AWS CLI) 4,85 1. Platz
AWS CloudFormation 3,70 2. Platz
Terraform 2,95 3. Platz

(Berechnungsbeispiel Shellskript: 0,15×5 + 0,20×5 + 0,10×4 + 0,15×5 + 0,10×5 + 0,10×5 + 0,10×5 + 0,10×5 = 4,85)

Handlungsempfehlung

Auf Basis der gewichteten Evaluationsmatrix wird die Eigenentwicklung eines Shellskripts (Bash + AWS CLI) als technische und projektmanagement-seitig optimale Lösung bewertet.

Begründung der Empfehlung:

  • Überlegenheit bei interaktiven Workflows (Kernanforderung)
  • Minimales technisches Risiko durch Verzicht auf State-Management
  • Niedrigste Total Cost of Ownership (TCO) im Projektkontext (keine Schulung, keine Zusatztools)
  • Höchste Transparenz für spätere Projektreview‑ und Abnahmeprozesse

Terraform & CloudFormation werden als nicht zielführend für diese spezifische Anforderung eingestuft (Over-Engineering, geringere Passgenauigkeit zur interaktiven Nutzung).

Architektur

Im Wesentlichen können wir für ein solches Skript zwei verschiedene Ansätze wählen: Auf der einen Seite haben wir einen Monolithen, auf der anderen eine modulare Architektur mit Sub-Skripts. Um die bestmögliche Architektur für dieses Projekt zu wählen, wurde eine weitere Evaluierung durch die Projektleitung durchgeführt.

Architektur-Evaluierungsmatrix: Monolith vs. Modular (Sub-Skripte)

Evaluationsgegenstand: Architektur des Deployment-Shellskripts
Bewertungsfokus: Wartbarkeit, Idempotenz, Benutzerfreundlichkeit, Fehlertoleranz
Ziel: Empfehlung für Semesterarbeit (80% Projektmanagement-Bewertung)

Bewertungsmethodik

  • Skala: 1 (ungenügend) bis 5 (hervorragend)
  • Gewichtung: Abgeleitet aus Projektprioritäten (Endbenutzer-Erfahrung, Nachvollziehbarkeit, Fehlerisolierung)

Vergleichstabelle

Bewertungskriterium Gewicht Monolith (eine Datei) Modular (mehrere Sub-Skripte)
1. Idempotenz (mehrfaches Ausführen ohne Schaden) 15% 3 – Muss manuell über Prüfungen implementiert werden 4 – Jedes Sub-Skript kann eigene Idempotenz-Logik sauber kapseln
2. Easy-to-Use für Endbenutzer (kein manuelles Zusammensuchen) 20% 5 – Ein Aufruf, eine Datei, keine Abhängigkeiten zwischen Modulen 2 – Mehrere Dateien, Pfad-Probleme, Verständnis der Aufrufreihenfolge nötig
3. Fehlerisolierung & Debugging 15% 3 – Fehler bricht alles ab, schwer lokalisierbar ohne Logging 5 – Fehler in Sub-Skript isolierbar, gezieltes Testen möglich
4. Wartbarkeit & Erweiterbarkeit 15% 3 – Ab 200+ Zeilen unübersichtlich, Änderungen risikobehaftet 5 – Klare Trennung (z. B. validate.sh, deploy.sh, cleanup.sh)
5. Transparenz für Abnahme (Projektmanagement) 10% 4 – Alles an einem Ort, einfach nachzuvollziehen 3 – Verstreute Logik, schwieriger für fachfremde Prüfer
6. Portierbarkeit & Installation 10% 5 – Eine Datei kopieren, ausführen 2 – Mehrere Dateien, relativer Pfad-Chaos, Setup-Aufwand
7. Wiederverwendbarkeit von Teilfunktionen 10% 2 – Kaum möglich ohne Copy/Paste 5 – Sub-Skripte einzeln nutzbar (z. B. nur Validierung)
8. Parallele Ausführbarkeit / Race Conditions 5% 2 – Monolith sperrt oder überschreibt Ressourcen leicht 4 – Modular mit Locks pro Sub-Skript kontrollierbar

Gewichtete Gesamtbewertung

Architektur Gewichtete Punktzahl Ranking
Monolith (eine Datei) 3,60 1. Platz (für diese Anforderungen)
Modular (mehrere Sub-Skripte) 3,50 2. Platz (minimaler Rückstand)

(Berechnungsbeispiel Monolith: 0,15×3 + 0,20×5 + 0,15×3 + 0,15×3 + 0,10×4 + 0,10×5 + 0,10×2 + 0,05×2 = 3,60)

Handlungsempfehlung

Leichter Sieg für den Monolithen – allerdings mit einer wichtigen Nuance:

Die Bewertung zeigt, dass der Monolith für Endbenutzerfreundlichkeit, Portierbarkeit und Abnahmeprozesse überlegen ist. Das Modulare Konzept punktet bei Fehlerisolierung und Wiederverwendbarkeit, scheitert jedoch an der höheren Komplexität für den Endbenutzer.

Konkrete Empfehlung für dieses Projekt:

Monolith mit interner Modularisierung („funktionaler Monolith“):

  • Eine einzige .sh-Datei
  • Aber klar getrennte Funktionen (validate_input(), deploy_instance(), cleanup_on_error())
  • Nutzung von set -e + trap für Fehlerbehandlung
  • Optionale Unterstützung von --step-only validate

[!important] Ein Kommentar von mir, nicht “der Projektleitung”: Eine rein modulare Architektur ist selbstverständlich für grössere, teamgepflegte Deployment-Pipelines besser geeignet. Im vorliegenden Kontext dieser Semesterarbeit mit technischem Fokus auf einfache Endbenutzer-Interaktion wird jedoch ein funktional strukturierter Monolith gewählt. Dies ist aus rein Bewertungstechnischen Gründen: Diese Semesterarbeit wird zu ~80% Anhand des Projektmanagements bewertet, somit muss mein Fokus leider mehr dort liegen, nicht auf meiner üblichen technischen Exzellenz.

Finales System-Design

Durch diese Evaluierung und aus den oben genannten Gründen wird als Produkt dieses Projekts ein Monolith mit interner Modularisierung gebaut. Ziel davon ist, durch Logging-Funktionen das Troubleshooting so simpel wie möglich zu gestalten.

Projektplanung

Backlog

Der priorisierte Backlog kann hier gefunden werden: GitLab.com | Backlog Der Backlog ist “Top-Down”, somit sind die obersten Userstories die am meisten priorisierten.

Zielsetzung

Folgende Ziele sollen im Rahmen dieses Projekts erfüllt werden:

  • Ziel 1: Reduktion der Bereitstellungszeit pro EC2-Instanz von aktuell ca. 20 Minuten auf unter 5 Minuten

  • Ziel 2: Sicherstellung einer konsistenten und nachvollziehbaren Konfiguration von EC2-Instanzen

  • Ziel 3: Reduktion des Support- und Troubleshooting-Aufwands um mindestens 20%

  • Ziel 4: Verbesserung der Wartbarkeit und Nachvollziehbarkeit der bereitgestellten Infrastruktur

  • Ziel 5: Ermöglichung der Durchführung standardisierter Deployments durch weniger erfahrene Mitarbeitende

Story Points

Zur Schätzung des Aufwands wird die relative Schätzung mittels Story Points (Fibonacci-Folge) gewählt. Dies ermöglicht es, Komplexität, Unwägbarkeiten und den reinen Arbeitsaufwand entkoppelt von Zeitdruck zu bewerten. Eine Story mit 5 Punkten wird dabei als etwa doppelt so aufwendig/komplex wie eine Story mit 2 oder 3 Punkten eingestuft. Als Beispiel:

Story Points Komplexität Beschreibung Beispiel im Projekt
1 Trivial Minimale Änderung, kein Risiko, sofort umsetzbar. Tippfehler in der README korrigieren oder Label anpassen.
2 Einfach Standardaufgabe ohne nennenswerte logische Hürden. Abfrage von User-Inputs (z.B. Region oder Instance-Type) via read.
3 Moderat Erfordert Recherche oder einfache Logik/Verknüpfungen. Implementierung der Logik zum Ersetzen von Platzhaltern im YAML-Template.
5 Komplex Mehrere Abhängigkeiten, Fehlerbehandlung nötig, API-Interaktion. Einbindung der AWS CLI Befehle inklusive Validierung der Rückgabewerte.
8 Gross Hohe Unsicherheit, umfasst mehrere Systembereiche. Erstmaliges Setup des Deployment-Flows (Verbindung Shell -> Template -> AWS).
13 Epic Zu umfangreich für eine einzelne User Story. “Das gesamte Skript inkl. aller Features entwickeln” -> Muss gesplittet werden!

Priorisierung mit MoSCoW

Die Userstories sowie Tasks werden anhand von MoSCoW (Must have, Should have, Could have, Won’t have) priorisiert. Dies sorgt dafür, dass die Priorisierung auf den wirklich wichtigen Aufgaben liegt und nicht für “nice-to-have”-Dinge zu viel Zeit verbraucht wird.

Releases

Es wird gleich viele Releases wie auch Sprints geben. Somit: Pro Sprint ein Release. Dies sieht ungefähr wie folgt aus:

Sprint Release genauere Bezeichnung Nutzen
1 MVP Minimal Viable Product Das Skript läuft einmalig von oben nach unten durch und deployt irgendwas.
2 MMP Minimum Marketable Product Das Skript ist “robust”. Es prüft Eingaben und ist sicher genug für Kollegen.
3 MLP Minimal Loveable Product Das Skript fühlt sich wie ein professionelles Tool an (Farben, Menüs, Geschwindigkeit).

Risikomanagement

Risiko W S Risikowert (W x S) Mitigationsstrategie (Vermeidung/Lösung)
Zeitverzug durch Komplexität 4 4 16 Fokus auf das MVP; MLP-Features konsequent streichen, falls die Zeit knapp wird (Scope-Management).
AWS Account/Quota Probleme 2 5 10 Frühzeitiger Test der Credentials und Berechtigungen; Nutzung des AWS Free Tier Budgets überwachen.
Technischer ““Blocker”” (Syntax) 3 3 9 Zeitnahe Recherche in Dokumentationen; Fallback auf einfachere Shell-Logik statt komplexer Tools.
Datenverlust (Lokal) 2 4 8 Tägliche Commits und Pushes in das GitLab-Repository (Versionierung als Backup).
Ausfall der Hardware (Laptop) 1 5 5 Regelmässige Sicherung der wichtigsten Konfigurationen; Nutzung von Cloud-IDE-Alternativen im Notfall.

Legende

W: Wahrscheinlichkeit (1 = unwahrscheinlich, 5 = sehr wahrscheinlich) S: Schadensausmass (1 = vernachlässigbar, 5 = kritisch für den Projektabschluss)

Risikowert: Priorisierung der Massnahmen (Hoch > 12, Mittel 6-12, Niedrig < 6)

Kommunikation

Die Kommunikation mit den Stakeholdern findet grundsätzlich nur über MS Teams statt. Das Gitlab-Repo ist öffentlich einsehbar und kann unter diesem Link gefunden werden: Gitlab.com Die aus dem Gitlab-Repo automatisch generierte Website kann hier eingesehen werden: docs.abyss.li

Stakeholder-Analyse

Name Rolle Einstellung Einfluss Interesse
Ramon Schmocker Projektleiter / Developer Hoch Kritisch Projekt so professionell, effizient und zielstrebig wie möglich abschliessen.
Michel Rodriguez Fachexperte Projektmanagement Mittel Unterstützend Hilfestellung für Projektmanagement-Anliegen / Challenges.
Armin Dörzbach Fachexperte Infrastruktur Mittel Unterstützend Hilfestellung für technische Anliegen / Challenges.
Thanam Pangri Lehrgangsleiter / Verantwortlich bei Eskalationen. Niedrig Neutral Professionelle Semesterarbeit, die bezeugt dass ich befähigt bin.

Ramon Schmocker:
Kategorie: Schlüsselfigur
Strategie: Wichtig: Regeln: Kommunikation über Teams-Kanal. Projekt so ausführlich wie möglich dokumentieren und planen. Dies ist entscheidend für den Erfolg.

Michel Rodriguez:
Kategorie: Fachexperte
Strategie: Starke Einbindung im Projektmanagement, bei Challenges nach Rat fragen. Bei Entscheidungsunsicherheit die Stakeholder miteinbeziehen.

Armin Dörzbach:
Kategorie: Fachexperte
Strategie: Sicherstellen, dass das Produkt fachgerecht programmiert ist und dass ich jede Zeile Code erklären kann.

Thanam Pangri:
Kategorie: Lehrgangsleiter
Strategie: Regelmässige Updates über Teams-Kanal bereitstellen. Bei Eskalationen in Absprache bleiben.

Projektzeitplanung

Projektzeitplan (Gantt)

Hier ist die Zeitliche Abfolge der Sprints und Meilensteine dargestellt:

gantt
    title Semesterarbeit: AWS EC2 Auto-Deploy
    dateFormat  YYYY-MM-DD
    axisFormat  %d.%m.

    section Planung
    Sprint 0 (Setup & Doku-Struktur) :done, s0, 2026-05-04, 6d

    section Entwicklung
    Sprint 1 (MVP - Kernfunktion)    :done, s1, 2026-05-10, 10d
    Sprint 2 (MMP - Robustheit)      :done, s2, after s1, 13d
    Sprint 3 (MLP - UX/Polishing)    :done, s3, after s2, 14d

    section Abschluss
    Dokumentation Finalisierung      :active, s4, after s3, 7d
    Abgabe der Arbeit                :milestone, m1, 2026-07-08, 0d

Sprint 1 

graph TD
    %% Definition der Spalten (Subgraphs)
    subgraph "To Do"
        T1[Keine offenen Tasks]
    end

    subgraph "In Progress"
        P1[Keine offenen Tasks]
    end

    subgraph "Done"
        D1[Projektstruktur aufsetzen]
        D2[GitLab CI/CD für Doku]
        D3[US.0: Evaluierung der Lösungsmöglichkeiten]
        D4[US.1: EC2-Instanz via CLI deployen]
        D5[US.2: Interaktive Parameter-Abfrage]
        D6[US.3: Befüllen des userdata.yml Template]
    end

    %% Styling für die Optik
    style D1 fill:#dfd,stroke:#333
    style D2 fill:#dfd,stroke:#333
    style D3 fill:#dfd,stroke:#333
    style D4 fill:#dfd,stroke:#333
    style D5 fill:#dfd,stroke:#333
    style D6 fill:#dfd,stroke:#333

Link zum Live Issue Board auf GitLab ↗

Sprint 2 

graph TD
    subgraph "To Do"
        T1[Keine offenen Tasks]
    end

    subgraph "Won't Do"
        W1[US.4: Abfrage von SSH-Keys & Security Groups]
    end

    subgraph "Done"
        D_prev[Features aus Sprint 1]
        D1[US.5: Fehlerbehandlung & Validierung]
        D2[US.6: Output-Zusammenfassung]
        D3[US.7: Interaktive Menü-Auswahl]
        D4[US.8: Standardwerte - Defaults]
        D5[US.10: Human-Readable Inputs / Auswahl]
    end

    %% Styling
    style W1 fill:#f8d7da,stroke:#a94442
    style D_prev fill:#dfd,stroke:#333,stroke-dasharray: 5 5
    style D1 fill:#dfd,stroke:#333
    style D2 fill:#dfd,stroke:#333
    style D3 fill:#dfd,stroke:#333
    style D4 fill:#dfd,stroke:#333
    style D5 fill:#dfd,stroke:#333

Link zum Live Issue Board auf GitLab ↗

Sprint 3 

graph TD
    subgraph "To Do"
        T1[Keine offenen Tasks]
    end

    subgraph "In Progress"
        P3[Keine offenen Tasks]
    end

    subgraph "Done"
        D_mmp[MMP Features abgeschlossen]
        D1[US.9: Visuelle Fortschrittsanzeige]
        D2[US.11: Betriebsdokumentation & Übergabe]
    end

    %% Styling
    style D_mmp fill:#dfd,stroke:#333,stroke-dasharray: 5 5
    style D1 fill:#dfd,stroke:#333
    style D2 fill:#dfd,stroke:#333

Link zum Live Issue Board auf GitLab ↗

Projektdurchführung

Zeiterfassung

Hier sind jegliche Arbeitsaufwände dieses Projekts dokumentiert.

FTE-Budget

Für diese Semesterarbeit ist ein Gesamtbudget von rund 60 Stunden (~7.5 FTE-Tage à 8 Stunden) eingeplant. Die nachfolgend dokumentierten Aufwände werden laufend gegen dieses Budget verrechnet, um den Verbrauch über die Sprints hinweg im Blick zu behalten.

Genehmigungsverfahren (Sprint 0)

Das initiale ausfüllen, revidieren und Re-Orientieren des PKA (Semesterarbeits-Einreichungsformulars)

  • Ausfüllen des Einreichungsformular ~1 Stunde
  • Re-Orientierung des Projekts (inklusive revidierung des Einreichungsformulars) ~2 Stunden

Initiales Aufsetzen des Projekts (Sprint 0)

In diesem Abschnitt ist das initiale Aufsetzen des GitLab-Repo’s sowie der Toolselektion

  • GitLab Issue Boards aufsetzen ~0.5 Stunden
  • GitLab Repo Struktur definieren ~0.2 Stunden
  • GitLab CI/CD Pipeline für Webpage-Docs aufsetzen + Troubleshooten ~0.5 Stunden
  • Domainconnect für GitLab Pages ~0.1 Stunden

Initiale Projektplanung (Sprint 0)

Die initiale Projektplanung. Hier zu erwähnen dass diese Werte wohl eher höher als Durchschnittlich sind, da die Projektleitung bisher in Sachen agilem Projektmanagement nicht vertraut war. Somit müssen hier wohl einige Verluste abgeschrieben werden, da diese Aufwände nicht den Kunden weiterverrechnet werden können.

  • Userstories verstehen ~0.2 Stunden
  • Userstory-Rating definieren ~0.1 Stunden
  • MLP / MMP / MVP / MVP verstehen & Releases für dieses Projekt definieren ~0.1 Stunden
  • SCRUM als Konzept verstehen ~2 Stunden
  • Meilensteine definieren ~0.1 Stunden
  • Userstories in GitLab erfassen ~0.5 Stunden
  • Tasks in GitLab erfassen ~0.5 Stunden
  • Grobe Roadmap erstellen ~0.3 Stunden

Subtotal Sprint 0

Total Sprint 0: ~8.1 Stunden

Implementierung (Sprint 1)

In diesem Abschnitt ist der Bau des MVP-Kerns dokumentiert, also das erste lauffähige Deployment-Skript.

  • Grundgerüst des Bash-Skripts aufsetzen ~1 Stunde
  • US.1: EC2-Instanz via aws ec2 run-instances deployen ~2 Stunden
  • US.2: Interaktive Parameter-Abfrage umsetzen ~1.5 Stunden
  • US.3: Befüllen des userdata.yml Templates (sed / cloud-init) ~1 Stunde
  • Security Group Troubleshooting (default SG blockiert alles) ~1.5 Stunden
  • Manuelles Testen des Deployments gegen AWS ~1 Stunde

Projektmanagement (Sprint 1)

Die planerischen und dokumentarischen Aufwände rund um den ersten Sprint.

  • Sprint-Planung & Backlog priorisieren ~0.5 Stunden
  • Sprint-Review & Dokumentation schreiben ~1 Stunde

Subtotal Sprint 1

Total Sprint 1: ~9.5 Stunden

Implementierung (Sprint 2)

In diesem Abschnitt ist die Weiterentwicklung des MVP zum robusten, benutzerfreundlichen MMP dokumentiert.

  • Refactoring auf modulare Funktionen (parse_args, check_dependencies) ~1 Stunde
  • US.5: Fehlerbehandlung, Dry-Run-Modus & Exit-Code-Handling ~2.5 Stunden
  • US.8: Standardwerte je Umgebung (load_environment_defaults) ~1 Stunde
  • US.7: Interaktive Menü-Auswahl via select ~1 Stunde
  • US.10: Human-Readable Umgebungsauswahl & Tagging ~1.5 Stunden
  • US.6: Output-Zusammenfassung mit IP-Polling & Konsolen-Link ~1.5 Stunden
  • Manuelles Testen aller Umgebungen & des Dry-Run-Modus ~1 Stunde

Projektmanagement (Sprint 2)

Die planerischen und dokumentarischen Aufwände rund um den zweiten Sprint.

  • Nachbesprechung Sprint 1 einarbeiten & neue Userstories erfassen ~0.5 Stunden
  • Sprint-Planung & Backlog aktualisieren ~0.5 Stunden
  • Sprint-Review & Dokumentation schreiben ~1 Stunde

Subtotal Sprint 2

Total Sprint 2: ~11.5 Stunden

Implementierung (Sprint 3)

In diesem Abschnitt ist die Veredelung des MMP zum MLP sowie die abschliessende Übergabedokumentation dokumentiert.

  • US.9: Spinner & Statusmeldungen (spinner, run_with_spinner) ~1.5 Stunden
  • US.9: Exit-Code-Handling der Hintergrundprozesse mit set -e troubleshooten ~0.5 Stunden
  • US.11: Betriebsdokumentation verfassen (Architektur, Daily Operations, Runbooks) ~2 Stunden
  • Manuelles Testen des Spinners (interaktiv & nicht-interaktiv) ~0.5 Stunden

Projektmanagement (Sprint 3)

Die planerischen und dokumentarischen Aufwände rund um den dritten Sprint.

  • Nachbesprechung Sprint 2 einarbeiten (verworfene US.4 dokumentieren) ~0.3 Stunden
  • Sprint-Planung & Backlog aktualisieren ~0.4 Stunden
  • Sprint-Review & Dokumentation schreiben ~1 Stunde

Subtotal Sprint 3

Total Sprint 3: ~6.7 Stunden

Sprint 0

  • Einreichungsformular überarbeitet anhand Feedback der Stakeholder
  • Userstories erstellen & priorisieren
  • Just the Docs für Dokumentation implementieren
  • GitLab Repo strukturieren
  • Backlog Priorisierung definieren
  • Template für Userstories definieren
  • Template für Tasks definieren
  • Story Points definieren
  • Stakeholder definiert
  • Ersten Sprint planen & Stakeholder informieren
  • Besprechungen vereinbaren

Retrospektive
Rückblickend kann ich sagen, dass ich für diesen Arbeitsprozess anfangs mit zu wenig Zeit gerechnet habe. Da ich anfangs davon ausging, das Projekt nach einem Wasserfall-Modell zu planen, habe ich mich verkalkuliert. Zuerst musste ich mir den gesamten agilen Prozess aneignen, um diesen zu verstehen und anzuwenden.

Room for Improvement Da ich nun mal mit agilem Projektmanagement angefangen habe, kann ich nun zuversichtlich sagen dass es mir beim nächsten Mal bestimmt einfacher fallen wird. Denn beim nächsten Mal würde ich folgende Dinge anders angehen:

  • Ich würde nicht Gitlab als Board nutzen, sondern eine Alternative wie beispielsweise Trello
  • Beim nächsten Mal werde ich beim Einreichungsformular von Anfang an problemorientiert denken.
  • Die Termine mit den involvierten Dozenten werde ich früher planen und auch gleich Buchen

Sprint 1

Plan des ersten Sprints

Ziele dieses Sprints:

  • MVP-Release fertiggestellt zu haben
  • Alle Tasks & Userstories, welche diesem Sprint zugewiesen sind, abzuschliessen.

Der momentane Stand des ersten Sprints sieht so aus:

graph TD
    %% Definition der Spalten (Subgraphs)
    subgraph "To Do"
        T2[US.1: EC2-Instanz via CLI deployen]
        T3[US.2: Interaktive Parameter-Abfrage]
        T4[US.3: Befüllen des userdata.yml Template]
    end

    subgraph "In Progress"
        P1[Aktuell keine Tasks]
    end

    subgraph "Done"
        D1[Projektstruktur aufsetzen]
        D2[GitLab CI/CD für Doku]
        D3[US.0: Evaluierung der Lösungsmöglichkeiten]
    end

    %% Styling für die Optik
    style T1 fill:#f9f,stroke:#333,stroke-width:2px
    style D1 fill:#dfd,stroke:#333
    style D2 fill:#dfd,stroke:#333

Für die aktuellsten Informationen:

Link zum Live Issue Board auf GitLab ↗

Aufgaben für diesen Sprint

Implementierung des ersten Sprints

Im ersten Sprint wurde der funktionale Kern des MVP umgesetzt. Grundlage bildeten die vorgängige Technologie-Evaluierung (Bash + AWS CLI als bevorzugte Lösung) sowie die Architekturentscheidung zugunsten eines funktional strukturierten Monolithen. Diese Vorentscheide erlaubten eine nachvollziehbare, endbenutzerorientierte Umsetzung mit klarer Fehlerbehandlung.

Die zu implementierenden Inhalte entsprachen den ersten drei User Stories des Sprint-Backlogs:

  • US.0: Evaluierung der Lösungsmöglichkeiten
  • US.1: EC2-Instanz via CLI deployen
  • US.2: Interaktive Parameter-Abfrage
  • US.3: Befüllen des userdata.yml-Templates

Die technische Umsetzung erfolgte in der Datei source/main.sh mit einer klaren Funktionsgliederung (main, get_user_input, generate_userdata, deploy_instance, cleanup). Damit wurde das im Architekturteil definierte Prinzip “Monolith mit interner Modularisierung” direkt angewendet.

US.0: - Evaluierung der Lösungsmöglichkeiten

Ziel der User Story

Die Projektleitung soll eine Evaluierung der bestmöglichen technischen Implementierung dieses Projekts durchführen, so dass Kosteneffizienz wie auch Ease of Use gewährt sind.

Implementierung

Eine Evaluierung wurde anhand vorgegebener Kriterien durchgeführt und kann hier gefunden werden: docs.abyss.li

Damit ist Userstory 0 umgesetzt: Eine Analyse wurde durchgeführt und ein Gewinner ausgewählt.

US.1 - EC2-Instanz via CLI deployen

Ziel der User Story

Die Projektleitung soll eine EC2-Instanz ohne manuellen Klickpfad in der AWS Console starten können, um die Bereitstellung reproduzierbar und effizient auszuführen.

Implementierung

Die Bereitstellung wurde in der Funktion deploy_instance() realisiert. Der technische Kern besteht aus einem parametrisierten Aufruf von aws ec2 run-instances.

Verwendete Parameter:

  • --image-id für die gewählte AMI
  • --instance-type für die Instanzgrösse
  • --subnet-id für die Netzzuordnung
  • --user-data file://... für Cloud-Init/Userdata
  • --security-group-ids "sg-0cf71c3fee7dd4c65" (hardcoded) um die korrekte Security Group zuzuweisen
  • --associate-public-ip-address (hardcoded) Damit die EC2-Instanz von aussen erreichbar ist
  • --region "us-east-1" (hardcoded) Definiert die Region, in welcher die EC2-Instanz deployed wird
  • --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=$HOSTNAME}]" Definiert einen Tag namens “Name”, damit die Instanz im EC2-Dashboard den definierten Hostnamen als Namen hat

Die Rückgabe wird mit --query 'Instances[0].InstanceId' --output text auf die Instanz-ID reduziert und anschliessend plausibilisiert. Falls keine Instanz-ID geliefert wird, bricht das Skript kontrolliert mit Fehlermeldung ab.

Qualitätssicherung und Fehlertoleranz

  • Globale Sicherheitsoptionen: set -euo pipefail
  • Vorprüfung gültiger AWS-Anmeldedaten via aws sts get-caller-identity
  • Eindeutige Konsolenausgaben zur Nachvollziehbarkeit der ausgeführten Schritte

Damit ist US.1 im Sinne der Story umgesetzt: Der eigentliche Deployment-Vorgang ist automatisiert, reproduzierbar und mit Basisschutz gegen Fehlkonfigurationen versehen.

US.2 - Interaktive Parameter-Abfrage

Ziel der User Story

Endbenutzer sollen die benötigten Deploy-Parameter während der Laufzeit eingeben können, ohne das Skript anpassen zu müssen.

Implementierung

Die Funktion get_user_input() implementiert einen geführten Eingabedialog mit den Feldern:

  • AMI-ID (Pflichtfeld)
  • Instance Type (Pflichtfeld)
  • Subnet-ID (Pflichtfeld)
  • Hostname (optional)

Für die Pflichtfelder wurden while-Schleifen mit Leereprüfung umgesetzt. Leere Eingaben werden unmittelbar mit einer klaren Fehlermeldung quittiert, anschliessend erfolgt die erneute Abfrage.

Nutzen für Benutzerfreundlichkeit

  • Keine Anpassung von Quellcode erforderlich
  • Reduktion von Eingabefehlern durch unmittelbare Validierung
  • Transparenter Ablauf durch konsistente Prompt-Texte

Die User Story ist dadurch erfüllt, da die Parametrisierung interaktiv, robust und für nicht-technische Anwender nachvollziehbar gestaltet ist.

US.3 - Befüllen des userdata.yml-Templates

Ziel der User Story

Die Konfiguration der Instanz soll standardisiert über eine Template-Datei erfolgen, damit wiederkehrende Basiskonfigurationen nicht manuell reproduziert werden müssen. Ebenfalls wird so eine homogene Systemlandschaft gewährleistet.

Implementierung

Die Funktion generate_userdata() verarbeitet die Datei userdata.yml.template und erzeugt daraus eine konkrete Laufzeitdatei unter /tmp/userdata_generated.yml.

Umsetzungsschritte:

  1. Existenzprüfung des Templates (-f)
  2. Kopie in eine temporäre Zieldatei
  3. Platzhalterersetzung `` per sed
  4. Fallback-Verhalten: Ist kein Hostname gesetzt, wird der Platzhalter entfernt

Dieser Ansatz stellt sicher, dass sowohl ein expliziter Hostname als auch ein “hostname-freier” Betrieb unterstützt werden.

Betriebssicherheit

Temporäre Artefakte werden über trap cleanup EXIT zuverlässig entfernt. Dadurch bleiben nach der Ausführung keine sensiblen oder veralteten Userdata-Dateien im Dateisystem zurück.

US.3 gilt damit als umgesetzt, da das Befüllen des Templates automatisiert, reproduzierbar und betrieblich sauber erfolgt.

Zusammenfassung Sprint 1

Die Umsetzung der User Stories US.1 bis US.3 bildet den lauffähigen MVP-Kern:

  • Interaktive Erfassung der benötigten Eingabewerte
  • Automatisiertes Generieren der Userdata-Konfiguration
  • Ausführung des eigentlichen EC2-Deployments via AWS CLI

Gleichzeitig wurde die Architekturvorgabe des Projekts eingehalten: ein einzelnes, portables Skript mit interner Funktionsstruktur statt verteilter Sub-Skripte. Dies erhöht die Nachvollziehbarkeit für Abnahme und Review und entspricht den priorisierten Projektzielen.

Review des ersten Sprints

Technisches

Einige Punkte sind hier nicht 100%-ig nach Best Practices aufgebaut. Dies hat jedoch stets einen sinnvollen Grund. Beispielsweise das Cloud-init Template. Eine Produktivverbesserung wäre hier jedoch die Auslagerung der SSH-Keys in AWS Secrets Manager oder Parameter Store. Ebenfalls habe ich mit dem Gedanken gespielt, einen Authorized_Key direkt aus der lokalen .ssh/authorized_keys auszulesen und diesen zusätzlich noch in’s generierte File einzufügen. Dies würde jedoch den Rahmen der Semesterarbeit sprengen.

Ebenfalls bin ich über einige Stolpersteine gefallen wie beispielsweise die Security Groups. Zuerst habe ich die Securitygroup nicht im API-Call definiert, was dazu führte dass die default security group verwendet wird. Diese blockiert jedoch alles. Es hat einige Instanzen gebraucht, bis ich das verstanden habe und eine eigene Securitygroup gebaut und im API-Call implementiert habe. Nachdem hat das ganze jedoch gut funktioniert.

Projektmanagement

Hier war mein Handeln alles andere als Souverän. Zuerst musste ich mir mal beibringen, was genau SCRUM überhaupt ist. Das ganze dann in die Tat umzusetzen war ebenfalls anspruchsvoller als ich das erwartet hatte. Jedoch bin ich, alles in allem, mit dem ersten Sprint zufrieden. Trotzdem gibt es einiges, auf was ich bei den nächsten beiden Sprints und vorallem bei den kommenden Semesterarbeiten stark verbessern kann. Jedoch glaube ich, dass ich doch schon einiges rein mit dem arbeiten an diesem Sprint verbessern konnte, sodass mir arbeiten mit SCRUM in der Zukunft einfacher fallen wird. Solche Beispiele sind unter anderem: - Userstories schreiben - Sinnvolle Tasks schreiben - Das “planen” eines Sprints - Die genauen Bedeutungen der Abkürzungen (MLP, MVP, AC, …)

Reminder

Dies ist mehr ein Reminder an mich selbst für die Zukunft, folgende Dinge haben oder haben mich fast gekriegt, weswegen ich in der Zukunft vermehrt darauf achten muss:

- Die Bewertungskriterien durchlesen. (Ich hätte fast die obligatorische Evaluierung vergessen...)
- Gewisse Dinge nicht zu sehr in Frage stellen.

TL;DR:

In diesem Sprint konnte ich bereits viel erreichen und noch mehr Optimierungspotential finden. Wenn ich die Bilanz ziehe bin ich trotzdem mehr oder weniger zufrieden.

TL;DR: Nachbesprechung

Die Projektleitung hat darin versagt, die Requirements der Zielgruppen im MVP-Release korrekt zu interpretieren. Code wird refactored, neue Requirements werden aufgenommen.

Funktionsbeweis MVP-Release:

Sprint 2

Plan des zweiten Sprints

Ziele dieses Sprints:

  • Den im ersten Sprint geschaffenen MVP zu einem robusten, fehlertoleranten MMP (Minimum Marketable Product) weiterzuentwickeln.
  • Die Benutzerfreundlichkeit für nicht-technische Zielgruppen (2nd Level Support) durch Human-Readable Auswahlmenüs und Standardwerte deutlich zu erhöhen.
  • Alle Tasks & Userstories, welche diesem Sprint zugewiesen sind, abzuschliessen.

Hintergrund: In der Nachbesprechung des ersten Sprints wurde festgestellt, dass die Requirements der Zielgruppen im MVP-Release nicht vollständig getroffen wurden. Der reine Freitext-Dialog war für technisch unbewanderte User zu fehleranfällig. Sprint 2 nimmt diese neuen Requirements auf und refactored den bestehenden Code entsprechend.

Der momentane Stand des zweiten Sprints sieht so aus:

graph TD
    %% Definition der Spalten (Subgraphs)
    subgraph "To Do"
        T1[US.5: Fehlerbehandlung & Validierung]
        T2[US.6: Output-Zusammenfassung]
        T3[US.7: Interaktive Menü-Auswahl]
        T4[US.8: Standardwerte (Defaults)]
        T5[US.10: Human-Readable Inputs / Auswahl]
    end

    subgraph "In Progress"
        P1[Aktuell keine Tasks]
    end

    subgraph "Done"
        D1[US.1: EC2-Instanz via CLI deployen]
        D2[US.2: Interaktive Parameter-Abfrage]
        D3[US.3: Befüllen des userdata.yml Template]
    end

    %% Styling für die Optik
    style D1 fill:#dfd,stroke:#333
    style D2 fill:#dfd,stroke:#333
    style D3 fill:#dfd,stroke:#333

Für die aktuellsten Informationen:

Link zum Live Issue Board auf GitLab ↗

Aufgaben für diesen Sprint

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.

Review des zweiten Sprints

Technisches

Der zweite Sprint war technisch deutlich angenehmer als der erste, da die Grundstruktur bereits stand und ich primär erweitern statt neu aufbauen konnte. Das konsequente Festhalten am “funktionalen Monolithen” hat sich hier ausgezahlt: Jede neue User Story liess sich als zusätzliche Funktion ergänzen, ohne den bestehenden Ablauf umzuwerfen.

Ein paar Stolpersteine gab es trotzdem. Der Dry-Run-Modus (US.5) war überraschend tückisch: aws ec2 run-instances --dry-run gibt bei Erfolg absichtlich einen Fehlercode mit der Meldung DryRunOperation zurück. Zusammen mit set -euo pipefail hat das zuerst dazu geführt, dass das Skript bei einem eigentlich erfolgreichen Dry-Run abgebrochen ist. Die Lösung war, den Aufruf in ein if ! ...-Konstrukt zu kapseln und gezielt auf den DryRunOperation-String zu prüfen.

Ebenfalls musste ich für die Output-Zusammenfassung (US.6) berücksichtigen, dass die öffentliche IP-Adresse direkt nach dem Start noch nicht verfügbar ist. Ein kurzes Polling über describe-instances löst das pragmatisch, ohne das Skript unnötig komplex zu machen.

Bei US.10 habe ich bewusst eine pragmatische Interpretation gewählt: Statt sämtliche Ressourcen zur Laufzeit über Tags aufzulösen, mappt das Skript die Human-Readable Umgebungsauswahl auf die in den Standards hinterlegten Werte und taggt die Instanzen beim Deployment mit Name und Environment. Das deckt den Nutzen für den 2nd Level Support vollständig ab und bleibt im Rahmen der Semesterarbeit wartbar.

Projektmanagement

Hier habe ich im Vergleich zum ersten Sprint klar dazugelernt. Die User Stories aus dem Nachbesprechungs-Feedback liessen sich sauber in den Sprint-Backlog überführen, und das Planen fiel mir spürbar leichter. Die fünf Stories bildeten thematisch eine logische Einheit (“Robustheit & Usability”), was die Priorisierung und die Reihenfolge der Umsetzung vereinfacht hat.

Was weiterhin Luft nach oben hat, ist das saubere Schätzen der Aufwände. Einzelne Stories (z. B. US.5 mit dem Dry-Run) haben mehr Zeit gekostet als gedacht, andere (US.8) gingen schneller als erwartet.

Verworfene User Story: US.4

Ursprünglich war für Sprint 2 die User Story US.4 “Abfrage von SSH-Keys & Security Groups” eingeplant. Diese wurde im Verlauf des Sprints bewusst verworfen, da sich die Anforderungen der Stakeholder geändert haben:

  • Die Security Groups werden seit US.8/US.10 nicht mehr separat abgefragt, sondern automatisch pro Umgebung (Prod/Int/Dev) aus den /.admin/Standards_AbyssInc.md aufgelöst. Eine zusätzliche, manuelle Abfrage wäre damit redundant und würde der Zielsetzung “Human-Readable, keine ID-Kenntnis nötig” sogar widersprechen.
  • Die SSH-Keys sind fest im userdata.yml.template (Cloud-Init) hinterlegt und werden so bei jedem Deployment einheitlich ausgerollt. Eine Laufzeit-Abfrage einzelner Keys hätte die homogene Systemlandschaft aufgeweicht. Die produktiv sauberere Lösung (Auslagerung in AWS Secrets Manager / Parameter Store) wurde bereits im Review von Sprint 1 als ausserhalb des Rahmens dieser Semesterarbeit eingestuft.

Die Story wurde damit nicht “vergessen”, sondern als nicht mehr werthaltig (effektiv “Won’t Do”) eingestuft. Auf Wunsch der Stakeholder aus der Nachbesprechung wird diese Entscheidung hier explizit dokumentiert.

Reminder

Dies ist erneut ein Reminder an mich selbst für die Zukunft:

- Bei AWS-CLI-Befehlen immer das Exit-Code-Verhalten prüfen (gerade in Kombination mit `set -e`).
- Defaults und fixe Werte konsequent zentral halten (Standards-File), statt sie im Code zu verstreuen.
- Eventualitäten wie "Wert noch nicht verfügbar" von Anfang an mitdenken.

TL;DR:

Sprint 2 hat den MVP zu einem runden, benutzerfreundlichen MMP gemacht. Die im ersten Sprint identifizierten Requirements der Zielgruppen wurden nachgezogen, der Code ist robuster und für nicht-technische User deutlich zugänglicher. Ich bin mit dem Ergebnis dieses Sprints zufrieden.

TL;DR: Nachbesprechung

Die Requirements der Zielgruppen werden im MMP-Release nun korrekt abgedeckt. Für Sprint 3 verbleibt das Polishing (MLP) sowie die abschliessende Dokumentation und Erfolgsmessung.

Sprint 3

Plan des dritten Sprints

Ziele dieses Sprints:

  • Den im zweiten Sprint geschaffenen MMP zu einem runden, professionell wirkenden MLP (Minimum Loveable Product) zu veredeln.
  • Eine vollständige und strukturierte Betriebsdokumentation für den ICT Server Support bereitzustellen, sodass das Produkt eigenständig betrieben und entstört werden kann.
  • Alle Tasks & Userstories, welche diesem Sprint zugewiesen sind, abzuschliessen.

Hintergrund: Mit dem MMP aus Sprint 2 sind die funktionalen Requirements der Zielgruppen abgedeckt. In der Nachbesprechung des zweiten Sprints wurde bestätigt, dass für das Release-Ziel “MLP” nur noch das Polishing sowie die abschliessende Dokumentation und Übergabe verbleiben. Sprint 3 nimmt diese letzten Punkte auf: eine visuelle Fortschrittsanzeige für ein angenehmeres Nutzungserlebnis (US.9) sowie die Betriebsdokumentation & Übergabe (US.11).

Der momentane Stand des dritten Sprints sieht so aus:

graph TD
    %% Definition der Spalten (Subgraphs)
    subgraph "To Do"
        T1[US.9: Visuelle Fortschrittsanzeige]
        T2[US.11: Betriebsdokumentation & Übergabe]
    end

    subgraph "In Progress"
        P1[Aktuell keine Tasks]
    end

    subgraph "Done"
        D1[US.1 - US.3: MVP-Features]
        D2[US.5 - US.8 & US.10: MMP-Features]
    end

    %% Styling für die Optik
    style D1 fill:#dfd,stroke:#333
    style D2 fill:#dfd,stroke:#333

Für die aktuellsten Informationen:

Link zum Live Issue Board auf GitLab ↗

Aufgaben für diesen Sprint

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. Über tput civis/tput cnorm wird 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 Variable SPINNER_OUTPUT, der ursprüngliche Exit-Code des Befehls wird unverändert zurückgegeben. Dadurch bleibt die bestehende Fehlerbehandlung aus Sprint 2 (inklusive der DryRunOperation-Logik) vollständig erhalten.
  • Die Statusmeldungen wurden an den drei wartezeit-relevanten Stellen ergänzt: Generiere Template... in generate_userdata(), Sende Request an AWS... rund um den run-instances-Aufruf in deploy_instance() sowie Warte auf Instanz-IP... während des IP-Pollings in print_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.

Review des dritten Sprints

Technisches

Der dritte Sprint war technisch der kleinste, aber dafür einer mit ein paar feinen Tücken. Die visuelle Fortschrittsanzeige (US.9) klingt zuerst nach einer Kosmetik-Aufgabe, kollidiert aber direkt mit dem set -euo pipefail aus Sprint 1: Ein Spinner braucht einen Hintergrundprozess, und dessen Exit-Code sauber einzusammeln, ohne dass set -e das Skript vorzeitig abbricht, war der eigentliche Knackpunkt. Gelöst habe ich das mit der Hilfsfunktion run_with_spinner, die den Befehl im Hintergrund startet, den Spinner anzeigt und den Exit-Code über wait gezielt einfängt. So bleibt die bestehende Fehlerbehandlung – inklusive der DryRunOperation-Logik aus Sprint 2 – unverändert erhalten.

Ein zweiter Punkt war die Robustheit ausserhalb einer echten Konsole. Ein Spinner, der mit \r dieselbe Zeile überschreibt, sieht in einer Pipeline oder in CI-Logs unschön aus. Über die Prüfung [[ -t 1 ]] zeigt das Skript daher nur in einer interaktiven Konsole die Animation und fällt sonst auf reine Statusmeldungen zurück.

Die Betriebsdokumentation (US.11) war weniger ein Code- als ein Strukturthema. Hier hat sich das von Anfang an gewählte Include-Konzept ausgezahlt: Der Inhalt liegt einmal zentral als Include und wird sowohl in die Dokumentations-Website als auch in die Stand-Alone-Datei userdocumentation.md eingebunden. Dadurch musste ich nichts doppelt pflegen.

Projektmanagement

Hier ist die Linie aus den ersten beiden Sprints klar aufgegangen. Das konsequente Scope-Management hat sich bewährt: Da die funktionalen Requirements bereits mit dem MMP abgedeckt waren, blieb für Sprint 3 ein überschaubarer, klar abgegrenzter Rest. Das Schätzen fiel mir spürbar leichter als noch in Sprint 1, und der Sprint liess sich ohne Überraschungen abschliessen.

Bewusst Stellung beziehen musste ich beim Feedback aus der Nachbesprechung von Sprint 2, dass für Sprint 2 “zu viel” eingeplant gewesen sei. In einem Ein-Mann-Projekt war das machbar, in einem echten Team-Setting wäre die Last aber unrealistisch gewesen. Diese Erkenntnis nehme ich als wichtigste Lehre für kommende Semesterarbeiten mit.

Reminder

Dies ist erneut ein Reminder an mich selbst für die Zukunft:

- Auch "kosmetische" Features (wie ein Spinner) können mit globalen Shell-Optionen kollidieren – früh mitdenken.
- Nicht-interaktive Umgebungen (CI/Pipe) von Anfang an als Sonderfall berücksichtigen.
- Realistische Sprint-Last auch für ein hypothetisches Team prüfen, nicht nur für mich allein.

TL;DR:

Sprint 3 hat den MMP zum MLP veredelt: Das Tool fühlt sich dank Spinner und Statusmeldungen runder an, und mit der Betriebsdokumentation ist die Übergabe an den Betrieb sauber vorbereitet. Damit sind alle für die Releases MVP, MMP und MLP vorgesehenen User Stories abgeschlossen, und das Produkt ist fertig. Ich bin mit dem Gesamtergebnis zufrieden.

TL;DR: Nachbesprechung

Mit dem MLP-Release ist der geplante Funktions- und Dokumentationsumfang des Projekts vollständig erreicht. Die in der letzten Nachbesprechung angemerkten Punkte (Dokumentation der verworfenen User Story, realistischere Sprint-Last) wurden aufgenommen. Für den Abschluss verbleibt einzig die finale Durchsicht und Abgabe der Semesterarbeit.

Funktionsbeweis Finalprodukt

Betriebsdokumentation

Diese Betriebsdokumentation richtet sich an den ICT Server Support der Abyss Inc. Sie beschreibt das Deployment-Tool für EC2-Instanzen so, dass das System ohne langwierige Einführung eigenständig betrieben, gewartet und im Fehlerfall entstört werden kann. Sie ist Teil des öffentlichen Git-Repositories und damit für das gesamte Support-Team an einem zentralen Ort zugänglich.

Es wird durchgehend eine einheitliche Terminologie verwendet und bewusst auf implizites Vorwissen verzichtet. Wo AWS-spezifische Begriffe nötig sind, werden sie kurz erläutert.

Systemübersicht & Architektur

Das Produkt ist ein einzelnes, portables Bash-Skript (source/main.sh), das über die AWS CLI mit der AWS-API kommuniziert und daraus EC2-Instanzen provisioniert. Die Basiskonfiguration der Instanz (Pakete, User, SSH-Keys) wird aus dem Template source/userdata.yml.template über Cloud-Init ausgerollt.

graph LR
    A[Supporter / Konsole] -->|interaktive Eingabe| B[main.sh]
    B -->|liest & befüllt| C[userdata.yml.template]
    B -->|AWS CLI / HTTPS 443| D[AWS EC2 API]
    D -->|provisioniert| E[EC2-Instanz]
    C -->|Cloud-Init Userdata| E
    A -.->|SSH / Port 22| E

Komponenten & Abhängigkeiten:

Komponente Rolle Schnittstelle / Port
main.sh Steuert den gesamten Deployment-Ablauf lokale Ausführung (Bash)
AWS CLI Übermittelt die Requests an AWS HTTPS / 443 (ausgehend)
AWS EC2 API Erstellt und verwaltet die Instanzen HTTPS / 443
userdata.yml.template Liefert die Cloud-Init-Basiskonfiguration Datei-Referenz (file://)
EC2-Instanz Das deployte Zielsystem SSH / 22 (Zugriff via abyss-admin)

Voraussetzungen:

  • Installierte AWS CLI (aws --version)
  • Gültige AWS-Credentials (aws configure), prüfbar via aws sts get-caller-identity
  • Ausgehender Zugriff auf die AWS-API (Port 443)

Daily Operations (Normalbetrieb)

Standard-Deployment (Prod / Int / Dev)

Das Skript wird interaktiv aus dem Ordner source/ gestartet:

./main.sh

Der Ablauf ist für alle Umgebungen identisch; einzig die Auswahl der Umgebung unterscheidet sich:

  1. Umgebung wählen: Im Auswahlmenü Produktion (Prod), Integration (Int) oder Entwicklung (Dev) auswählen. Damit werden AMI-ID, Instance-Type, Subnet und Security Group automatisch aus den Standards (/.admin/Standards_AbyssInc.md) vorbelegt.
  2. Werte bestätigen: Die vorgeschlagenen Standardwerte können per Enter übernommen oder bei Bedarf überschrieben werden.
  3. Instance-Type wählen: Aus der nummerierten Liste auswählen (Standard der Umgebung ist bereits angegeben).
  4. Hostname (optional) setzen, dann läuft das Deployment durch.
  5. Zusammenfassung prüfen: Am Ende werden Instance-ID, Public IP und ein Direktlink zur AWS-Konsole ausgegeben.

Für die Umgebung Custom werden keine Defaults gesetzt; alle AWS-IDs müssen manuell eingegeben werden (nur für Server mit Ausnahmebewilligung).

Parameter vorab prüfen (Dry-Run)

Vor einem echten Deployment können die Parameter ohne Kostenfolge gegen die AWS-API getestet werden:

./main.sh --dry-run

Erscheint die Meldung “Die Parameter sind gültig”, würde ein echtes Deployment funktionieren.

Logfiles

Ort Inhalt
Konsolen-Ausgabe von main.sh Vollständiger Ablauf inkl. Fehlermeldungen. Für eine Persistenz empfiehlt sich ./main.sh \| tee deployment.log.
/var/log/cloud-init.log (auf der Instanz) Ablauf von Cloud-Init beim ersten Boot
/var/log/cloud-init-output.log (auf der Instanz) Konsolen-Output der Cloud-Init-Schritte (Paketinstallation etc.)
AWS CloudTrail API-seitige Nachvollziehbarkeit der run-instances-Aufrufe

Troubleshooting

Die folgenden drei Szenarien decken die häufigsten Fehlerbilder ab. Lässt sich ein Problem damit nicht lösen, gilt der Eskalationspfad weiter unten.

Runbook 1 – “AWS Credentials nicht erkannt oder ungültig”

Symptom: Das Skript bricht direkt nach dem Start mit dieser Meldung ab.

Lösung:

  1. Credentials prüfen: aws sts get-caller-identity
  2. Sind keine/abgelaufene Credentials hinterlegt: aws configure ausführen und Access Key, Secret sowie Region setzen.
  3. Erneut starten.

Runbook 2 – “Das Deployment wurde von AWS abgelehnt”

Symptom: Der Request an AWS schlägt fehl, die Original-Fehlermeldung von AWS wird angezeigt.

Lösung:

  1. Region, AMI-ID, Subnet-ID und Security-Group-ID gegen die Standards (/.admin/Standards_AbyssInc.md) abgleichen – Subnet und Security Group müssen zur gleichen Umgebung gehören.
  2. Berechtigungen des verwendeten AWS-Users prüfen (IAM).
  3. Im Zweifel zuerst mit --dry-run testen, um die Parameter isoliert zu validieren.

Runbook 3 – “Instanz läuft, ist aber per SSH nicht erreichbar”

Symptom: Das Deployment war erfolgreich (Instance-ID & IP vorhanden), eine SSH-Verbindung auf Port 22 kommt jedoch nicht zustande.

Lösung:

  1. Prüfen, ob die korrekte umgebungsspezifische Security Group gesetzt wurde – die AWS-Default-Security-Group blockiert eingehenden Verkehr und darf nicht verwendet werden.
  2. Sicherstellen, dass Port 22 in der Security Group für die Quell-IP freigegeben ist.
  3. Kurz warten: Direkt nach dem Start ist die Instanz teils noch im Boot-/Cloud-Init-Vorgang.

Zuständigkeiten & Eskalation

Stufe Zuständig Wofür
1st Level ICT Server Support Durchführen der Deployments, Abarbeiten der Runbooks
2nd Level Fachexperte Infrastruktur (A. Dörzbach) AWS-/Infrastruktur-Themen (Security Groups, Subnets, IAM)
3rd Level Projektleitung / Developer (R. Schmocker) Fehler im Skript selbst, Anpassungen am Tool

Die Kommunikation und Eskalation erfolgt grundsätzlich über den MS-Teams-Kanal. Lässt sich ein Vorfall mit den obigen Runbooks nicht lösen, wird er an die nächsthöhere Stufe übergeben.

Ergebnisse & Analyse

Dieser Abschnitt stellt die erreichten Ergebnisse dem ursprünglich definierten Soll gegenüber. Bewertet werden einerseits die fünf in der Projektplanung definierten Ziele, andererseits der funktionale Lieferumfang sowie der tatsächliche Aufwand. Ziel ist eine ehrliche, nachvollziehbare Erfolgsmessung – ohne Schönfärberei.

Zielerreichung (Soll/Ist)

Die folgende Tabelle fasst den Erreichungsgrad der fünf Projektziele zusammen. Ziel 1 wurde konkret gemessen, die übrigen Ziele werden qualitativ anhand der umgesetzten Funktionalität und der Stakeholder-Rückmeldungen bewertet.

Ziel Soll Ist Status
Ziel 1: Bereitstellungszeit pro Instanz von ca. 20 Min auf unter 5 Min gemessen: Standard-Umgebungen (Prod/Int/Dev) unter 2 Min, Custom ca. 4 Min ✅ erfüllt
Ziel 2: Konsistente, nachvollziehbare Konfiguration keine manuellen Abweichungen mehr Werte je Umgebung zentral aus /.admin/Standards_AbyssInc.md, Configuration Drift eliminiert ✅ erfüllt
Ziel 3: Reduktion Support-/Troubleshooting-Aufwand mind. −20 % qualitativ plausibel durch Standardisierung, Dry-Run und Betriebsdoku/Runbooks; nicht über Produktivlaufzeit messbar 🟡 teilweise belegbar
Ziel 4: Verbesserung Wartbarkeit & Nachvollziehbarkeit nachvollziehbare Infrastruktur versionierte Konfiguration, funktional gegliederter Monolith, AWS-Tags (Name, Environment) ✅ erfüllt
Ziel 5: Standardisierte Deployments durch weniger erfahrene Mitarbeitende kein ID-Wissen nötig Human-Readable Umgebungsauswahl, Defaults, Auswahlmenüs statt Freitext ✅ erfüllt

Ziel 1 – Bereitstellungszeit (gemessen)

Das einzige rein quantitativ messbare Ziel wurde im Rahmen mehrerer manueller Testläufe gegen die AWS-API überprüft. Gemessen wurde die Zeit ab dem Start von main.sh bis zur laufenden Instanz inklusive ausgegebener Public-IP – die reine Bedenkzeit des Nutzers bei der Eingabe ist dabei nicht eingerechnet, da sie nicht dem Werkzeug zuzuschreiben ist. Für die Standard-Umgebungen (Prod/Int/Dev) lag die Bereitstellung dabei konstant bei unter 2 Minuten, da hier alle Werte über die Standard-Defaults vorbelegt sind und nur bestätigt werden müssen. Ein Custom-Deployment, bei dem sämtliche AWS-IDs manuell einzugeben sind, dauert mit rund 4 Minuten erwartungsgemäss länger – liegt aber selbst dann noch klar unter der Zielmarke von fünf Minuten. Der Grossteil der Zeit entfällt auf das Warten auf die AWS-API (Provisionierung und Vergabe der Public-IP), nicht auf das Skript selbst.

Ziel 2 bis 5 (qualitativ)

Die Ziele 2, 4 und 5 sind durch die im Sprint 2 umgesetzten Funktionen direkt belegbar: Die zentral in den Standards hinterlegten Umgebungswerte verhindern abweichende Konfigurationen (Ziel 2), die versionierte und funktional gegliederte Codebasis verbessert die Wartbarkeit (Ziel 4), und die Human-Readable Auswahl macht das Werkzeug auch für den 2nd Level Support ohne ID-Kenntnis bedienbar (Ziel 5).

Ziel 3 (Reduktion des Support-Aufwands um mindestens 20 %) lässt sich im Rahmen einer Semesterarbeit nicht seriös in Prozent messen, da hierfür ein Vorher-/Nachher-Vergleich über einen längeren Produktivbetrieb nötig wäre. Die Voraussetzungen für eine Reduktion sind jedoch geschaffen: standardisierte Eingaben, der Dry-Run-Modus zur Vorab-Validierung sowie die Betriebsdokumentation mit Runbooks senken die Fehlerquote und die Einarbeitungszeit nachweisbar. Dieses Ziel wird daher bewusst als teilweise belegbar statt als vollständig erfüllt ausgewiesen.

Funktionale Ergebnisse (Release-Sicht)

Über die drei Sprints wurde der geplante Funktionsumfang vollständig erreicht. Jeder Sprint mündete in das vorgesehene Release:

Release Sprint Lieferumfang User Stories
MVP 1 Lauffähiges Deployment: interaktive Eingabe, Userdata-Template, aws ec2 run-instances US.0–US.3
MMP 2 Robustheit & Usability: Fehlerbehandlung, Dry-Run, Defaults, Auswahlmenüs, Tagging, Output-Zusammenfassung US.5–US.8, US.10
MLP 3 Polishing & Übergabe: Spinner/Statusmeldungen, vollständige Betriebsdokumentation US.9, US.11

Die ursprünglich für Sprint 2 geplante US.4 (Abfrage von SSH-Keys & Security Groups) wurde bewusst als Won’t Do verworfen und im Review von Sprint 2 begründet dokumentiert. Damit sind alle werthaltigen User Stories umgesetzt; das Produkt entspricht dem geplanten MLP-Stand.

Aufwand (Soll/Ist)

Für die Arbeit war ein Budget von rund 60 Stunden vorgesehen. Der laufend erfasste Ist-Aufwand liegt darunter:

Phase Aufwand
Sprint 0 (Setup & Planung) ~8.1 h
Sprint 1 (MVP) ~9.5 h
Sprint 2 (MMP) ~11.5 h
Sprint 3 (MLP) ~6.7 h
Total (ohne Finalisierung) ~35.8 h

Der Verbrauch liegt klar innerhalb des Budgets. Auffällig ist der überdurchschnittliche Anteil von Sprint 0: Wie in der Zeiterfassung dokumentiert, entfiel hier viel Aufwand auf das erstmalige Einarbeiten in das agile Vorgehen (SCRUM), der sich nicht auf einen Kunden verrechnen liesse. Über die Sprints hinweg sank der Projektmanagement-Overhead spürbar, während die Implementierung effizienter wurde – ein direkter Effekt des Lernfortschritts.

Grenzen der Messung

Die hier dokumentierten Ergebnisse stammen aus einem Ein-Personen-Projekt mit manuellen Testläufen gegen einen AWS-Free-Tier-Account. Die Zeitmessung (Ziel 1) ist damit indikativ, nicht unter Laborbedingungen reproduziert. Für eine produktive Bewertung der Effizienzgewinne (insbesondere Ziel 3) wäre eine Erhebung über mehrere Wochen Produktivbetrieb mit mehreren Anwendern erforderlich. Diese Einschränkung wird bewusst offengelegt, um die Aussagekraft der Ergebnisse korrekt einzuordnen.

Fazit & Ausblick

Fazit

Das Ziel dieser Semesterarbeit – ein Werkzeug zur standardisierten, schnellen und einfachen Bereitstellung von AWS-EC2-Instanzen – wurde erreicht. Aus der manuellen, fehleranfälligen “Point-and-Click”-Provisionierung ist ein interaktives Bash-Skript geworden, das eine Instanz in den Standard-Umgebungen reproduzierbar in unter zwei Minuten (Custom rund vier) ausrollt und dabei die Konfiguration zentral aus den Abyss-Standards bezieht. Der eingangs beschriebene Configuration Drift zwischen Dev, Int und Prod ist damit eliminiert.

Inhaltlich wurden alle drei geplanten Releases (MVP, MMP, MLP) abgeschlossen und sämtliche werthaltigen User Stories umgesetzt. Genauso wichtig wie das Produkt war für mich aber der Weg dorthin: Diese Arbeit war mein erster vollständiger Durchlauf eines agilen Projekts nach SCRUM. Entsprechend lag ein erheblicher Teil des Lernens nicht im Technischen, sondern im Projektmanagement – vom Schreiben sinnvoller User Stories über das Schätzen mit Story Points bis zum Planen und Abschliessen einzelner Sprints. Der Fortschritt über die drei Sprints hinweg ist für mich der wertvollste Ertrag dieser Arbeit.

Reflexion und Vorbehalte

So zufrieden ich mit dem Ergebnis bin, gibt es bewusst gesetzte Grenzen, die ich nicht verschweigen möchte:

  • SSH-Keys im Klartext: Die autorisierten Schlüssel liegen fix im userdata.yml.template. Produktiv wäre die Auslagerung in den AWS Secrets Manager oder Parameter Store die sauberere Lösung. Dies wurde bereits im Review von Sprint 1 als ausserhalb des Rahmens dieser Arbeit eingestuft – die Entscheidung war also bewusst, nicht aus Unkenntnis.
  • Monolith statt Module: Die Architektur-Evaluierung fiel nur knapp zugunsten des funktionalen Monolithen aus. Für ein wachsendes, teamgepflegtes Werkzeug wäre eine modulare Struktur die nachhaltigere Wahl. Im Kontext dieser Semesterarbeit (Fokus Endbenutzer-Einfachheit, 80 % Projektmanagement-Bewertung) war der Monolith jedoch die stimmigere Entscheidung.
  • Begrenzter Scope: IAM-Rollen, Monitoring und der Betrieb nach dem Deployment sind bewusst out of scope. Für einen echten Produktivbetrieb wären diese Punkte zwingend zu ergänzen.
  • Aussagekraft der Messung: Wie im Kapitel “Ergebnisse & Analyse” offengelegt, beruhen die Werte auf manuellen Testläufen eines Ein-Personen-Projekts. Sie sind indikativ, nicht unter Laborbedingungen abgesichert.

Diese Vorbehalte schmälern das Ergebnis nicht – sie zeigen, wo die bewusst gezogene Grenze zwischen “Prototyp für die Semesterarbeit” und “produktivem Werkzeug” verläuft.

Ausblick

Aus den obigen Punkten ergibt sich ein klarer Pfad für eine mögliche Weiterentwicklung. Nach Priorität geordnet:

  1. Secrets-Handling: SSH-Keys und sensible Werte aus dem Template lösen und über AWS Secrets Manager / Parameter Store beziehen.
  2. IAM & Berechtigungen: Saubere, minimal berechtigte IAM-Rollen für das Deployment statt breiter Account-Rechte.
  3. Monitoring & Lifecycle: Einbindung von CloudWatch sowie ein definierter Prozess für Wartung und Deprovisionierung der Instanzen.
  4. Multi-Region / Skalierung: Unterstützung mehrerer Regionen und das Ausrollen mehrerer Instanzen in einem Lauf.
  5. Won’t-Do-Spalte & Tooling: Die in der Nachbesprechung angeregte “Won’t Do”-Spalte im Issue Board sowie der Wechsel auf ein dediziertes Board-Tool werden in der nächsten Semesterarbeit berücksichtigt.

Schlusswort

Rückblickend hat mir diese Arbeit weniger über AWS oder Bash beigebracht – diese Grundlagen waren vorhanden – als über das strukturierte, agile Vorgehen in einem Projekt. Genau das war als erste Semesterarbeit mit Fokus auf die Lernbegleitung auch der Anspruch. Das Werkzeug ist fertig, dokumentiert und übergabefähig; und ich gehe mit deutlich mehr Sicherheit im Projektmanagement in die nächste Semesterarbeit.

Danksagung & Ehrung

Obschon ich als “Die Projektleitung” dieses Mock-Project selbstständig geführt habe, hatte ich selbstverständlich als “Nerd” Hilfe. Deswegen kommt hier eine Danksagung sowie ein Auszug von allen Personen welche mir in dieser Arbeit geholfen haben.

Menschen

Ein grosses Dankeschön geht selbstverständlich an die “Stakeholder” dieses Projekts. Somit: Herzlichen Dank Armin Dörzbach & Michel Rodriguez. Euer Feedback hat mir sehr weitergeholfen und ich bin froh, euch als meine “Stakeholder” gehabt zu haben.

Technik

Selbstverständlich geht auch ein Dankeschön an folgende “virtuelle Assistenten” raus:

  1. Gemini CLI
  2. Aino (Eigene KI)
  3. Claude Code

Auch diese drei virtuellen Assistenten haben mir sehr geholfen.

This site uses Just the Docs, a documentation theme for Jekyll.