Entwicklungshistorie in der Reihenfolge, wie das Projekt entstanden ist.
Dient als Kontext für die Übergabe: welche Entscheidung wurde warum
getroffen, welches Problem hat welche Änderung ausgelöst.
Ausgangslage: Software-Installer und Dokumentation lagen verstreut, keine
Übersicht, wer welche Software auf welchem Rechner hat. Ziel: ein Ort für
alles.
- Flask-Webanwendung + SQLite-Datenbank (eine Datei, kein DB-Server)
- Software-Katalog: Name, Kategorie, Version, Installer-Pfad, Silent-Install-
Parameter, Freitext-Dokumentation
- Status-Anzeige pro Tool: Aktuell / Bitte prüfen / Nie geprüft (Schwelle:
30 Tage seit letzter Prüfung) – löst das Kernproblem "Installer-Ordner
4 Wochen nicht gepflegt, muss alles neu heruntergeladen werden"
- Einfache Zuweisungs-Tabelle (ein Eintrag pro Mitarbeiter+Tool)
- Design bewusst zurückhaltend gehalten (kein Frontend-Framework), damit die
Zielperson (keine Programmiererfahrung) es per Doppelklick starten kann
Auslöser: "Ich dachte, ich kann das Tool direkt installieren – ist Python
nicht nur zum Programmieren da?"
- install.bat / start.bat: kein Terminal/Befehle mehr nötig, nur
Doppelklick
- Python-Versionsprüfung mit klarer Fehlermeldung statt kryptischem Absturz
Auslöser: Wunsch, dass sich Standard-Software selbst aktuell hält, ohne
Verteilung an andere Rechner (das war zu diesem Zeitpunkt explizit
NICHT gewünscht).
- Drei Update-Quellen: winget (Windows-Paketverwaltung), GitHub-Releases,
fester Download-Link
- Sicherheitskopie der alten Datei vor jedem Ersetzen
- Update-Protokoll pro Tool
- Mini-Doku-Box im Formular, die je nach gewählter Quelle live erklärt, wo
man den passenden Wert findet (ersetzt einen langen Erklärtext)
Auslöser: "Wenn ich mehrere Tools gleichzeitig zuweise, will ich nicht für
jede Software einzeln ein Formular ausfüllen."
- Checkliste mit "Alle auswählen", ein Formular erzeugt mehrere
Zuweisungen auf einmal
Auslöser: "Bei 40 Mitarbeitern × 40 Tools wird die Liste unübersichtlich."
- Neues Datenmodell: protokolle (1 Eintrag pro Rechner-Einrichtung) +
zuweisungen (n Tools pro Protokoll)
- Download-Button pro Tool (lokale Datei oder externer Link)
Auslöser: reale Nutzung zeigte, dass Installer-Dateien "nackt" im
gemeinsamen Ablageordner landeten, weil mehrere Tools denselben Basis-Ordner
eingetragen hatten.
- Mehrere Iterationen, bis die Lösung wirklich robust war:
1. Automatische Ordner-Erstellung beim Speichern
2. Automatische Dateinamens-Vergabe (aus Tool-Namen abgeleitet)
3. Endgültige Lösung: effektiver_ablageordner() erzwingt IMMER einen
Tool-eigenen Unterordner, unabhängig davon, was im Feld eingetragen ist
– auch rückwirkend, ohne bestehende Einträge ändern zu müssen
- Bugfix: Wurde eine Installer-Datei manuell gelöscht, meldete das System
fälschlich "bereits aktuell" (nur Versionsnummer wurde verglichen, nicht
ob die Datei noch existiert) – behoben durch zusätzliche Existenzprüfung
- Download-Button erkennt jetzt automatisch Ordner vs. Einzeldatei und
bietet bei Ordnern den Inhalt als ZIP an (wichtig für portable Tools wie
Blender)
- Versions-Anzeige in der Seitenleiste ergänzt (Diagnose-Hilfe, ob wirklich
die neueste Version läuft – nötig geworden, weil mehrfach der Verdacht
aufkam, ein Fix "greife nicht", obwohl der laufende Prozess nur nicht neu
gestartet worden war)
Auslöser: Rückbesinnung, dass eine Verteilungsfunktion doch gebraucht wird –
allerdings ohne Remote-Zugriff auf fremde Rechner (das wurde bewusst
verworfen: zu hoher Aufwand/Risiko ohne vorhandene Domänen-Infrastruktur).
Stattdessen: Skript, das man AUF dem neuen Zielrechner selbst ausführt.
- Route /einrichten: Checkliste aller Tools, erzeugt bei Bedarf ein
individuelles Installations-Paket (kein Pflegeaufwand für 100+ feste
Skripte)
- Generiertes PowerShell-Skript: lädt jedes ausgewählte Tool herunter,
installiert es still, meldet danach automatisch ein Protokoll an den
Server zurück (Rechnername wird automatisch erkannt)
- Tools ohne Installer-Datei (portable/entpackte Tools wie Blender) werden
als ZIP bereitgestellt – zunächst automatisch entpackt, nach Rückmeldung
("das will ich selbst entscheiden können") bewusst NICHT mehr automatisch
entpackt, sondern nur bereitgestellt
- Fester Client-Ordner C:\ClientBibliothek auf dem Zielrechner statt
verstreuter Temp-Pfade – ermöglicht eine einzelne Antivirus-/Defender-
Ausnahme statt vieler Einzelpfade; wird vom Skript beim ersten Lauf
automatisch selbst eingetragen (Add-MpPreference)
- Firewall-Freigabe-Skript ergänzt, nachdem der Test im echten
Firmennetzwerk anstand (Port 5000 war durch die Windows-Firewall blockiert)
Da die Zielumgebung Windows ist, die Entwicklung aber in einer Linux-Umgebung
stattfand, wurde wo immer möglich zusätzlich abgesichert:
- PowerShell 7 wurde in der Entwicklungsumgebung nachinstalliert, um
generierte Skripte mit dem echten Parser auf Syntaxfehler zu prüfen
- Netzwerk-Operationen (Download, Formular-Rückmeldung, ZIP-Erstellung/
-Entpacken) wurden, wo plattformunabhängig möglich, live gegen den
laufenden Server ausgeführt statt nur angenommen
- Windows-exklusive Teile (Admin-Rechte-Anfrage, msiexec, winget,
Defender-Cmdlets) blieben auf Syntaxprüfung + Dokumentations-Abgleich
beschränkt – siehe ARCHITEKTUR.md, Abschnitt 7, für Details
