3.4 KiB
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 |