ÜBERBLICK
Systemarchitektur
Alle sechs Apps teilen sich Anmeldung, Datenhaltung und Hosting.
ABLAUF
Änderung an einer bestehenden App
Gilt für Fehlerbehebungen, Erweiterungen und Design-Anpassungen.
- Auftrag klären. Was soll sich ändern, für wen, bis wann.
- Auf aktuellem Stand starten. Ein neuer Arbeitszweig wird immer vom aktuellen Hauptstand abgezweigt — nie auf einem alten Stand weitergearbeitet.
- Umsetzen. Änderung im Code, lokal geprüft (automatisierte Prüfung + Funktionstest im Browser).
- Prüfantrag stellen (Pull Request). Die Änderung wird zur Übernahme in den Hauptstand vorgeschlagen.
- Automatische Prüfung. Eine Kontrolle (CI) muss grün sein, bevor übernommen wird.
- Übernehmen. Nach grüner Prüfung wird in den Hauptstand übernommen.
- Ausliefern. Bei laufenden Apps: neues Image bauen, in Azure ausrollen — die Kolleg:innen sehen die Änderung nach dem nächsten Login.
ABLAUF
Eine neue App hinzufügen
Wenn ein komplett neuer Anwendungsfall ins Portfolio soll.
- Bedarf und Nutzen klären. Wer nutzt die App, welches Problem löst sie, wer ist verantwortlich.
- App-Grundgerüst anlegen. Neue App nach demselben Aufbau wie die bestehenden sechs (eigene Oberfläche, eigener Datenbereich).
- An Anmeldung und Übersicht anschließen. Neuer Eintrag in der Shell-Übersicht, neuer Zugang bei der zentralen Anmeldung.
- Berechtigungen vorbereiten. Wer darf die App sehen, wer darf darin etwas anlegen oder ändern — hier in der Verwaltung gepflegt.
- Erstes Ausrollen. Eigener Bereich in Azure, eigene Web-Adresse (Subdomain), einmalig eingerichtet.
- Freigeben. App erscheint für berechtigte Kolleg:innen in der Übersicht — ab hier gilt für Weiterentwicklung der normale Änderungs-Ablauf oben.
Diese Seite beschreibt den organisatorischen Ablauf für Entscheider:innen. Die technische Schritt-für-Schritt-Anleitung für das Entwicklungsteam steht im Projekt-Repository.