Eine private PrestaShop-Staging-Site erstellen und aktualisieren

Unser empfohlenes Vorgehen

Wir würden die Änderung und ihre Abnahmetests vereinbaren, bevor wir die Kopie erstellen. Das passende Vorgehen hängt von Ihrem vorhandenen Shop ab: seinen Modulen, Integrationen, dem Theme, den Daten, Märkten und den Personen, die ihn testen und warten werden. Eine Versandänderung benötigt repräsentative Adressen und Versanddienste; ein Versionsupgrade erfordert eine umfassendere Erprobung der Shop-Abhängigkeiten. Halten Sie nicht zugehörige Verbesserungen aus diesem Test heraus, damit sich ein Fehler einer Ursache zuordnen lässt.

Erproben Sie die vorgesehene Änderung auf einer sauberen, isolierten Staging-Kopie und planen Sie dann die Produktionsumstellung mit einer benannten entscheidungsbefugten Person und einem Wiederherstellungsweg. Entscheiden Sie, ob Sie ein getestetes Paket im aktuellen Shop bereitstellen oder den Shop migrieren und seine abschließenden Daten abgleichen. Das sind unterschiedliche Bereitstellungspläne: Bestandene Tests auf der gestrigen Kopie klären nicht, was mit den heutigen Bestellungen geschieht.

Wenn Sie einen Versionswechsel durchführen lassen möchten, beginnt der PrestaShop Upgrade Service: Any Version to PrestaShop 9 mit den Anforderungen Ihres Shops und einer Erprobung auf Staging.

Festlegen, was Staging testen soll

Eine Staging-Site ist eine private Kopie, auf der Sie Änderungen mit repräsentativen Shop-Dateien, Daten, Themes und Modulen proben. Sie hilft Ihnen, Modulkonflikte, fehlgeschlagene Upgrades, Checkout-Fehler und Leistungseinbußen vor der Bereitstellung zu finden.

Bewahren Sie Entwicklungsarbeiten in einer Versionsverwaltung oder einer separaten Entwicklungsumgebung auf. Eine Staging-Aktualisierung kann lokale Änderungen ersetzen. Halten Sie außerdem unabhängige, wiederherstellbare Backups vor. Staging ist kein Backup, und unveränderliche Backups gibt es nur, wenn Sie geeigneten Speicher und Aufbewahrung konfigurieren.

Dokumentieren Sie die produktive PrestaShop-Patchversion, PHP-Version und Erweiterungen, Datenbankversion, Webserverregeln, Theme, Module, Jobs und externe Abhängigkeiten. Beginnen Sie mit dieser Ausgangsbasis. Ändern Sie beim Test eines Upgrades gezielt eine Variable, etwa PHP oder eine Modulversion.

Nutzen Sie Staging für Core- oder PHP-Upgrades, Modulinstallationen, Theme-Änderungen, Overrides, Datenbankmigrationen und wichtige Änderungen an Steuern, Versand oder Zahlungen. Für routinemäßige Inhaltsarbeiten genügt eine angemessene Prüfung. Eine Preis-, Versand- oder Steueränderung kann dennoch den Checkout beeinflussen und sollte getestet werden.

Zugriff und Nebenwirkungen vor dem Kopieren von Daten beschränken

1. Erstellen Sie ein separates Staging-Verzeichnis, eine eigene Datenbank und einen eigenen Datenbankbenutzer. Beschränken Sie diesen Benutzer auf die Staging-Datenbank.
2. Richten Sie Webserver-Authentifizierung, eine Netzwerk-Freigabeliste oder ein privates Netzwerk ein, bevor Sie Produktionsdaten in die Umgebung übertragen. Beziehen Sie Shop-Oberfläche, Admin, statische Dateien und zusätzliche Endpunkte ein.
3. Lassen Sie Anwendungszugriffe, Cronjobs, Worker und geplante Aufgaben während des Klonens und Bereinigens gestoppt.
4. Beschränken Sie ausgehende Verbindungen, damit kopierte Zugangsdaten keine produktiven Zahlungs-, E-Mail-, Versand-, ERP-, Marktplatz- oder Webhook-Dienste erreichen können.
5. Speichern Sie Datenbankexporte und Zugangsdaten außerhalb des Web-Stammverzeichnisses mit eingeschränkten Berechtigungen.

