Heute war im Lenkungsausschuss eines großen Ausbauprojektes eines meiner Kunden die Problematik von „Hotfixes“ oder „Emergency Maintenance“ ein Thema. Einig waren wir uns darin, dass solche Änderungen am System aus einer Notlage heraus möglichst schnell und ohne großen Overhead vorgenommen werden müssen. Das bedeutet für die Rahmenbedingungen von Hotfixes:
- Es besteht ein schwerwiegendes betriebliches Problem, das deutliche Einbußen in der Produktivität bedeutet.
- Es geht nicht um funktionale Änderungen oder Erweiterungen, sondern um Fehlerbehebung.
- Es gibt kein mehrstufiges Change-Verfahren. Die Entscheidung zur Entwicklung eines Hotfixes wird von wenigen Personen und ad hoc getroffen.
- Die Änderungen erfolgen am „offenen Herzen“. Sie werden keinen umfangreichen Tests unterzogen. Die Tests unterliegen der Verantwortung des Entwicklers.
- Nach Implementierung des Hotfixes werden die Änderungen in den normalen Change-/Release-Prozess übernommen. Der Code wird zum nächsten Release/Patch bereinigt.
Das zeigt, dass Hotfixes gefährlich sind und nur in Ausnahmesituationen vorkommen sollten. 27 Hotfixes in 3 Monaten sind eindeutig zu viel und zeigen, dass hier der Change-/Release-Prozess umgangen wird. Heute entscheidet der Betrieb, ob ein Hotfix angefordert wird oder nicht. Offensichtlich liegt hier ein Missbrauch vor, aber wie geht man dagegen vor?
Der Vorschlag, die Architekur-Gruppe zur Entscheidung, ob ein Hotfix-Bedarf vorliegt, heranzuziehen, erscheint nicht praktikabel. Damit würde sich der Entscheidungsprozess signifikant verlangsamen und damit die Produktivität gefährden. M.E. muss die Entscheidung, ob ein Hotfix verlangt wird, beim Betrieb verbleiben, aber er muss motiviert werden, nur wirklich kritische Fehler so beheben zu lassen. Dazu ist folgendes nötig:
- Die Hürde für das ordentliche Change-/Release-Verfahren muss möglichst niedrig gelegt werden. Dazu gehören Transparenz, recht hohe Release-Frequenz und kein Rückstau von Changes.
- Die Notwendigkeit eines Hotfixes muss nachträglich detailliert begründet und belegt werden.
Risiken und Probleme von Hotfixes müssen dem Betrieb klar gemacht werden.