stefan
236876a043
- Consolidated and removed redundant steps in `SPRINT_EXECUTION_ORDER.md`. - Simplified descriptions and roadmap formatting for improved clarity. - Updated progress and dependencies to align with Phase 8 objectives. - Adjusted role-specific roadmaps to reflect the latest sprint updates. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
88 lines
3.5 KiB
Markdown
88 lines
3.5 KiB
Markdown
# 🐧 [DevOps Engineer] — Zwischenstand & Roadmap
|
||
|
||
> **Stand:** 3. April 2026
|
||
> **Rolle:** Docker, CI/CD, Gradle, Security, Desktop-Packaging, Infrastruktur
|
||
|
||
---
|
||
|
||
## ✅ Erledigte Sprints
|
||
|
||
### Sprint A — Abgeschlossen
|
||
|
||
- [x] **A-1** | Docker-Compose-Setup auf aktuellen Stand gebracht
|
||
- [x] Alle Services in `docker-compose.yaml` / `dc-*.yaml` geprüft
|
||
- [x] Lokale Entwicklungsumgebung startet mit einem einzigen Befehl
|
||
- [x] Healthchecks für alle Services definiert
|
||
|
||
### Sprint B — Abgeschlossen
|
||
|
||
- [x] **B-1** | CI/CD Pipeline für Compose Desktop Tests (headless)
|
||
- [x] Gitea Actions Workflow: `.gitea/workflows/desktop-tests.yml`
|
||
- [x] Headless-Umgebung: `xvfb-run` (1920×1080×24) für Compose Desktop Tests
|
||
- [x] Gradle-Task: `:frontend:shells:meldestelle-desktop:jvmTest`
|
||
- [x] Build-Artefakte gespeichert (JARs, Compose-Distributables)
|
||
|
||
- [x] **B-2** | Gradle-Build-Optimierungen
|
||
- [x] Build-Cache aktiv: `org.gradle.caching=true`
|
||
- [x] Parallele Builds aktiv: `org.gradle.parallel=true`
|
||
- [x] Headless-Flag: `-Djava.awt.headless=true`
|
||
- [x] Gradle Wrapper auf `9.4.0` aktualisiert
|
||
|
||
---
|
||
|
||
## 🔴 Sprint C — Priorität 1 (diese Woche)
|
||
|
||
- [ ] **C-1** | Desktop-App Packaging konfigurieren
|
||
- [ ] `compose.desktop.nativeDistributions` in `build.gradle.kts` konfigurieren
|
||
- [ ] Windows: `.msi`-Installer bauen
|
||
- [ ] Linux: `.deb`-Paket bauen
|
||
- [ ] macOS: `.dmg`-Image bauen (falls erforderlich)
|
||
- [ ] App-Icon und Metadaten (Name, Version, Publisher) eintragen
|
||
- [ ] Testinstallation auf Ziel-Betriebssystem durchführen
|
||
|
||
- [ ] **C-2** | Semantic Versioning einführen
|
||
- [ ] Versionierungsschema definieren: `MAJOR.MINOR.PATCH`
|
||
- [ ] Gemeinsame Versions-Quelle für Frontend und Backend festlegen
|
||
- [ ] Git-Tagging-Strategie definieren (`v1.0.0`, `v1.0.0-backend`, etc.)
|
||
- [ ] Release-Tagging in CI/CD-Pipeline integrieren
|
||
- [ ] `CHANGELOG.md`-Vorlage anlegen
|
||
|
||
- [ ] **C-3** | Produktions-Deployment vorbereiten
|
||
- [ ] Reverse-Proxy-Konfiguration (Nginx / Traefik) für Backend prüfen
|
||
- [ ] HTTPS-Zertifikat-Management dokumentieren
|
||
- [ ] Backup-Strategie für Produktionsdatenbanken definieren
|
||
|
||
---
|
||
|
||
## 🟠 Sprint D — Priorität 2 (nächste Woche)
|
||
|
||
- [ ] **D-1** | Multi-Tenant Datenbankinfrastruktur absichern
|
||
- [ ] Sicherstellen: Pro-Tenant-Schema in Postgres korrekt isoliert
|
||
- [ ] Monitoring: Tenant-Schemas in Grafana-Dashboard sichtbar
|
||
- [ ] Backup: Pro-Tenant-Backup-Strategie definieren
|
||
|
||
- [ ] **D-2** | mDNS / LAN-Discovery Infrastruktur (nach ADR-0022)
|
||
- [ ] mDNS-Dienst (Avahi o. ä.) in Docker-Compose für lokale Entwicklung bereitstellen
|
||
- [ ] WebSocket-Endpunkt in Nginx/Traefik-Konfiguration durchreichen
|
||
|
||
> ⏸️ **Pangolin / externer Zugriff** — Nur für Remote-Support-Szenarien; kein MVP-Blocker
|
||
|
||
---
|
||
|
||
## 📌 Abhängigkeiten
|
||
|
||
| Warte auf | Von wem | Betrifft |
|
||
|----------------------------|-------------------|---------------------|
|
||
| ADR-0022 LAN-Sync | 🏗️ Architect B-1 | D-2 mDNS-Infra |
|
||
| QA: Test-Integration in CI | 🧐 QA C-4 | C-1 Packaging-Tests |
|
||
|
||
---
|
||
|
||
## 💡 Empfehlungen (nach Priorität)
|
||
|
||
1. **C-1 Desktop-Packaging** — Für erste echte Auslieferung an Endnutzer zwingend notwendig; `.msi`/`.deb` sollten vor
|
||
dem ersten Beta-Test bereitstehen.
|
||
2. **C-2 Semantic Versioning** — Ohne klare Versionierung ist kein koordiniertes Release möglich; einfach zu
|
||
implementieren, hoher Nutzen.
|
||
3. **D-1 Tenant-Backup** — Wenn eine Veranstaltung = eine Datenbank, muss jeder Tenant einzeln gesichert werden können.
|