Wartungsmodus und robots.txt bieten keine vollständige Zugriffskontrolle. Ein Modul mit Passwortschutz für das Shop-Frontend schützt nicht jede Datei und jeden administrativen Endpunkt. Password Protection schützt die Anfrageverarbeitung im Frontoffice; die Hilfeseite erläutert diesen auf das Shop-Frontend begrenzten Umfang.

Verwenden Sie ausschließlich für Staging bestimmte Dienstzugangsdaten und einen Transport zum Abfangen von E-Mails. Minimieren oder anonymisieren Sie Kundendaten entsprechend den benötigten Tests. Erhalten Sie die Beziehungen und Formate, die aussagekräftige Tests erfordern: Das wahllose Löschen von Adressen oder Anpassungsdatensätzen kann Fehler im Bestellprozess verbergen. Bevorzugen Sie erfundene Testkunden, wenn deren Daten genügen. Beschränken Sie den Zugriff auf kopierte personenbezogene Daten und entfernen Sie veraltete Klone und Dumps.

Prüfen Sie, dass unberechtigte Anfragen weder ein Bild noch eine Admin-URL, eine Konfigurationssicherung oder einen Datenbankexport abrufen können. Testen Sie Ihre Zugriffskontrolle, bevor Sie die Anwendung starten lassen.

Eine passende Hosting- oder Containerumgebung wählen

Container

Fixieren Sie das genaue Anwendungs-/PHP-Image und die Datenbankversion, vorzugsweise über unveränderliche Image-Digests. Ein Image ohne Versionsangabe oder ein grob gefasstes Tag bildet die Produktion nicht nach. Verwenden Sie ein separates Staging-Volume und eine eigene Datenbank. Konfigurieren Sie den Datenbankhost der Anwendung ausdrücklich, etwa mit dem Compose-Dienstnamen db.

Veröffentlichen Sie einen lokalen Port nur bei Bedarf, beispielsweise 127.0.0.1:8080:80, hinter einem authentifizierten Zugangsweg. Die Veröffentlichung von 8080:80 macht den Port im Allgemeinen auf Host-Schnittstellen erreichbar. Beachten Sie Dockers Dokumentation zur Portbindung und setzen Sie ausgehende Verbindungskontrollen separat durch.

Starten Sie während des Imports nur die Datenbank. Warten Sie auf eine echte Bereitschaftsprüfung statt auf eine feste Wartezeit. Stellen Sie die Staging-Konfiguration der geklonten Anwendung bereit, bevor Sie deren Webdienst oder Worker starten. Prüfen Sie den Image-Entrypoint, damit automatische Installations- oder Startaufgaben nicht mit kopierten Produktionseinstellungen ausgeführt werden können.

Verwenden Sie zur Nachbildung einer alten Umgebung die tatsächliche produktive Datenbankversion und testen Sie anschließend einen unterstützten Upgrade-Pfad separat. MySQL 5.7 ist eine Alt-Abhängigkeit, kein neuer Staging-Standard. Teilen Sie keine Cache-/Sitzungsnamensräume mit der Produktion.

Subdomain im Hosting-Panel

Erstellen Sie eine private Subdomain mit eigenem Dokumentenstamm und eigener Datenbank. Wenden Sie Beschränkungen vor dem Import an. Prüfen Sie die tatsächlichen Berechtigungen des Tarifs: Der Name eines Panels bestimmt nicht die Docker-Verfügbarkeit, und einige Anbieter unterstützen Container.

Lokale Entwicklung

