Hotfix in der App-Entwicklung: Wesen, Mechanismus und Anwendung

Was ist ein Hotfix und wann wird er benötigt?

Ein Hotfix (schnelle Korrektur) ist ein Patch für die Produktionsversion einer Anwendung, der außer der Reihe veröffentlicht wird, um ein kritisches Problem zu beheben. Ein Hotfix wird innerhalb von Stunden zu den Benutzern gebracht, nicht in Tagen, und ist ausschließlich für Situationen gedacht, in denen die Anwendung nicht verfügbar ist, Daten verliert oder die Benutzersicherheit gefährdet.

Typische Szenarien für einen Hotfix: Absturz beim Start auf bestimmten Geräten (Regression nach dem letzten Release), Leck persönlicher Daten aufgrund falscher Autorisierung, defekte Zahlungsintegration (Umsatzverlust), Verstöße gegen GDPR/CCPA-Compliance. Alle diese Situationen haben in der Incident-Klassifizierung den Schweregrad P0 oder P1. Geplante Aufgaben — Optimierung, Refactoring, neue Bildschirme — werden niemals per Hotfix durchgeführt.

Eine wichtige Regel: Ein Hotfix enthält eine minimale Anzahl von Änderungen (1–2 Dateien, 10–20 Codezeilen). Je kleiner der Diff, desto geringer das Risiko, einen neuen Fehler einzuführen. Wenn die Behebung des Problems eine Änderung der Architektur oder das Hinzufügen eines neuen Moduls erfordert — handelt es sich nicht um einen Hotfix, sondern um ein Notfall-Release, das eine vollständige Code-Review und QA erfordert.

Wie unterscheidet sich ein Hotfix von einem normalen Release

Die Hauptunterschiede zwischen einem Hotfix und einem geplanten Release sind Geschwindigkeit, Umfang der Änderungen und Testniveau. Ein geplanter Release kann Dutzende von Funktionen umfassen, einen vollständigen QA-Zyklus durchlaufen (Regression + Integration + UI-Tests) und 1–2 Wochen vom Code-Freeze bis zur Bereitstellung dauern. Ein Hotfix enthält ein oder zwei Korrekturen, durchläuft eine beschleunigte Überprüfung (2 Genehmigungen statt 3) und minimale Smoke-Tests.

Aus Sicht des Git-Prozesses wird ein Hotfix von einem Release-Tag erstellt, nicht vom develop-Branch. Dadurch wird sichergestellt, dass nur die zur Behebung des Problems notwendigen Änderungen in den Hotfix aufgenommen werden, ohne versehentlich unfertige Funktionen aus develop zu übernehmen. Nach der Bereitstellung wird der Hotfix zurück in main und develop gemergt (per Cherry-Pick oder Merge).

Vergleich zwischen geplantem Release und Hotfix

Wichtig: Nicht jede dringende Aufgabe ist ein Hotfix. Wenn ein Manager sagt “wir müssen dringend einen Button hinzufügen” — das ist kein Hotfix, sondern eine Prioritätsverschiebung. Ein echter Hotfix wird durch den Schweregrad für den Benutzer bestimmt, nicht durch die Dringlichkeit für das Geschäft. Das Kriterium: wenn die Anwendung nicht abstürzt und keine Daten lecken — wartet die Aufgabe auf einen geplanten Release.

Hotfix-Prozess: Von der Erkennung bis zur Bereitstellung

Der erste Schritt beim Erkennen eines kritischen Problems ist das Triage — eine schnelle Bewertung des Schweregrads. Der Bereitschaftsingenieur bestätigt den Fehler, überprüft Logs und Crash-Reports und stellt fest, ob das Problem eine Regression des letzten Releases oder ein langlebiger Fehler ist. Bei Schweregrad P0 wird die Hotfix-Pipeline gestartet. Die Triage-Phase sollte nicht länger als 15 Minuten dauern.

Der zweite Schritt ist das Erstellen eines Branches vom letzten Release-Tag (v2.5.0 → hotfix/v2.5.1). Der Entwickler nimmt die minimale Korrektur vor, committed mit dem Präfix HOTFIX in der Nachricht, pusht und öffnet einen PR mit dem Label [HOTFIX]. Fast-Track Code-Review: zwei Reviewer werden automatisch via CODEOWNERS zugewiesen, Review-Zeit — maximal 30 Minuten. Erfolgt innerhalb von 20 Minuten keine Review — wird der Reviewer übersprungen und der nächste zugewiesen.

Der dritte Schritt ist Build und Deployment via CI/CD. Die Hotfix-Pipeline unterscheidet sich von der normalen: lange Integrationstests (die Stunden dauern) werden übersprungen, nur die Smoke-Suite wird ausgeführt (10–15 kritische Szenarien, 5–10 Minuten). Nach dem Deployment: Überwachung der Crash-Rate, Fehlerrate, API-Latenz — für 30 Minuten. DORA-Metriken für Hotfixes: die mittlere Wiederherstellungszeit (MTTR) sollte unter 1 Stunde liegen.

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

