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+trapfü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.