Docker, XAMPP, MAMP, WAMP oder eine lokale Linux-Umgebung können für Tests nützlich sein. Gleichen Sie relevante Laufzeitdetails ab und testen Sie plattformspezifisches Verhalten erneut in der Bereitstellungsumgebung. Die Bezeichnung des Betriebssystems allein entscheidet nicht über den Nutzen eines lokalen Tests.

Folgen Sie dem Docker-Leitfaden und dem Leitfaden zur lokalen Entwicklung für die Einrichtung der Umgebung.

Eine konsistente Datenbank und vollständige Dateien kopieren

Erstellen Sie eine Wiederherstellungssicherung und notieren Sie den Snapshot-Zeitpunkt. Für transaktionale InnoDB-Tabellen kann mysqldump --single-transaction einen konsistenten Snapshot liefern, ohne normale Schreibzugriffe während des gesamten Exports zu sperren. Nichttransaktionale Tabellen werden dadurch nicht konsistent gesichert und schützt nicht vor gleichzeitigen Schemaänderungen. Stimmen Sie Datei- und Datenbank-Snapshot bei veränderlichen Uploads und Downloads ab.

Verwenden Sie ein eingeschränktes Backup-Konto und eine sichere Client-Konfiguration oder Passwortabfrage. Vermeiden Sie Passwörter in Shell-Argumenten und Skripten. Prüfen Sie Abschluss des Exports, Exit-Status und Dateigröße, bevor Sie in die bestätigte Staging-Datenbank importieren. Warten Sie auf Datenbankbereitschaft und brechen Sie ab, wenn ein Import fehlschlägt.

Kopieren Sie versteckte Dateien, Module, Overrides, Themes, Bilder, Downloads, Uploads und individuelle Assets. Schließen Sie umgebungsspezifische Verbindungseinstellungen und Laufzeit-Caches gegebenenfalls aus. Diese lokalen Beispielpfade beschreiben einen bereits erstellten Snapshot und ein separates Staging-Stammverzeichnis:

rsync -av   --exclude='app/config/parameters.php'   --exclude='var/cache/'   --exclude='var/logs/'   /srv/prestashop-snapshot/   /srv/prestashop-staging/html/

Der abschließende Schrägstrich der Quelle kopiert den Verzeichnisinhalt einschließlich versteckter Dateien. Die Alternative cp -a /srv/prestashop-snapshot/. /srv/prestashop-staging/html/ enthält ebenfalls versteckte Dateien, kopiert aber auch Konfiguration, die Sie vor dem ersten Anwendungsaufruf ersetzen müssen.

Bestätigen Sie Quelle und Ziel vor der Synchronisierung. Prüfen Sie bei Aktualisierungen mit Löschfunktion einen Testlauf und schützen Sie Dateien, die nur zu Staging gehören. Wählen Sie niemals den produktiven Dokumentenstamm als Ziel.

Stellen Sie für PrestaShop 1.7 bis 9 ausdrücklich app/config/parameters.php mit reinen Staging-Datenbankzugangsdaten bereit. Die ältere Konfiguration von 1.6 ist config/settings.inc.php. Bewahren oder ersetzen Sie kryptografische Schlüssel bewusst und berücksichtigen Sie dabei die Kompatibilität von Passwörtern und verschlüsselten Daten. Das Kopieren von Schlüsseln rechtfertigt nicht, produktive externe Zugangsdaten beizubehalten.

Diagnostizieren Sie Importfehler anhand der tatsächlichen Datenbankausgabe. Prüfen Sie Versionen, Zeichensätze, Kollationen und DDL-Kompatibilität. SET NAMES utf8mb4 hinzuzufügen, ist keine allgemeine Reparatur für inkompatible Kollationen oder zuvor falsch kodierte Daten. Nutzen Sie die passenden Export- und Wiederherstellungsoptionen.

Alle Shop-URLs umschreiben und Integrationen bereinigen