Wichtige Optimierungen in dieser Pipeline: Diff-Überprüfung (nicht mehr als 30 Zeilen), Überspringen von Integrationstests, automatisches Deployment auf Staging und Production bei erfolgreichem Smoke-Test. HOTFIX_MODE Umgebungsvariable aktiviert zusätzliche Prüfungen zur Laufzeit — z.B. erweiterte Protokollierung zur schnellen Diagnose von Problemen.

Hotfix-Branches in Git: Die richtige Strategie

Die Strategie für die Arbeit mit Hotfix-Branches wird im Gitflow-Workflow beschrieben. Die Hauptregel: Ein Hotfix-Branch wird vom letzten Release-Tag erstellt (git checkout -b hotfix/v2.5.1 tags/v2.5.0), nicht von develop oder main. Dadurch wird sichergestellt, dass der Hotfix auf demselben Code-Stand basiert, der derzeit in Produktion ist, und keine unfertigen Änderungen aus develop übernimmt.

Nach Abschluss der Korrektur wird der Hotfix-Branch in main (oder master) und develop gemergt. In main — ein normaler Merge-Commit mit einem neuen Patch-Release-Tag (v2.5.1). In develop — ein Merge oder Cherry-Pick, je nach Teamrichtlinie. Wenn develop mehr Änderungen enthält als main, wird empfohlen, den spezifischen Hotfix-Commit zu cherry-picken, um Konflikte zu vermeiden. GitFlow empfiehlt, den Hotfix zuerst in main zu mergen und dann main in develop zu mergen.

# Hotfix-Branch vom letzten Release-Tag erstellen
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Die Korrektur anwenden
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# In main mergen und Release taggen
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Auch in develop mergen
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Temporären Branch bereinigen
git branch -d hotfix/v2.5.1

Wichtig: Wenn der Hotfix einen Fehler behebt, der im aktuellen develop-Branch existiert (der Fehler wurde vor mehreren Sprints eingeführt), dann enthält develop nach dem Mergen des Hotfix in main und develop bereits die Korrektur. Wenn der Fehler nur im Release-Branch eingeführt wurde (ein Fehler, der sich via Cherry-Pick angesammelt hat), ist die Korrektur in develop möglicherweise nicht erforderlich. Die Ursachenanalyse hilft festzustellen, ob ein Cherry-Pick in develop notwendig ist.

Risiken von Hotfixes und wie man sie minimiert

Das Hauptrisiko eines Hotfixes ist die Einführung eines neuen, schwerwiegenderen Fehlers aufgrund von Eile. Laut einer Studie von Stripe (2021) verursachen 15% der Hotfixes eine Regression und erfordern einen zweiten Hotfix. Das ist das Gesetz der Ironie: Je schneller wir korrigieren, desto höher ist die Wahrscheinlichkeit eines Fehlers. Die Risikominimierung wird durch die strenge Begrenzung der Diff-Größe (nicht mehr als 30 Zeilen) und obligatorische automatisierte Smoke-Tests erreicht.

Das zweite Risiko ist die Anhäufung technischer Schulden. Wenn ein Team regelmäßig Hotfixes anstelle von geplanten Releases verwendet, verschlechtert sich die Codebasis: Hotfix-Commits durchlaufen kein Refactoring, temporäre Lösungen werden nicht durch richtige ersetzt, die Dokumentation wird nicht aktualisiert. Gesundheitscheck: Wenn Hotfixes häufiger als einmal im Monat veröffentlicht werden — muss der Release-Prozess überprüft werden.

Das dritte Risiko ist psychologisch. Regelmäßige Hotfixes zehren am Team: Bereitschaftsentwickler stehen unter ständigem Stress, Code-Reviews werden zur Formalität (alle wollen schneller sein), und die Qualitätskultur sinkt. Eine normale Hotfix-Häufigkeit für ein reifes Team ist 1–2 pro Quartal. Wenn mehr — liegt das Problem nicht an den Hotfixes, sondern an der Qualität der geplanten Releases.

Was tun nach einem Hotfix

Nach der Bereitstellung eines Hotfixes und der Stabilisierung der Metriken wird eine schuldfreie Post-Mortem-Retrospektive durchgeführt. Das Team beantwortet vier Fragen: Was ist passiert, warum haben die Prüfungen den Fehler nicht gefangen, was wurde zur Behebung getan und wie kann ein erneutes Auftreten verhindert werden. Das Post-Mortem wird innerhalb von 24–48 Stunden nach dem Hotfix durchgeführt, solange die Details noch frisch sind. Schuldfreie Kultur ist ein Schlüsselprinzip: Es werden Prozesse diskutiert, nicht Personen.

Das Ergebnis des Post-Mortems sind konkrete Aktionspunkte mit Verantwortlichen und Fristen. Typische Aktionspunkte: Hinzufügen eines Unit-Tests für den übersehenen Fall, Erweitern der Smoke-Test-Suite, Verbessern der Überwachung (Hinzufügen eines Alarms auf die Metrik), Aktualisieren des Runbooks für ähnliche Vorfälle. Aktionspunkte müssen vor dem nächsten geplanten Release abgeschlossen sein.