Shopware 6.4 to 6.5 (update duuh!)

Shopware 6.4 auf 6.5 update: ein Unterfangen, das sich als ebenso herausfordernd wie eine Expedition zum Mount Everest erweist (fast). Doch wie heißt es so schön? Kein Aufstieg ohne Anstrengung und kein Update ohne ein paar nervenaufreibende Momente. Hier ist unsere Geschichte.

Systemaufstellung

  • Verfügbarkeit: Wir nutzen das Blue-Green-Entwicklungskonzept durch Deployer, um Änderungen sicher und nahtlos zu implementieren
  • Versionierungssystem: Git-Versionierungssystem ermöglicht eine transparente und konsistente Verwaltung des Quellcodes
  • Deployment: Eine gut strukturierte Deployment-Pipeline sorgt für eine effiziente Bereitstellung von Updates und neuen Funktionen
  • Server: Wir betreiben separate Staging- und Live-Umgebungen auf unterschiedlichen Hostern
  • Versionen:
    • Aktuelle Shopware-Version: 6.4.18.0
    • Ziel-Shopware-Version: 6.5.7.3 (zum Zeitpunkt des Schreibens)

Die Migration wird zunächst im Staging durchgeführt, bevor sie auf die Live-Umgebung übertragen werden. Anschließend wird die Migration im Live-Betrieb wiederholt.

Warum ist das gut?

  • Früherkennung von Problemen: Durch die Durchführung der Migration zuerst im Staging können potenzielle Probleme identifiziert und behoben werden, bevor sie Auswirkungen auf die Live-Umgebung haben. Als Bonus erhalten wir eine Step für step update Einleitung um die Live Instanz leichter zu aktualisieren.
Warum ist das schlecht?
  • Zeitaufwand: Der Prozess der Migration erfordert mehr Zeit und Ressourcen, da wir das Update zweimal durchführen müssen.

Todos (der plan)

Unsere //Todo’s:

  • Eigenentwickelte Plugins aktualisieren
  • Shopware aktualisieren
 
Einfach, oder?
 

Unterbrechungsfreies Update

Um Unterbrechungen der Seite zu minimieren, verwenden wir folgenden Ansatz:

  1. Aufsetzen einer neuen (Deployer)-Release-Struktur (FS).
  2. Duplizieren der Live-Datenbank
  3. Erstellen einer temporären Domain für das Update und Verweisen auf das neue FS + DB
  4. Durchführen des Updates auf der temporären Domain (Code + DB).
  5. Weiterleitung der Live-Seite auf eine “maintenance.html” (vHost auf andere Verzeichnis) – ab diesem Punkt ist die Seite offline
  6. Verknüpfen des neuen FS mit der Live-DB (SW 6.4.20).
  7. Durchführen der DB-Migrationen (live db upgrade)
  8. Übernahme des neuen Release-FS als neues Live-FS
  9. Caffè fertigsaufen

Vorgehensweise visualisiert:

Ansatz im detail

#Aufsetzen einer neuen (Deployer)-Release-Struktur (FS).

#step
Deployer Release-Struktur duplizieren. Hier kannst du mehr über Deployer lernen.
Um zu checken, ob alle Links ausgetauscht sind, oder ob einfach die verlinkungen richtig sind, nutze einfach diesen Bash-Befehl:

				
					# find the links
ls -lR . | grep '^l'
				
			

#Durchführen des Updates auf der temporären Domain (Release-FS + Temp-DB)

#step
Für dieses Update willst du alle Plugins deaktivieren. Hier ist der Befehl dafür. Erstmal finde heraus welche plugins überhaupt Aktiv und Installiert sind:

				
					# Zeige alle Plugins, die aktiviert oder installiert sind.
./bin/console plugin:refresh | grep "Yes"
				
			

Ergebnis kopieren und mit ein bisschen Magie und VS Code oder ChatGPT eine Liste der Plugin-Namen erzeugen, mit einem Leerzeichen getrennt.
Damit kannst du nun nutzen, um alle Plugins zu deaktivieren.

				
					# liste
... SwagPayPal SwagExtensionStore ...

# plugins deaktivieren
./bin/console plugin:uninstall SwagPayPal SwagExtensionStore
				
			


#step 
Shopware auf 6.4.20.0 übers Backend aktualisieren. Ja ich weiß, wir haben einem Pipeline (deployment) System der die benötigten Dateien (Symfony) auf die 6.4.20 aktualisieren könnte, aber das heißt erstmal der Pipeline mit SW6.4.20 starten und dann nochmal auf 6.5.8.2 ist nicht zielführend. Das Update auf Version 6.4.20.0 ist sicher über das Backend möglich.

 

