[Epic] Releasemanagement für Merge von Minor-API-Changes
Ausgangslage
Einige aktuelle Issues enthalten Minor-API-Changes (z.B. #301 (closed), #451 (closed), https://git.fitko.de/fit-connect/planning/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=minor&first_page_size=100). Wir haben zum Umgang mit solchen API-Changes bisher keinen sauberen Prozess definiert.
Lösung
Wir benötigen einen Prozess zum Mergen der zugehörigen MRs, der definiert, wie und wann die API-Version erhöht werden und was es dabei zu beachten gilt.
Relevante Links und Bemerkungen
Vorschlag: Branch erstellen --> implementieren --> Branch auf Merge Umgebung deployen --> Testen --> PO Review --> Merge auf Main / Anpassung Infra Repo --> automatisches Deplyoment auf Dev --> (Test?) --> Deplyoment auf Test
Akzeptanzkriterien
- Der Prozess ist im Wiki beschrieben.
- Der Prozess ist mit dem DEV-Team abgestimmt.
- Der Prozess beinhaltet detaillierte Anweisungen zum Vorgehen in GitLab / ggf. zur Nutzung von nötigen Skripten / etc.
- Doku (Api Spec, Doku und Changelog) und Software werden synchron auf die Testumgebung (Software) deployed und online (Dokumentation) gestellt
-
abklären, ob/wie Merge Umgebungen (deployment von feature-branches) erstellt und genutzt werden können - Für PO Review existiert eine Umgebung mit dem implementierten Feature
- Features ohne PO Review dürfen nicht auf Test/Refz/Prod landen
- Der Umgang mit SDKs ist beschrieben (Wann werden SDKs akualisiert? Minor-API-Changes erfordern das Erstellen eines Umsetzungs-Issues für die SDKs).
- Es werden abgedeckt: APIs, JSON-Schema (Metadatenschema, SET-Schema, ...), Infrastrutkurkomponentnen (Zustelldienst, SSP, ...), SDKs
Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)
- ...
- ...
- ...
- Definition of Done wurde geprüft