Ein bestehendes System sicher ändern

Ermitteln Sie die Verträge rund um die Änderung

Bestehende Software hat Aufrufer, gespeicherte Daten, geplante Jobs und Betriebsverfahren. Manche Abhängigkeiten sind in der Datei, die Sie bearbeiten wollen, nicht sichtbar. Ein Agent kann eine lokal korrekte Änderung erzeugen, die einen dieser Verträge verletzt.

Ermitteln Sie vor der Implementierung die lesenden und schreibenden Komponenten der betroffenen Daten. Prüfen Sie Routen, Hintergrundjobs, Berichte und externe Integrationen. Prüfen Sie, ob andere Teams oder ältere Clientversionen vom aktuellen Verhalten abhängen.

Bitten Sie den Agenten, die Nachweise für diese Übersicht zu zeigen. Ein Suchergebnis ist ein nützlicher Ausgangspunkt. Bei dynamischen Aufrufen und externen Clients muss eine verantwortliche Person die Abhängigkeit möglicherweise bestätigen.

Machen Sie das aktuelle Verhalten beobachtbar

Ergänzen Sie bei einem schlecht dokumentierten Modul gezielte Prüfungen für Verhalten, das unverändert bleiben muss. Diese Prüfungen beschreiben den aktuellen Vertrag. Sie belegen nicht, dass jedes bestehende Verhalten erwünscht ist.

Wenn das aktuelle Verhalten einer Anforderung widerspricht, halten Sie den Konflikt fest. Erhalten Sie keinen Sicherheitsfehler nur deshalb, weil ein Test ihn erfasst hat. Holen Sie die Entscheidung ein, die beabsichtigtes Verhalten von einem Fehler unterscheidet.

Verwenden Sie realistische Testdaten ohne sensible Inhalte. Nehmen Sie alte Datenstrukturen und unvollständige Datensätze auf, wenn sie vorkommen können. Ein neues Schema, das nur mit neu erstellten Daten getestet wird, kann Migrationsprobleme verbergen.

Prüfen Sie den Übergang zwischen Versionen

Betrachten Sie eine fiktive Umbenennung von customer_name in display_name. Eine sofortige Umbenennung kann während des Deployments eine alte Anwendungsinstanz beschädigen. Dass beide Dateien in einem Pull Request aktualisiert werden, macht das Deployment nicht atomar.

Ein schrittweises Vorgehen kann die Kompatibilität erhalten:

1. Ergänzen Sie das neue Feld, ohne das alte zu entfernen.
2. Legen Sie fest, wie neue Schreibvorgänge die erforderlichen Werte konsistent halten.
3. Füllen Sie vorhandene Datensätze mit einem wiederaufnehmbaren Prozess nach.
4. Prüfen Sie Vollständigkeit und das Verhalten lesender Komponenten.
5. Stellen Sie lesende Komponenten auf das neue Feld um.
6. Entfernen Sie das alte Feld erst, wenn keine nutzenden Komponenten mehr darauf zugreifen.

Die genaue Methode hängt von Datenbank und Schreibmustern ab. Doppelte Schreibvorgänge können Inkonsistenzen erzeugen, wenn einer fehlschlägt. Eine Datenbanktransaktion oder ein anderes ausdrückliches Synchronisierungsverfahren kann nötig sein. Wenden Sie dieses Beispiel nicht an, ohne die Garantien des Systems zu prüfen.

Martin Fowler beschreibt diesen allgemeinen Übergang als Parallel Change, auch Expand-and-Contract genannt. Die zentrale Idee ist ein kompatibler Übergang vor der Entfernung.

Planen Sie Wiederherstellung getrennt vom Rollback

Ein Code-Rollback stellt eine frühere Anwendungsversion wieder her. Er macht eine Datenmigration nicht automatisch rückgängig. Die alte Version versteht die neuen Daten möglicherweise nicht. Eine destruktive Migration kann Informationen entfernen, die ein Code-Rollback nicht wiederherstellen kann.

Benennen Sie für jeden Schritt die Wiederherstellungsaktion. Ein wiederaufnehmbarer Backfill lässt sich möglicherweise sicher fortsetzen. Eine falsche Umwandlung kann eine Korrektur aus aufbewahrten Quelldaten erfordern. Ein destruktiver Vorgang kann ein geprüftes Wiederherstellungsverfahren benötigen.

Fragen Sie, wer die Wiederherstellungsentscheidung verantwortet und wie lange die Wiederherstellung dauern kann. Behandeln Sie „Wir haben Backups“ nicht als Nachweis, dass die Wiederherstellung die Dienstanforderung erfüllt.

Halten Sie die Änderung prüfbar

Trennen Sie aufgabenfremde Aufräumarbeiten von der funktionalen Änderung. Beschreiben Sie Kompatibilitätsplan, Prüfergebnisse und Entfernungsbedingungen im Pull Request. Markieren Sie den Punkt, ab dem ein Rollback zusätzliche Arbeit erfordert.

Ein Agent kann helfen, die nutzenden Komponenten zu untersuchen und Migrationscode vorzubereiten. Eine verantwortliche Person muss den Übergangs- und Wiederherstellungsplan weiterhin annehmen. Der endgültige Entwurf ist nur ein Teil einer sicheren Änderung.