#Potenzielle Fehler: Update abbricht.

Die dateien nuter ./bin/ haben nicht die Execution Flag. Dafür:

				
					 chmod +x ./bin/*
				
			

Zusätzlich schlagen folgende Migrationen fehl (im Staging), daher sollte jemand in der Datenbank prüfen und diese als durchgeführt markieren können.

				
					 INSERT INTO `migration` (`class`, `creation_timestamp`, `update`, `update_destructive`, `message`) VALUES
    ('Shopware\\Core\\Migration\\V6_5\\Migration1673420896RemoveUndefinedSalutation', 1673420896, '2024-01-18 13:28:51.442115', NULL, NULL),
    ('Shopware\\Core\\Migration\\V6_5\\Migration1688717599UpdateCreatedByIdAndUpdatedByIdInOrderAndCustomer', 1688717599, '2024-01-19 13:35:11.000000', NULL, NULL);
				
			


#step

Pipeline  mit die Shopware 6.5.8.2 starten (auf die gespiegelte FS).
Nun hast du Shopware auf die letzte Version. (Falls du kein Pipeline-Setup hast, na… das ist ne andere Geschichte.  Es sollte einfacher sein, aber das ist es nicht. Teilen Sie uns dies mit, und wir werden den Beitrag erweitern, um auch ein Update ohne Pipeline einzubeziehen).
 
#step
Als Nächstes aktualisierst du alle Plugins per hand 🤮 auf die letzte version. Das geht leider noch nicht über die Konsole.
… 3 Stunden später
 
  • Plugins installieren/aktivieren 
  • Theme neu zuweisen
  • Plugin Migrationen starten (./bin/console database:migrate — all <Plugin Name>) 
 
				
					./bin/console plugin:activate SwagPayPal SwagExtensionStore

# migrationen starten 

./bin/console plugin:activate --all SwagPayPal
./bin/console plugin:activate --all SwagExtensionStore
...

				
			

Glückwunsch, deine temporäre Domäne rockt die letzte Shopware 6.5 Version.

 

#Nun das letzte Teil: Live Stellung

Nun kannst du deinen Zwischenstand testen. Listenansicht, Detailansicht, Login, Bestellungen und E-Mail (durch Passwort zurücksetzen) sind die Hauptthemen, die du nicht vergessen solltest, während du testest. Jetzt kommt der zweite Teil, in dem die Live-Domäne heruntergefahren wird.
 
Warum down? Natürlich könntest du diese Instanz live schalten und fertig sein (mit 0 sekunden downtime). Dies führt jedoch oft zu Datenverlust, da deine Seite inzwischen weitere Einträge in der Datenbank generiert hat. Diese möchtest du auch mitnehmen, daher:
 
#step
  • Die Live-Seite in den Wartungsmodus versetzen
  • Leite deine Live-Domäne auf ein Verzeichnis um, in dem du eine index.html-Datei mit dem Wartungsmodus hast. Du findest eine unter public/recovery/update/maintenance.html, oder verwende einfach diese Datei)
  • Die Live-Datenbank duplizieren oder ein Backup davon erstellen
 
				
					#maintenance seite direkt auf dem server herunterladen 

curl -o index.html  https://zenkod.de/wp-content/uploads/2024/02/maitenance-index.html

## oder

wget -O index.html  https://zenkod.de/wp-content/uploads/2024/02/maitenance-index.html
				
			

nun bist, ist die Seite in Wartungsmodus.

  • neue FS auf die live DB schalten (.env)
  • Plugins über die Datenbank deaktivieren (die bin/console ist meistens nicht mehr brauchbar)
				
					UPDATE `plugin` SET active = 0 WHERE active = 1;
				
			
  • Core Migrationen starten
				
					./bin/console database:migrate --all
				
			
  • Plugins wieder aktivieren (diesmal über konsole)
 
				
					./bin/console plugin:activate SwagPayPal SwagExtensionStore
./bin/console plugin:update SwagPayPal SwagExtensionStore

#cache leeren
./bin/console cache:clear

#Dreieckstausch zwischen Live FS und Deployer FS 
mv live _live 
mv update live

				
			
  • Richte die Live-Domäne wieder auf dein Live-Dateisystem aus.
  • Nun hast du deine Live-Seite aktualisiert. Diese befindet sich jedoch noch im Wartungsmodus. Teste deine Seite noch einmal, und wenn du bereit bist, nimm den Wartungsmodus heraus.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kontaktieren Sie uns

von 8:00 – 18:00 erreichbar