Arbeiten Sie ausschließlich auf der bestätigten Staging-Datenbank, während Anwendungszugriffe und Jobs gestoppt bleiben. Ermitteln Sie das konfigurierte Tabellenpräfix und alle Shop-URLs sowie Konfigurationsdatensätze mit ihrem Geltungsbereich. Gehen Sie nicht von Shop-ID 1 aus.

Beginnen Sie mit einer rein lesenden Prüfung. Diese Beispiele verwenden das illustrative Präfix ps_:

SELECT id_shop_url, id_shop, domain, domain_ssl,
       physical_uri, virtual_uri, main, active
FROM ps_shop_url
ORDER BY id_shop, id_shop_url;

SELECT id_configuration, id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL')
ORDER BY id_shop_group, id_shop, name;

Erstellen Sie für jede relevante URL-Zeile eine ausdrückliche Zuordnung zum Staging-Hostnamen und physischen/virtuellen Pfad. Aktualisieren Sie die passenden Konfigurationszeilen anhand ihres tatsächlichen Geltungsbereichs oder ihrer IDs. Erhalten Sie die vorgesehene Multistore-Struktur. Prüfen Sie Moduleinstellungen, Weiterleitungen, Medienserver-Domains, Canonical-Einstellungen und fest codierte URLs auf verbleibende Produktionsziele. Führt eine URL weiterhin zur Produktion zurück, prüfen Sie Weiterleitungskette und Antwortheader: Eine alte Webserverregel, ein Reverse-Proxy oder eine CDN-Einstellung kann weiterleiten, bevor PrestaShop die Anfrage verarbeitet. Halten Sie Staging-Hostnamen und -Zertifikate vom Produktionsrouting getrennt.

1. Ersetzen Sie produktive Zahlungszugangsdaten durch Sandbox-Zugangsdaten oder deaktivieren Sie die Integration.
2. Deaktivieren Sie den Kauf von Versandetiketten und andere kostenpflichtige Versandaktionen. Nutzen Sie einen Testdienst, soweit verfügbar.
3. Deaktivieren oder isolieren Sie ERP/WMS-, Marktplatz-, Lieferantenbestands-, CRM-, Marketing-, Analytics- und ausgehende Webhook-Verbindungen.
4. Deaktivieren Sie den Core-Mailversand oder richten Sie unter Erweiterte Einstellungen > E-Mail einen Transport zum Abfangen ein. Decken Sie unabhängige Modul-SMTP-Clients und E-Mail-APIs durch nachgewiesenes Abfangen oder ausgehende Verbindungssperren ab.
5. Deaktivieren Sie Produktionsjobs in System-Cron, Timern, Hosting-Panels, Modul-Zeitplanern, Queue-Workern und externen Zeitplanern.
6. Deaktivieren Sie die Erstellung/Einreichung von Staging-Sitemaps im installierten Sitemap-Modul und entfernen Sie gegebenenfalls erzeugte Dateien, die ausschließlich für die Produktion bestimmt sind.
7. Nutzen Sie private Zugriffskontrollen sowie noindex-Header oder Robots-Regeln als zusätzliche Indexierungskontrollen.

Core-E-Mail-Einstellungen allein können nicht jeden unabhängigen Modultransport blockieren. DNS- oder URL-Umschreibungen allein können einen produktiven Zahlungsschlüssel nicht unschädlich machen. Lassen Sie ausgehende Beschränkungen bestehen, bis jede Integration geprüft ist.

Caches leeren und den isolierten Klon testen

Leeren Sie nach abgeschlossener Staging-Konfiguration und Bereinigung die zur Version passenden Anwendungscaches als Anwendungsbenutzer. In einem modernen Shop nutzen Smarty- und Framework-Caches umgebungsspezifische Pfade unter var/cache. Ältere Versionen haben andere Strukturen.

