# Change Management

**Dokumenttyp:** Prozess
**Geltungsbereich:** Alle Änderungen an Produktivsystemen der PORTA-Plattform
**Version:** 1.0
**Status:** Entwurf zur internen Freigabe
**Owner:** Entwicklung / Release-Verantwortlicher
**Letzte Aktualisierung:** 02.06.2026
**Deckt ab (CACC):** 81, 82, 83
**Verweist auf:** `feature_release_bugfix.md`

---

## 1. Bestehender Prozess (Basis)

Der Kern des Change-Managements ist bereits in `feature_release_bugfix.md` dokumentiert und auditkonform aufgebaut: zentrale Erfassung, Priorisierung, Tech-Workshop, Feature-/Bugfix-Branches, Code-Review (Vier-Augen-Prinzip), Staging-Verifikation gegen Akzeptanzkriterien, Release in Produktion, versionierte Release Notes und CHANGELOG. Deployment erfolgt automatisiert über Forgejo-CI/CD.

Dieses Dokument ergänzt die für das CACC fehlenden Aspekte (#82 Frozen Zones, #83 Konfigurationskonformität) und fasst die Risikobewertung/Genehmigung formal zusammen (#81).

## 2. Change-Kategorien und Genehmigung (#81)

| Kategorie | Beispiel | Risikobewertung | Genehmigung |
|---|---|---|---|
| **Standard** | Routine-Bugfix, kleinere Anpassung | gering | Code-Review (2. Entwickler) |
| **Normal** | Neues Feature, API-Änderung | mittel | Tech-Workshop + Review + Staging-Verifikation |
| **Major** | Neue Version, DB-Migration, Architekturänderung | hoch | Tech-Workshop + Review + Staging + Backup vor Deployment + explizite Release-Freigabe |
| **Emergency** | Kritischer Hotfix / Sicherheitspatch | situativ | Verkürzt: Fix + Review + sofortiges Deployment, Nachdokumentation innert 24 h |

Jede Major-Änderung erfordert vor dem Deployment einen Export-Backup (siehe `datenbank-handling.md` / Dok 05).

## 3. Frozen Zones und Maintenance Windows (#82)

PowerOn ermöglicht kundenseitig definierte **Frozen Zones** (Zeiträume ohne Änderungen, z. B. Jahresabschluss einer Bank) und **Maintenance Windows**.

| Element | Regelung |
|---|---|
| Frozen Zone | Auf Kundenwunsch im Vertrag/SLA definiert; in diesen Zeiträumen keine nicht-kritischen Deployments |
| Maintenance Window | Geplante Wartung wird mind. 5 Werktage im Voraus angekündigt |
| Notfalländerung in Frozen Zone | Nur bei kritischen Sicherheitsvorfällen, mit Kundeninformation |

**[ZU PRÜFEN: Werden Frozen Zones aktuell technisch/organisatorisch berücksichtigt? Falls neu, als Prozessvorgabe etablieren.]**

## 4. Standardisierte und sichere Konfiguration (#83)

| Element | Regelung | Status |
|---|---|---|
| Konfigurationsdateien | `.env` pro Umgebung (`env-prod.env`, `env-int.env`), getrennt, nicht im Git | Umgesetzt |
| Infrastruktur als Code | [ZU PRÜFEN: Werden Server-Konfigurationen versioniert/reproduzierbar gehalten?] | [ZU PRÜFEN] |
| Konformitätskontrolle | Regelmässige Prüfung, dass Produktivkonfiguration dem Soll entspricht | [ZU PRÜFEN: etablieren] |
| Härtung | siehe `12_Netzwerk_und_Infrastruktursicherheit.md` | |

## 5. Nachvollziehbarkeit (Auditnachweis)

Jede Änderung ist nachvollziehbar über: Issue/Ticket, Feature-/Bugfix-Branch, Pull Request mit Review, CI/CD-Pipeline-Lauf in Forgejo, Commit-Historie, CHANGELOG-Eintrag. Rollbacks sind über Git/Forgejo dokumentiert (`bcm_runbook.md` §3).

## 6. Stand der Umsetzung / Lücken

| Thema | Status | Massnahme |
|---|---|---|
| Change-Kategorisierung formalisiert | Neu | Übernehmen |
| Frozen Zones | [ZU PRÜFEN] | Prozess verankern |
| Konfigurations-Konformitätsprüfung | [ZU PRÜFEN] | Etablieren |