Einen Software-Release mit Datenbankänderung vorbereiten
Ein Code-Rollback passt nicht automatisch zur geänderten Datenbank. Ein vollständiger Testfall zeigt, was vor dem Wechsel und dem Rückweg zu prüfen ist.
Bei einem Software-Release ändern sich manchmal Anwendung und Datenbank gemeinsam. Ein Rückweg muss deshalb mehr berücksichtigen als die vorherige Programmversion. Halten Sie fest, welche Kombination aus Code, Konfiguration und Datenstruktur zusammen funktioniert.
Das folgende hypothetische Portalbeispiel ist ein geplanter Testfall. Es beschreibt keine Änderung an einer realen Kundendatenbank.
Den Rückweg am selben Datenstand prüfen
Die bisherige Anwendung V1 liest Kundennamen aus customer_name. Die neue Anwendung V2 soll stattdessen display_name lesen. Im zunächst vorgesehenen Ablauf wird die alte Spalte entfernt. Danach startet die neue Anwendung wegen einer fehlenden Konfiguration nicht.
Schritt | Datenbank nach dem Schritt | Ergebnis im Beispiel |
|---|---|---|
Vor dem Wechsel | Alte Namensspalte vorhanden | Bisherige Anwendung funktioniert |
Nach der geplanten Änderung | Nur die neue Namensspalte vorhanden | Neue Anwendung startet wegen der Konfiguration nicht |
Nur den alten Code erneut bereitstellen | Weiterhin nur die neue Namensspalte vorhanden | Alte Anwendung findet ihre erwartete Spalte nicht mehr |
Die erneute Bereitstellung des alten Codes setzt die Datenstruktur nicht zurück. Ein Rollback-Knopf im Bereitstellungswerkzeug löst diese Unverträglichkeit nicht von selbst.
Einen kompatiblen Übergang planen
Eine mögliche Alternative ist ein schrittweiser Übergang: Zuerst bleibt die alte Spalte erhalten und die neue wird ergänzt. Vorhandene Werte werden nachvollziehbar übertragen. Das Team legt fest, welches Feld maßgeblich ist und wie Änderungen während des Übergangs konsistent bleiben.
In einer getrennten Testumgebung werden beide Anwendungsversionen gegen diesen Zwischenstand geprüft. Dazu gehört, einen Namen zu ändern und ihn über beide Versionen korrekt wiederzulesen. Ein einmaliges Kopieren reicht nicht, wenn später neue Werte nur in eines der Felder geschrieben werden.
Erst wenn die Umstellung bestätigt ist und die alte Version nicht mehr als Rückweg benötigt wird, wird die Entfernung des alten Felds geplant. Damit ändert sich erneut, welche älteren Versionen noch verwendbar sind. Dieser Schritt braucht eine eigene Entscheidung.
Daten nach dem Wechsel mitdenken
Ein älteres Backup kann die frühere Struktur enthalten. Wurden inzwischen neue Bestellungen angenommen, fehlen diese möglicherweise in dem Backup. Eine Wiederherstellung darf solche Vorgänge nicht unbemerkt verwerfen. Welche Daten nachkommen und wie sie abgeglichen werden, gehört in den Wiederherstellungsplan.
Je nach Änderung kann ein geplantes Wartungsfenster oder eine gezielte Korrektur der neuen Version sinnvoller sein. Der schrittweise Übergang ist kein pauschales Versprechen eines unterbrechungsfreien Updates.
Das Ergebnis der Probe festhalten
Dokumentieren Sie den geprüften Versionsstand, die Konfiguration, den Datenstand und die Person, die bei einem Fehlschlag entscheidet. Lassen Sie im Test eine Bestellung bis zum bestätigten Ziel verfolgen und anschließend den vorgesehenen Rückweg durchspielen. Notieren Sie, welche Daten dabei erhalten bleiben und welche Einschränkungen bestehen.
So wird vor dem produktiven Wechsel sichtbar, ob der geplante Rückweg tatsächlich zur Anwendung und ihren Daten passt.
Quellen
Weiterlesen
Alle Beiträge
Cloud & Betrieb mit ASES
Hosting, Deployment, Wartung und Betreuung