83 lines
3.2 KiB
Markdown
83 lines
3.2 KiB
Markdown
# 🐧 [DevOps Engineer] — Schritt-für-Schritt Roadmap
|
|
|
|
> **Stand:** 2. April 2026
|
|
> **Rolle:** Docker, CI/CD, Gradle, Security, Desktop-Packaging, Infrastruktur
|
|
|
|
---
|
|
|
|
## 🔴 Sprint A — Sofort (diese Woche)
|
|
|
|
- [x] **A-1** | Docker-Compose-Setup auf aktuellen Stand bringen
|
|
- [x] Alle Services (Backend, DB, Infra) in `docker-compose.yaml` / `dc-*.yaml` prüfen
|
|
- [x] Sicherstellen: Lokale Entwicklungsumgebung startet mit einem einzigen Befehl
|
|
- [x] Healthchecks für alle Services definieren
|
|
|
|
Hinweise:
|
|
- Ein-Kommando-Start (alle Profile):
|
|
```bash
|
|
docker compose --profile all up -d
|
|
```
|
|
- Healthchecks ergänzt für: `api-gateway`, `ping-service`, `web-app`, `zipkin`.
|
|
- `depends_on` vereinheitlicht: Keycloak wird von Backend-Services mit `service_healthy` abgewartet.
|
|
|
|
---
|
|
|
|
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
|
|
|
- [ ] **B-1** | CI/CD Pipeline für Compose Desktop Tests (headless)
|
|
- [ ] GitHub Actions / Gitea Actions Workflow anlegen
|
|
- [ ] Headless-Umgebung für Compose Desktop Tests konfigurieren (Xvfb oder virtueller Framebuffer)
|
|
- [ ] Gradle-Task für Desktop-Tests in Pipeline integrieren
|
|
- [ ] Build-Artefakte (JAR / native Binaries) als Pipeline-Ausgabe speichern
|
|
- [ ] Fehlgeschlagene Tests als Build-Blocker konfigurieren
|
|
|
|
- [ ] **B-2** | Gradle-Build-Optimierungen
|
|
- [ ] Build-Cache aktivieren und prüfen
|
|
- [ ] Parallele Modul-Builds konfigurieren
|
|
- [ ] Gradle-Wrapper-Version auf aktuellen Stand bringen
|
|
|
|
---
|
|
|
|
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
|
|
|
- [ ] **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 Client (Frontend) und Server (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
|
|
|
|
---
|
|
|
|
## ⏸️ Zurückgestellt
|
|
|
|
> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt
|
|
> ⏸️ **Web-App Deployment** — Wird erst nach Desktop-App (Sprint A+B) gestartet
|
|
|
|
---
|
|
|
|
## 📌 Abhängigkeiten
|
|
|
|
| Warte auf | Von wem |
|
|
|-------------------------|------------------|
|
|
| Headless-Test-Strategie | 🧐 QA Specialist |
|
|
|
|
| Meine Aufgabe | Ermöglicht wem |
|
|
|---------------------------|----------------------------------------|
|
|
| CI/CD Pipeline (B-1) | 🧐 QA: Automatisierte Test-Ausführung |
|
|
| Desktop-Packaging (C-1) | Alle: Auslieferbare Desktop-App |
|
|
| Semantic Versioning (C-2) | Alle: Koordiniertes Release-Management |
|