Wiederherstellungspunkte & sichere Updates

Wiederherstellungspunkte

Vor jeder Änderung an einer App zeichnet die Plattform einen Wiederherstellungspunkt auf: die App so, wie sie unmittelbar davor war. Ein Punkt enthält den Commit, auf dem jedes Repository stand, das vor der Änderung erstellte Backup (falls eines erstellt wurde) und was die Änderung bewirkt hat: die Commits, die sie gebracht hat, und die Module, die sie migriert hat.

Ein Punkt wird für Bereitstellen, Aktualisieren, Schnell-Update und Module aktualisieren aufgezeichnet, in jeder Umgebung. Ein Rollback ist ebenfalls eine Änderung und hinterlässt daher einen eigenen Punkt: Sie können jederzeit wieder vorwärts rollen. Punkte werden 90 Tage aufbewahrt; ihre Backups folgen den eigenen Regeln der Backups.

Öffnen Sie die App und wählen Sie in ihrer Seitenleiste Wiederherstellungspunkte.

Auf einem Punkt können zwei Badges erscheinen. Sofort rückgängig machen: Die Datenbank von vor dieser Änderung wird noch auf dem Server aufbewahrt, sodass das Rückgängigmachen nur Sekunden dauert (siehe Die behaltene Kopie). Hier gehalten: Die App wurde auf diesen Punkt zurückgesetzt und wird dort gehalten.

Zurücksetzen

Wählen Sie den Punkt direkt vor der Änderung, die Sie rückgängig machen möchten, und klicken Sie auf Zurücksetzen. Der Dialog zeigt, was die Änderung war, und fragt, was zurückgeholt werden soll. Jede Auswahl gibt an, ob sie von diesem Punkt aus möglich ist und was sie behält und verliert; eine nicht mögliche Auswahl ist ausgegraut.

In der Produktion geben Sie zur Bestätigung den Namen der App ein. Sobald das Rollback beginnt, verfolgen Sie es in der App unter Vorgänge. Eine App lässt sich nur zurücksetzen, solange sie bereitgestellt ist und nichts anderes auf ihr läuft.

Nur Code

Die Repositories werden auf den Commits des Punkts ausgecheckt. Die Setup-Dateien werden neu geschrieben, und das Image wird neu gebaut, wenn sich die Abhängigkeiten des Codes geändert haben. Module werden nicht herabgestuft, und die Daten bleiben, wie sie sind.

• Wurden seit dem Punkt Module migriert, listet der Dialog sie auf: Der ältere Code läuft dann auf dem neueren Datenbankschema. Bei kleinen Änderungen ist das meist unproblematisch; wenn nicht, verwenden Sie Beides.
• Der gemeinsame Odoo-Code, den jede App derselben Version verwendet, wird nie zurückgesetzt. Wenn er sich seit dem Punkt geändert hat, weist der Dialog darauf hin.
• Die App wird auf dem zurückgesetzten Code gehalten: Automatische Updates sind pausiert, und ein Push deployt sie nicht neu, bis jemand sie wieder aktualisiert. Solange sie gehalten wird, zeigt die Liste Automatische Updates nach einem Rollback pausiert.

Nur Daten

Das vor der Änderung erstellte Backup wird unter dem aktuellen Code wiederhergestellt, und die seither migrierten Module werden aktualisiert, damit die Daten zu ihm passen. Wählen Sie, wohin die Daten gehen:

Eine Kopie in eine andere App wird neutralisiert: Sie versendet keine E-Mails und führt keine geplanten Jobs aus. Während Daten in eine App wiederhergestellt werden, ist ihre Wartungsseite aktiv.

Beides

Code und Daten kehren auf den Stand unmittelbar vor der Änderung zurück; alles, was seitdem geschrieben wurde, geht verloren.

• Wenn die Datenbank des Updates noch auf dem Server aufbewahrt wird (Sofort rückgängig machen), wird sie in Sekunden zurückgespielt. Die aktuellen Daten werden einen Tag lang auf dem Server beiseitegelegt.
• Andernfalls wird das vor der Änderung erstellte Backup wiederhergestellt. Zuvor wird ein Sicherheits-Backup der aktuellen Daten erstellt.

