Hotfix
Was ist ein Hotfix?
Ein Hotfix ist eine dringende Softwarekorrektur, die außerhalb des regulären Release-Zyklus erstellt und eingespielt wird. Der Name setzt sich aus „hot“ (im laufenden Betrieb, unter Druck) und „fix“ (Fehlerbehebung) zusammen. Ein Hotfix wird dann eingesetzt, wenn ein Fehler in der Produktion so gravierend ist, dass er nicht bis zum nächsten geplanten Update warten kann.
Typische Anlässe für einen Hotfix:
- Eine Sicherheitslücke wird aktiv ausgenutzt
- Eine Kernfunktion der Anwendung ist ausgefallen (Login, Bezahlvorgang, Datenbankzugriff)
- Ein Datenverlust droht oder ist bereits eingetreten
- Eine regulatorisch relevante Funktion arbeitet fehlerhaft
Der entscheidende Unterschied zu einem normalen Update: Ein Hotfix durchläuft einen verkürzten Testprozess. Die Dringlichkeit der Fehlerbehebung wiegt schwerer als die vollständige Absicherung durch umfangreiche Regressionstests. Das macht Hotfixes zugleich notwendig und riskant.
Hotfix, Patch, Bugfix und Coldfix im Vergleich
Die Begriffe werden häufig durcheinander verwendet. Eine klare Abgrenzung:
Patch ist der Oberbegriff für jedes Softwareupdate, das gezielt ein Problem behebt, sei es eine Sicherheitslücke, ein Fehler oder eine Kompatibilitätsfrage. Ein Patch wird im Rahmen des regulären Patch-Management-Prozesses geplant, getestet und ausgerollt. Zeitdruck besteht, ist aber beherrschbar.
Bugfix bezeichnet die Behebung eines spezifischen Fehlers im Code. Ein Bugfix kann Teil eines regulären Patches sein oder als eigenständiges Update veröffentlicht werden. Nicht jeder Bugfix ist dringend.
Hotfix ist ein Bugfix oder Sicherheitspatch, der unter Zeitdruck erstellt und eingespielt wird, typischerweise innerhalb von Stunden statt Tagen oder Wochen. Der verkürzte Prozess ist das definierende Merkmal.
Coldfix ist das Gegenteil: Eine Korrektur, die erst beim nächsten regulären Neustart oder Wartungsfenster angewendet wird. Coldfixes betreffen Fehler, die keinen sofortigen Eingriff erfordern, aber bei der nächsten Gelegenheit behoben werden sollten.
Der Hotfix-Prozess in der Praxis
1. Erkennung und Bewertung
Ein kritischer Fehler wird gemeldet, durch das Monitoring, einen Anwender oder ein automatisches Alerting-System. Der erste Schritt: Ist das Problem wirklich ein Hotfix-Kandidat? Oder lässt es sich mit einem Workaround überbrücken, bis der reguläre Patch-Zyklus greift? Diese Bewertung sollte nicht von einer einzelnen Person getroffen werden. In vielen Organisationen gibt es dafür einen kurzen Abstimmungsprozess zwischen Entwicklung, Betrieb und dem fachlich Verantwortlichen.
2. Entwicklung
Der Hotfix wird entwickelt, und zwar so minimal wie möglich. Das Ziel ist nicht, den Code zu verbessern oder ein Redesign zu starten, sondern genau das akute Problem zu beheben. Je kleiner die Änderung, desto geringer das Risiko unbeabsichtigter Nebenwirkungen. In der Versionsverwaltung wird ein Hotfix typischerweise auf einem eigenen Branch erstellt (Hotfix-Branch), der direkt vom Production-Stand abzweigt.
3. Test (verkürzt)
Auch ein Hotfix muss getestet werden, aber der Umfang ist reduziert. Statt eines vollständigen Regressionstests konzentriert sich das Testing auf die direkt betroffene Funktion und ihre unmittelbaren Abhängigkeiten. Automatisierte Tests beschleunigen diese Phase erheblich. Anwendungen mit guter Testabdeckung können einen Hotfix in Minuten statt Stunden validieren.
4. Deployment
Der Hotfix wird auf der Produktionsumgebung eingespielt. Je nach Infrastruktur kann das ein manuelles Deployment sein oder ein automatisierter Prozess über eine CI/CD-Pipeline. Wichtig: Der Zeitpunkt des Deployments und die durchgeführten Änderungen werden dokumentiert, für die Nachvollziehbarkeit und für das spätere Post-Mortem.
5. Nachbereitung
Nach dem Deployment wird der Hotfix in den regulären Entwicklungszweig zurückgeführt (Merge), damit die Korrektur auch in zukünftigen Releases enthalten ist. Außerdem findet in der Regel ein kurzes Post-Mortem statt: Was hat den Fehler verursacht? Warum wurde er nicht durch Tests erkannt? Was kann verbessert werden, damit ein ähnliches Problem in Zukunft im regulären Prozess abgefangen wird?
Hotfixes und Wartungsverträge
Für Unternehmen, die Individualsoftware betreiben, sind garantierte Hotfix-Zeiten ein zentraler Bestandteil des Wartungsvertrags. Das SLA definiert, wie schnell der Dienstleister bei einem kritischen Fehler reagiert und wie schnell ein Hotfix bereitgestellt wird.
Typische SLA-Parameter für Hotfixes:
- Reaktionszeit bei kritischen Fehlern: 1-4 Stunden
- Hotfix-Bereitstellung: 4-24 Stunden (abhängig von der Komplexität)
- Bereitschaft: Werktags oder 24/7 (je nach Vertrag und Kritikalität)
Ohne Wartungsvertrag wird ein Hotfix zum Ad-hoc-Projekt: Der Dienstleister muss sich erst wieder in den Code einarbeiten, Zugänge beschaffen und die Priorität des Einsatzes gegen andere Aufträge abwägen. Das kostet nicht nur mehr, sondern dauert auch deutlich länger, im schlimmsten Fall Tage statt Stunden.
Weiterführende Informationen
- Patch Management: der reguläre Update-Prozess
- Software Monitoring: Fehler erkennen, bevor Nutzer sie melden
- Wartungsvertrag für Individualsoftware: Hotfix-Zeiten vertraglich sichern
- Service-Level-Agreement (SLA): Reaktionszeiten und Eskalationsstufen
- Second Level Support: wer den Hotfix entwickelt
- Maintenance, Wartung und Support Service