Releasemanagement: Änderungsnachverfolgung und Patchplan einführen #12

New issue

Open

opened 2026-03-30 19:18:27 +00:00 by David · 0 comments

David commented

2026-03-30 19:18:27 +00:00

Collaborator

Beschreibung

Ein Releasemanagement-Konzept einführen, mit dem alle Änderungen am System nachvollziehbar dokumentiert und in Releases gruppiert werden. Ziel: Jederzeit sichtbar, welche Änderungen wann ins System gekommen sind (Patchplan/Changelog).

Hintergrund

Aktuell werden Änderungen nur auf Ticket-Ebene und über Git-Commits nachverfolgt. Es fehlt eine übergreifende Release-Sicht, die zeigt:

Welche Features/Fixes in welchem Release enthalten sind
Wann welche Version wohin deployed wurde
Was sich zwischen zwei Versionen geändert hat

Die Ticket-Daten (mr_url, mr_outcome, completed_at) sind bereits vorhanden und können als Grundlage für automatische Changelog-Generierung genutzt werden.

Akzeptanzkriterien

Neues DB-Model Release mit Version, Status, Datum, Beschreibung
Neues DB-Model ChangelogEntry mit Typ (feature/bugfix/improvement), Titel, Beschreibung, verknüpften Ticket-IDs
API-Endpoints: Releases auflisten, erstellen, Details abrufen, Changelog generieren
Tickets werden beim Abschluss (mr_created) automatisch dem aktuellen Draft-Release zugeordnet
Frontend-Seite "Releases" mit Timeline-Ansicht aller Releases
Release-Detailseite mit vollständigem Changelog und verlinkten Tickets
Deployment-Tracking: Welche Version ist wo aktiv (Staging/Produktion)
Semantic Versioning (Major.Minor.Patch) durchgängig angewendet
Auto-Generierung von Release Notes aus verknüpften Tickets

Technische Hinweise

Neues Model: backend/models/release.py (Release + ChangelogEntry)
Neuer Service: backend/services/release_manager.py
Neue API: backend/api/releases.py
Neue Frontend-Seiten: frontend/src/pages/Releases.tsx, frontend/src/pages/ReleaseDetail.tsx
Neue Komponenten: ReleaseTimeline.tsx, ChangelogEntry.tsx, DeploymentStatus.tsx
Integration in bestehende Pipeline: backend/services/pipeline.py — Ticket-Release-Verknüpfung bei mr_created
Alembic-Migration nötig: ja (neue Tabellen releases, changelog_entries)
Version aktuell hardcoded in backend/main.py als "0.1.0" — muss dynamisch werden

Aufwand: XL

## Beschreibung Ein Releasemanagement-Konzept einführen, mit dem alle Änderungen am System nachvollziehbar dokumentiert und in Releases gruppiert werden. Ziel: Jederzeit sichtbar, welche Änderungen wann ins System gekommen sind (Patchplan/Changelog). ## Hintergrund Aktuell werden Änderungen nur auf Ticket-Ebene und über Git-Commits nachverfolgt. Es fehlt eine übergreifende Release-Sicht, die zeigt: - Welche Features/Fixes in welchem Release enthalten sind - Wann welche Version wohin deployed wurde - Was sich zwischen zwei Versionen geändert hat Die Ticket-Daten (`mr_url`, `mr_outcome`, `completed_at`) sind bereits vorhanden und können als Grundlage für automatische Changelog-Generierung genutzt werden. ## Akzeptanzkriterien - [ ] Neues DB-Model `Release` mit Version, Status, Datum, Beschreibung - [ ] Neues DB-Model `ChangelogEntry` mit Typ (feature/bugfix/improvement), Titel, Beschreibung, verknüpften Ticket-IDs - [ ] API-Endpoints: Releases auflisten, erstellen, Details abrufen, Changelog generieren - [ ] Tickets werden beim Abschluss (`mr_created`) automatisch dem aktuellen Draft-Release zugeordnet - [ ] Frontend-Seite "Releases" mit Timeline-Ansicht aller Releases - [ ] Release-Detailseite mit vollständigem Changelog und verlinkten Tickets - [ ] Deployment-Tracking: Welche Version ist wo aktiv (Staging/Produktion) - [ ] Semantic Versioning (Major.Minor.Patch) durchgängig angewendet - [ ] Auto-Generierung von Release Notes aus verknüpften Tickets ## Technische Hinweise - Neues Model: `backend/models/release.py` (Release + ChangelogEntry) - Neuer Service: `backend/services/release_manager.py` - Neue API: `backend/api/releases.py` - Neue Frontend-Seiten: `frontend/src/pages/Releases.tsx`, `frontend/src/pages/ReleaseDetail.tsx` - Neue Komponenten: `ReleaseTimeline.tsx`, `ChangelogEntry.tsx`, `DeploymentStatus.tsx` - Integration in bestehende Pipeline: `backend/services/pipeline.py` — Ticket-Release-Verknüpfung bei `mr_created` - Alembic-Migration nötig: **ja** (neue Tabellen `releases`, `changelog_entries`) - Version aktuell hardcoded in `backend/main.py` als `"0.1.0"` — muss dynamisch werden ## Aufwand: XL