Verwenden Sie den unterstützten Cache-Leervorgang der Anwendung aus dem bestätigten Staging-Stammverzeichnis. Führen Sie ihn in einem Container über den Anwendungsdienst in dessen Shop-Arbeitsverzeichnis aus. Docker exec selbst expandiert keine Shell-Platzhalter; eine Host-Shell kann einen nicht in Anführungszeichen gesetzten Platzhalter im falschen Dateisystem expandieren. Vermeiden Sie pauschale Löschrezepte.

Setzen Sie den OPcache der Staging-Web-Laufzeit über das Hosting-/Dienstverfahren zurück, wenn die Bereitstellungseinstellungen dies erfordern. Ein reiner CLI-Reset setzt normalerweise nicht den PHP-FPM-Cache zurück. Prüfen Sie Berechtigungen und Cache-Neuaufbau, bevor Sie den beschränkten Webzugang öffnen.

1. Bestätigen Sie, dass die Anwendung ausschließlich die Staging-Datenbank verwendet.
2. Prüfen Sie die Startseiten-, Kategorie-, Produkt- und Admin-URLs jedes Shops auf Produktionsweiterleitungen.
3. Untersuchen Sie Protokolle auf Datenbank-, Berechtigungs-, Template- und PHP-Fehler.
4. Führen Sie eine Testbestellung mit jeder Sandbox-Zahlungsart durch, einschließlich asynchroner Zahlungsbenachrichtigungen, sofern verwendet. Bestätigen Sie, dass der Anbieter die Staging-Callback-URL nutzt und den erforderlichen Endpunkt erreichen kann, ohne den restlichen Klon offenzulegen. Prüfen Sie Steuern, Versand, Rabatte, Bestand und Erstattungen.
5. Lösen Sie eine Test-E-Mail aus und bestätigen Sie, dass sie nur das Abfangsystem erreicht.
6. Prüfen Sie versuchte ausgehende Verbindungen und bestätigen Sie, dass produktive Dienste gesperrt bleiben.
7. Prüfen Sie, dass Jobs gestoppt bleiben, außer denen, die ausdrücklich für einen Test aktiviert wurden.

Nutzen Sie ein separates Browserprofil, um Bedienfehler bei der Arbeit mit Produktion und Staging zu reduzieren. Prüfen Sie Cookie-Namen und Domain-Attribute, besonders wenn Staging und Produktion dieselbe übergeordnete Domain teilen: Manche Cookies können beide Hosts erreichen. Halten Sie ihre Sitzungen mit dem separaten Browserprofil auseinander. Kennzeichnen Sie Staging-Hostnamen und Verwaltung deutlich.

Ein Update eines Versandmoduls durchspielen

Angenommen, Ihr britischer und französischer Shop verwenden dasselbe Versandmodul und eingegangene Bestellungen werden an ein Lager exportiert. Dokumentieren Sie vor dem Update für jeden Markt einen repräsentativen Warenkorb: Adresse, Sprache, Währung, Produkte, Versanddienst, Versandkosten und Endsumme. Nehmen Sie einen Warenkorb auf, den die Einschränkungen des Versanddienstes ausschließen sollten. Daraus entstehen erwartete Ergebnisse, statt lediglich zu prüfen, ob sich der Bestellprozess öffnet.

Installieren Sie die vorgesehene Version auf der isolierten Kopie und vergleichen Sie dieselben Warenkörbe. Schließen Sie eine Sandbox-Zahlung ab und prüfen Sie Versanddienst, Lieferadresse und Exportnutzdaten der entstandenen Bestellung, ohne sie an das produktive Lager zu senden. Bestätigen Sie, dass kein kostenpflichtiges Etikett gekauft wurde. Gibt es für einen vereinbarten Versandtarif keine Testentsprechung, dokumentieren Sie diese Lücke und vereinbaren Sie eine kontrollierte Produktionsprüfung separat.

