mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
236876a043
meldestelle/docs/04_Agents/Roadmaps/DevOps_Roadmap.md
Stefan Mogeritsch 236876a043 docs: restructure and streamline sprint execution order 
- 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>
2026-04-03 09:43:11 +02:00

3.5 KiB
Raw Blame History

🐧 [DevOps Engineer] — Zwischenstand & Roadmap

Stand: 3. April 2026 Rolle: Docker, CI/CD, Gradle, Security, Desktop-Packaging, Infrastruktur

✅ Erledigte Sprints

Sprint A — Abgeschlossen

  • A-1 | Docker-Compose-Setup auf aktuellen Stand gebracht
    • Alle Services in docker-compose.yaml / dc-*.yaml geprüft
    • Lokale Entwicklungsumgebung startet mit einem einzigen Befehl
    • Healthchecks für alle Services definiert

Sprint B — Abgeschlossen

  • B-1 | CI/CD Pipeline für Compose Desktop Tests (headless)

    • Gitea Actions Workflow: .gitea/workflows/desktop-tests.yml
    • Headless-Umgebung: xvfb-run (1920×1080×24) für Compose Desktop Tests
    • Gradle-Task: :frontend:shells:meldestelle-desktop:jvmTest
    • Build-Artefakte gespeichert (JARs, Compose-Distributables)

  • B-2 | Gradle-Build-Optimierungen

    • Build-Cache aktiv: org.gradle.caching=true
    • Parallele Builds aktiv: org.gradle.parallel=true
    • Headless-Flag: -Djava.awt.headless=true
    • 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.