Ein Update darf keine Daten verlieren
Datenverlust ist der einzige Fehler, der sich nicht nachträglich beheben lässt. Alles andere kann man korrigieren. Deshalb ist die Art, wie eine Anwendung aktualisiert wird, kein Nebenthema der Technik, sondern eine Eigenschaft des Produkts.
Die Regel, auf die alles andere aufbaut
Ein Update tauscht Programm und Gestaltung aus. Es fasst das Datenverzeichnis nicht an, die Anhänge nicht, die Zugangsdaten nicht. Was es nicht mitbringt, darf es nicht löschen.
Das klingt selbstverständlich und ist es nicht. Die übliche Bequemlichkeit beim Ausrollen ist ein Spiegeln mit Aufräumen: Zielverzeichnis dem Paket gleichmachen, alles Übrige entfernen. Genau dieser Schalter löscht beim ersten Mal, wenn eine Datei im Ziel liegt, die im Paket fehlt, und das ist regelmäßig das Datenverzeichnis.
Vor jedem Update wird gesichert, ohne Ausnahme
Nicht „bei größeren Updates“, nicht „wenn Migrationen dabei sind“. Vor jedem. Gesichert werden Datenbank und Anhänge, in einen Ordner mit Zeitstempel, bevor irgendetwas anderes passiert. Läuft die Anwendung noch, wird sie vorher geordnet beendet.
Eine SQLite-Datenbank besteht nicht nur aus der Datei, die man sieht. Daneben liegen zwei Begleitdateien, in denen noch nicht übernommene Änderungen stehen. Wer nur die Hauptdatei kopiert, sichert einen älteren Stand, ohne es zu merken. Bei einer Prüfung haben wir so 37 Datensätze gezählt, wo 50 waren, und daraus zuerst den falschen Schluss gezogen. Seitdem wird immer der ganze Satz kopiert.
Umbenennen statt löschen
Beim Einspielen einer neuen Fassung liegt die naheliegende Reihenfolge so: altes Programmverzeichnis löschen, neues hinlegen. Das ist die falsche Reihenfolge. Löschen kann mitten drin scheitern, etwa weil einzelne Dateien einem anderen Benutzer gehören. Zurück bleibt ein halb gelöschtes Programm, und die Anwendung ist nicht mehr erreichbar.
Genau das ist uns passiert, bei einem System im Echtbetrieb. Repariert war es in Minuten, weil die neue Fassung schon daneben lag, aber die Lehre ist grundsätzlich: Erst umbenennen, dann das Neue einhängen, und erst löschen, wenn das Neue läuft. Umbenennen braucht nur Schreibrecht auf das übergeordnete Verzeichnis und geht ganz oder gar nicht.
Migrationen dürfen nur hinzufügen
Eine Datenbankänderung legt Spalten und Tabellen an. Sie benennt nichts um und löscht nichts. Das kostet Ordnung: Man schleppt Felder mit, die nicht mehr gebraucht werden. Es kauft dafür eine Eigenschaft, die mehr wert ist: Eine ältere Fassung des Programms läuft auf der neueren Datenbank weiter. Damit ist ein Rückweg immer möglich.
Wo eine Bedeutung sich wirklich ändert, wird die neue Spalte ergänzt und die alte gefüllt gelassen. Ein Beispiel aus einem Projekt: Aus einer Umsatzsteuer-Nummer sollte in bestimmten Fällen eine Steuernummer werden. Die Migration kopiert, sie überschreibt nicht. Wer sich vertan hat, findet den alten Wert noch.
Die Datenablage liegt fest
Jede Installation hat einen festen Pfad für ihre Daten, und der ändert sich nie. Klingt banal, ist aber die Ursache des Fehlerbildes, das Kunden am meisten erschreckt: „Update gemacht, Version ist hoch, alles ist leer.“ In fast allen Fällen ist nichts verloren, sondern die Anwendung sieht an einer anderen Stelle nach.
Bei einem Kunden lag ein Programm an zwei Stellen: einmal im Anwendungsverzeichnis, einmal auf dem Schreibtisch. Gestartet wurde die eine, aktualisiert die andere. Zu sehen war das erst an der Befehlszeile des laufenden Prozesses. Kein Datensatz ging verloren, die Sicherung von vorher war vollständig. Die Einrichtung sucht seitdem alle Stellen, an denen das Programm liegt, aktualisiert jede, gleicht den Bestand ab und ersetzt nie einen größeren Bestand durch einen kleineren. Nachzulesen in der Fallstudie zu diesem Projekt.
Was zum Update gehört, aber niemand nennt
- Die Versionsangabe muss mitziehen. Ein Ausrollskript, das die Versionsdatei nicht mitnimmt, lässt das System dauerhaft eine alte Fassung melden. Dann sucht man beim nächsten Fehler an der falschen Stelle. Genau das ist uns passiert.
- Die Wiederherstellung gehört geprobt, nicht dokumentiert. Eine Sicherung, aus der noch niemand zurückgespielt hat, ist eine Vermutung.
- Vor der Auslieferung wird mit vorhandenen Daten getestet. Nicht auf einem leeren System. Ein Update gegen eine leere Datenbank beweist nichts.
- Rechte nach dem Einspielen prüfen. Wer als Verwalter Dateien in ein Verzeichnis schreibt, in dem die Anwendung unter einem anderen Konto arbeitet, legt die Ursache für den nächsten Fehlschlag. Wir schreiben dort nur noch unter dem Konto der Anwendung.
Woran Sie das bei einem Anbieter erkennen
Vier Fragen genügen, und sie lassen sich in einem Gespräch stellen:
Wird vor jedem Update automatisch gesichert, und wohin?
Wenn die Antwort „wir empfehlen dem Kunden, vorher zu sichern“ lautet, ist die Antwort nein.
Was passiert mit Dateien im Zielverzeichnis, die nicht im Paket sind?
Die richtige Antwort ist: nichts.
Läuft die vorige Programmfassung auf der neuen Datenbank noch?
Wenn ja, gibt es einen Rückweg. Wenn nein, ist jedes Update eine Einbahnstraße.
Hat schon einmal jemand aus einer Sicherung zurückgespielt?
Die Frage ist unhöflich und trennt zuverlässig.
Erzählen Sie, was heute weh tut.
Ein paar Sätze genügen: was gemacht wird, womit es heute gemacht wird und woran es hakt. Sie bekommen eine ehrliche Einschätzung, auch dann, wenn die Antwort lautet: dafür brauchen Sie uns nicht.