62 lines
3.4 KiB
Markdown
62 lines
3.4 KiB
Markdown
# 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 |
|