Prüfen Sie neben sofortigen Anfragen auch wartende Exporte. Eine gesperrte Lagerverbindung kann Aufgaben zur Wiederholung in der Warteschlange lassen; verbinden Sie diese Staging-Warteschlange später nicht mit dem Live-Konto, um zu sehen, ob sie abgearbeitet wird. Nutzen Sie ein isoliertes Testziel oder prüfen Sie die wartenden Nutzdaten. Bewahren Sie erwartete und tatsächliche Ergebnisse zusammen mit der Paketversion auf, damit Mitarbeiter diese Änderung anhand von Nachweisen abnehmen können.

Ein Modul testen und die Bereitstellung proben

1. Lesen Sie die Anforderungen des Moduls an Version, PHP, Theme, Multistore und Lizenz. Prüfen Sie Paketinhalt und externe Abhängigkeiten. Eine Zeichenfolgensuche nach eval oder Base64-Dekodierung ist keine vollständige Sicherheitsprüfung.
2. Erstellen Sie einen Staging-Wiederherstellungs-Snapshot und dokumentieren Sie Ausgangsseiten und Laufzeiten.
3. Installieren Sie die genaue Release-ZIP über den Modulmanager. Prüfen Sie Installationsfehler, erstellte Tabellen, Hook-Registrierung und Protokolle.
4. Speichern Sie die Konfiguration und testen Sie die vorgesehene Funktion. Prüfen Sie nach Bedarf Start-, Kategorie-, Produkt-, Warenkorb-, Checkout- und Kontoseiten.
5. Testen Sie Mobilgeräte, unterstützte Sprachen/Währungen und jeden von Ihnen genutzten Multistore-Kontext. Untersuchen Sie Browserfehler und fehlgeschlagene Anfragen.
6. Durchlaufen Sie Sandbox-Kauf, Stornierung und Erstattung. Prüfen Sie wichtige bestehende Module neben der neuen Funktion.
7. Vergleichen Sie wiederholte Laufzeiten und Seitenverhalten unter gleichwertigen Cache- und Traffic-Bedingungen.
8. Testen Sie Update-, Deaktivierungs- und Deinstallationsverhalten auf einer entbehrlichen Kopie. Einige Module behalten Geschäftsdaten absichtlich bei; vergleichen Sie die Bereinigung mit der dokumentierten Richtlinie.

Bestätigen Sie für die jeweilige Lizenz die Berechtigungen für Produktionsdomain, Staging-Domain, localhost und Testbetrieb. Gehen Sie nicht davon aus, dass jedes Modul unbegrenzt kostenlose lokale Aktivierungen oder denselben Demozeitraum bietet. Nutzen Sie bei Fragen zu mypresta.rocks-Lizenzen den Lizenzleitfaden oder kontaktieren Sie den Support.

Wenn Sie ein vorhandenes Paket installieren und prüfen lassen möchten, deckt der PrestaShop Module Installation & Configuration Service die vereinbarte Konfiguration und den Kunden- oder Mitarbeiterablauf ab.

Das Ergebnis abnehmen und die Produktionsumstellung planen

Lassen Sie den Betreiber oder einen benannten Tester das fachliche Ergebnis abnehmen; der Entwickler verantwortet die technischen Nachweise. Halten Sie ungelöste Fehler und ungetestete Integrationen sichtbar; eine fehlerfreie Installation ist keine Abnahme des Kaufablaufs.

1. Dokumentieren Sie den getesteten Shop-Snapshot, die Laufzeit, Paketversionen und Konfigurationsänderungen. Eine spätere Aktualisierung oder Codeänderung kann dieses Ergebnis ungültig machen.
2. Bewahren Sie erwartete und tatsächliche Ergebnisse für die betroffenen Märkte, Geräte und Integrationen auf, einschließlich Fehlern und Wiederherstellungswegen.
3. Bestätigen Sie, wer die Bereitstellung durchführt, wer die Umstellung stoppen darf und wer anschließend Bestellungen, Zahlungen und Auftragsabwicklung überwacht.
4. Vereinbaren Sie das Bereitstellungsfenster und etwaige Pausen für Bestellungen, Mitarbeiterbearbeitungen oder Importe. Schätzen Sie die Unterbrechung anhand der Erprobung, statt eine feste Dauer zu versprechen.
5. Demonstrieren Sie die Wiederherstellung auf einer entbehrlichen Kopie und definieren Sie den Fehler, der sie auslöst. Berücksichtigen Sie in diesem Plan Datenbankänderungen und neue Geschäftsvorgänge.

