+ Neuer Prozess
← Alle Prozesse

Software-Release & Deployment

Veröffentlicht v2 P-IT-07
IT & Entwicklung Owner: AB Anna Bauer Approver: Clara Weiß Geändert 22.05.2026 19:44 Veröffentlicht 10.05.2026 Review bis 22.02.2027
#DevOps#CI/CD
Bearbeiten

Zweck & Scope

Zweck

Kontrolliertes, nachvollziehbares Ausrollen neuer Software-Versionen mit minimalem Risiko und klarer Roll-back-Strategie.

Geltungsbereich

Alle produktiven Web- und Service-Komponenten.

Auslöser

Pull-Request in `main` gemerged und Release-Tag erstellt.

Inputs · Outputs · KPIs

Inputs

Release-Notes, Test-Reports, Migrationsskripte

Outputs

Deploytes Artefakt in Produktion, aktualisierte Release-Notes, archivierte Artefakte

KPIs

Lead Time ≤ 1 Tag · Change Failure Rate ≤ 10 % · Roll-back-Rate ≤ 5 %

Beteiligte Rollen

  • Solution Architect
  • IT-Sicherheit
  • IT-Betrieb
  • Produktverantwortlicher
  • Fachbereichs-Spezialist
  1. 1

    Release-Kandidat fixieren

    Start

    Git-Tag setzen, Release-Notes generieren.

  2. 2

    Automatische Tests

    Aktivität Solution Architect ⏱ 25 Min.

    Unit, Integration, E2E, Security-Scan, Lizenz-Check.

    Systeme: GitHub Actions, SonarQube, Snyk

    • R Solution Architect
    • C IT-Sicherheit
  3. 3

    Staging-Deployment

    Aktivität IT-Betrieb ⏱ 10 Min.

    Vollautomatisches Deployment auf Staging mit Smoke-Tests.

    Systeme: ArgoCD, Kubernetes

    • R IT-Betrieb
    • A Solution Architect
  4. 4

    Manuelle Abnahme nötig?

    Entscheidung Produktverantwortlicher

    Major-Release oder UI-Change → Akzeptanztests.

  5. 5

    Fachliche Abnahme

    Aktivität Fachbereichs-Spezialist ⏱ 90 Min.

    Akzeptanztests gemäß Testplan, Fokus auf Domänenlogik.

    Systeme: TestRail

    • R Fachbereichs-Spezialist
    • A Produktverantwortlicher
  6. 6

    Production-Deployment

    Aktivität IT-Betrieb ⏱ 20 Min.

    Blue-Green Deployment, Health-Checks, Canary Rollout.

    Systeme: ArgoCD

    • R IT-Betrieb
    • A Solution Architect
    • I Produktverantwortlicher
  7. 7

    Release kommunizieren

    Aktivität Produktverantwortlicher ⏱ 30 Min.

    Changelog veröffentlichen, Support-Briefing, Kunden-Mailing falls sichtbar.

  8. 8

    Ende

    Ende

    Release abgeschlossen, Metriken eingesammelt.

+ Schritt hinzufügen

RACI-Matrix

Verantwortlichkeiten je Schritt und Rolle. R = Ausführend · A = Verantwortlich · C = Befragt · I = Informiert

# Schritt Solution Architect IT-Sicherheit IT-Betrieb Produktverantwortlicher Fachbereichs-Spezialist
1 Release-Kandidat fixieren
2 Automatische Tests RR C
3 Staging-Deployment A RR
4 Manuelle Abnahme nötig? R
5 Fachliche Abnahme A RR
6 Production-Deployment A RR I
7 Release kommunizieren R
8 Ende

RACI je Schritt pflegen

1. Release-Kandidat fixieren

Keine RACI-Zuweisungen.

2. Automatische Tests

  • R Solution Architect Responsible (Ausführend)
  • C IT-Sicherheit Consulted (Befragt)

3. Staging-Deployment

  • R IT-Betrieb Responsible (Ausführend)
  • A Solution Architect Accountable (Verantwortlich)

4. Manuelle Abnahme nötig?

Keine RACI-Zuweisungen.

5. Fachliche Abnahme

  • R Fachbereichs-Spezialist Responsible (Ausführend)
  • A Produktverantwortlicher Accountable (Verantwortlich)

6. Production-Deployment

  • R IT-Betrieb Responsible (Ausführend)
  • A Solution Architect Accountable (Verantwortlich)
  • I Produktverantwortlicher Informed (Informiert)

7. Release kommunizieren

Keine RACI-Zuweisungen.

8. Ende

Keine RACI-Zuweisungen.

Risiken & Kontrollen

RisikoSchwereKontrolleVerantwortlich
Stille Datenmigrationen Hoch Schema-Migrationen erfordern Architecture-Review. Anna Bauer

+ Risiko erfassen

Feedback & Fragen

Noch kein Feedback. Sei der erste!

+ Kommentar oder Frage

Versionshistorie

  1. v1 published 22.05.2026 19:44

    Initiale Veröffentlichung

    Snapshot anzeigen 
    {
    "name": "Software-Release & Deployment",
    "note": "Initiale Ver\u00f6ffentlichung"
}