Wer ein Rollback ausführen darf

Essential, Pro und Premium enthalten beide Funktionen. Eine Option, die Ihre Rolle in dieser Umgebung nicht ausführen darf, zeigt ein Schloss.

Sichere Updates

Ein Modul-Update ist der riskanteste Teil einer Änderung: Es migriert die Datenbank. Mit sicheren Updates läuft das Modul-Update auf einer Kopie der Datenbank. Die App wird erst auf die Kopie umgestellt, wenn das Update und ein Start darauf beide funktioniert haben. Schlägt eines davon fehl, wird die Kopie verworfen: Die App behält ihren Code und ihre Daten und ist innerhalb einer Minute wieder erreichbar. Nichts muss wiederhergestellt werden, weil sich nichts geändert hat.

Es gilt für Änderungen an bereits vorhandenen Daten: Bereitstellen bei einer schon einmal deployten App, Aktualisieren, Schnell-Update mit seiner Modulaktualisierung und Module aktualisieren. Ein erstes Deployment oder ein Deployment auf einer leeren Datenbank hat nichts zu schützen. Die Dialoge Build und Module aktualisieren zeigen an, wann das Update auf einer Kopie läuft.

Eine Kopie braucht Platz: Auf dem Datenbankserver müssen etwa das 1,2-Fache der Datenbankgröße plus 2 GB frei sein. Außerdem muss die Datenbank auf dem eigenen Datenbankserver der Umgebung liegen, und zu diesem Zeitpunkt darf kein Backup der App laufen. Wenn keine Kopie erstellt werden kann, nennt der Lauf den Grund, zum Beispiel, dass dem Server Platz fehlt, und was er stattdessen getan hat.

Die Kopie-Richtlinie für Updates

Jede Umgebung legt fest, was zu tun ist, wenn ein Update nicht auf einer Kopie laufen kann. Öffnen Sie das Projekt, wählen Sie die Umgebung, wechseln Sie zu Einstellungen und öffnen Sie Automatisierung.

Die Produktion aktualisiert immer auf einer Kopie, wenn das möglich ist (Auf einer Kopie, sonst direkt); daher wird die Einstellung nur in Staging und Entwicklung angezeigt.

Die behaltene Kopie

Nachdem ein sicheres Update funktioniert hat, wird die Datenbank von davor nicht sofort gelöscht. Sie bleibt auf dem Server bis zum nächsten sicheren Update der App oder 7 Tage lang, je nachdem, was zuerst eintritt. Solange sie vorhanden ist, zeigt der Wiederherstellungspunkt des Updates Sofort rückgängig machen, und ein Rollback mit Beides setzt sie in Sekunden wieder ein, statt ein Backup wiederherzustellen.

Auch das vor der Änderung erstellte Backup bleibt erhalten: Die behaltene Kopie liegt auf demselben Server wie die App, und das Backup deckt jeden älteren Punkt ab.

Wenn ein Update fehlschlägt

1. Öffnen Sie die Vorgänge der App und dort die fehlgeschlagene Ausführung: Der fehlgeschlagene Schritt nennt den Grund. Eine Ausführung, die Wird wiederholt anzeigt, ist nicht beendet; die Plattform versucht den Schritt selbstständig erneut.
2. Lief das Update auf einer Kopie, zeigt sein Wiederherstellungspunkt Fehlgeschlagen, nichts geändert: Die App läuft weiterhin mit ihrem alten Code auf ihren alten Daten. Beheben Sie die Ursache, zum Beispiel in Ihrem Code, pushen Sie und aktualisieren Sie erneut.
3. Lief das Update auf der Live-Datenbank und die App funktioniert nicht, setzen Sie sie mit Beides auf den Punkt vor dem Update zurück.
4. War der Fehler vorübergehend, zum Beispiel ein Netzwerkproblem, verwenden Sie Wiederholen in der Kopfzeile der App: Damit wird die fehlgeschlagene Ausführung ab dem fehlgeschlagenen Schritt erneut gestartet.