Erstellen Sie vor der Produktionsbereitstellung ein frisches, wiederherstellbares Produktionsbackup und vereinbaren Sie das Rücknahmeverfahren. Stellen Sie das getestete Artefakt und die vorgesehene Konfiguration in einem geeigneten Zeitfenster bereit. Führen Sie einen kurzen Funktionstest in der Produktion durch und überwachen Sie Logs und Bestellfluss. Halten Sie reine Staging-Zugangsdaten, Testbestellungen und Staging-spezifische Beschränkungen aus der Produktionskonfiguration heraus. Behalten Sie die vorgesehenen produktiven Datenschutz- und Einwilligungseinstellungen bei.

Release-Dateien und abschließende Geschäftsdaten getrennt halten

Stellen Sie bei einer Modul- oder Theme-Änderung die getesteten Dateien und vorgesehenen Einstellungen über das unterstützte Installations- oder Updateverfahren auf den aktuellen Produktionsdaten bereit. Ersetzen Sie die Live-Datenbank nicht durch die Staging-Datenbank. Testbestellungen, anonymisierte Kunden und alte Bestandswerte gehören nicht in die Produktion.

Erproben Sie bei einer Versionsmigration oder einem Ersatzshop den abschließenden Datenabgleich separat. Ermitteln Sie, was sich seit dem Snapshot geändert hat: Bestellungen, Kunden, Bestand, Katalogbearbeitungen, Erstattungen und Integrationszustand. Nutzen Sie das unterstützte Verfahren der Migration für die abschließende Kopie oder Delta-Übernahme und berücksichtigen Sie Schemaunterschiede. Falls kein unterstütztes Delta-Verfahren existiert, erproben Sie eine Schreibpause für den abschließenden Produktions-Snapshot, die Migration und Validierung und vereinbaren Sie diese Unterbrechung vor der Freigabe der Umstellung. Eine ungeprüfte Zusammenführung ausgewählter Tabellen kann Beziehungen beschädigen, selbst wenn die sichtbare Bestellanzahl übereinstimmt.

Koordinieren Sie bei der vereinbarten Umstellung Schreibvorgänge im Bestellprozess, Mitarbeiterarbeiten, Importe, Worker und verzögerte Zahlungsbenachrichtigungen, damit sich Geschäftsvorgänge nicht auf alten und neuen Shop verteilen. Gleichen Sie die abschließenden Datensätze und Integrationswarteschlangen ab, bevor Sie die Auftragsabwicklung freigeben. Nach der Wiedereröffnung kann die Wiederherstellung eines älteren Backups neue Bestellungen oder Zahlungsaktualisierungen verlieren; die Wiederherstellung muss diese Vorgänge berücksichtigen. Alte PHP-Dateien allein können eine inkompatible Datenbankmigration nicht rückgängig machen.

Fragen an Entwickler oder Agentur

• Welche Unterschiede zur Produktion bleiben auf Staging bestehen und welche Nachweise verhindern sie?
• Welche Dateien, Einstellungen und Schemaänderungen stellen Sie bereit und welche Daten bleiben bestehen?
• Wie werden die abschließenden Bestellungen, Zahlungen, Erstattungen und Bestandsänderungen abgeglichen, wenn der gesamte Shop umzieht?
• Wo liegen die Abnahmenachweise und Wiederherstellungsschritte und wer verantwortet einen Vorfall nach der Wiedereröffnung?

Die Isolation bei jeder Aktualisierung wiederholen

Aktualisieren Sie vor wesentlichen Tests, wenn der Klon die Produktion nicht mehr abbildet. Wählen Sie den Rhythmus anhand Ihrer Release- und Katalogänderungen statt nach einem festen Versprechen zur Einrichtungs- oder Aktualisierungsdauer.

1. Sichern Sie alle Arbeiten, die die Aktualisierung überstehen müssen.
2. Wenden Sie Zugriffs- und ausgehende Beschränkungen erneut an und stoppen Sie anschließend Anwendungszugriffe, Jobs und Worker.
3. Beschaffen und prüfen Sie einen frischen Snapshot. Brechen Sie bei Export-, Übertragungs- oder Importfehlern ab.
4. Importieren Sie in die Staging-Datenbank und synchronisieren Sie die bestätigten Staging-Dateien.
5. Stellen Sie Staging-Verbindungseinstellungen erneut bereit und ordnen Sie jede Shop-URL zu.
6. Wenden Sie E-Mail-Abfangen, Sandbox-Zugangsdaten, Zeitplanersteuerung, Datenminimierung und Integrationsbeschränkungen erneut an. Die neue Datenbank hat Produktionseinstellungen wiederhergestellt.
7. Leeren Sie Staging-Caches und prüfen Sie Laufzeitberechtigungen.
8. Wiederholen Sie Isolations- und Kaufablaufprüfungen, bevor Sie die eingeschränkte Nutzung aktivieren.

Automatisieren Sie dies in Schritten, die im Fehlerfall den Zugriff gesperrt lassen: Prüfen Sie Datenbankbereitschaft, Exit-Status der Befehle und nicht leere Backups und stoppen Sie bei jedem Fehler. Melden Sie eine erfolgreiche Aktualisierung erst nach der Validierung. Halten Sie Produktions-Snapshot und Staging-Konfiguration getrennt, damit eine Aktualisierung den Zugriff auf produktive Dienste nicht unbemerkt wiederherstellen kann.

Nutzen Sie den Leitfaden zum Modultesten und den Backup-Leitfaden für die Pflege Ihrer Release-Checkliste.

Fragen von Shop-Betreibern

Was tun, wenn eine Integration keine Sandbox hat?

Nutzen Sie einen isolierten Ersatz oder prüfen Sie die Anfrage, ohne sie abzusenden, und kennzeichnen Sie die Live-Interaktion als ungetestet. Vereinbaren Sie nötige Produktionsprüfungen mit dem Anbieter und der für Abrechnung oder Auftragsabwicklung verantwortlichen Person. Eine gesperrte Anfrage belegt die Abschottung, keine erfolgreiche Integration.

Darf der Entwickler Staging während der Abnahme durch Mitarbeiter aktualisieren?

Vereinbaren Sie ein Testfenster und kennzeichnen Sie den zu prüfenden Build. Eine Aktualisierung ändert Daten und kann Konfigurationen zurücksetzen; informieren Sie daher die Tester und wiederholen Sie die betroffenen Prüfungen. Kombinieren Sie Ergebnisse verschiedener Builds nicht so, als beschrieben sie dieselbe Version.

Warum kann sich Staging schneller als der Live-Shop anfühlen?

Es kann weniger Besucher, andere Ressourcen oder anderes Cache- und externes Dienstverhalten haben. Dokumentieren Sie diese Unterschiede vor Zeitvergleichen. Ein Kauf auf wenig ausgelastetem Staging ist ein nützlicher Funktionsnachweis, belegt aber keine Produktionskapazität.

Wann sollten wir eine Staging-Kopie entfernen?

Behalten Sie sie nur, solange sie einem vereinbarten Test- oder Supportzweck dient. Entfernen Sie bei ihrer Stilllegung die erreichbare Anwendung und veraltete Dumps, widerrufen Sie ihre Zugangsdaten und entfernen Sie ihre Jobs und Zugriffsberechtigungen. Behandeln Sie aufbewahrte Wiederherstellungsbackups gemäß deren eigener Aufbewahrungsrichtlinie.