Neu JTL Shop 4.04 auf 4.06 > Wie kann man ein Update auf einem Entwicklungs-Server testen?

[Ralf Römling]

Hallo Zusammen,
ich bin gerade in der Vorbereitung einen angepassten JTL Shop 4.04 auf 4.06 upzudaten.

Da ich den Anpassungen nicht selbst gemacht habe, würde ich das ganze gerne vorab auf einem Entwicklungsserver testen. Gibt es dafür evt. ein HowTo bzw. ein Best-Practice-Dokument?

Da ich den Datenabgleich und WaWi noch nicht geblickt habe, hätte ich die Befürchtung ein Datenkuddelmuddel zu verursachen, wenn sich evt. beide Shops mit der WaWi verbinden. Ist die Angst berechtigt?

Mein geplantes Vorgehen wäre derzeit:
- Shop in Wartungsmodus stellen
- Datei-Backup erstellen
- Datenbank mit phpmyadmin exportieren
- Alles auf der Testumgebung wieder einspielen.

Was wäre danach noch zu tun bzgl. URL-Anpassungen im System, htacces, o.ä.?

Danke schon mal vorab für Eure Hilfe

Viele Grüße,
Ralf

 

[Tomas]

Hallo Ralf,

ich kann hierbei nur für mich sprechen, da vermutlich jeder so seine eigene Arbeitsweise hat.

Wir haben neben unserer Produktiven Wawi eine Entwicklungs bzw. Test Wawi lokal auf meinem Entwicklungsrechner.
Dafür habe ich einfach eine JTL-Neuinstallation auf dem Rechner ausgeführt und ein Backup der Produktiv-Datenbank eingespielt.
Man muss aber alle kritischen Verbindungen entfernen. EazyAuction, die Verbindung zum Live- Shop und die E-Mail Adressen, damit beim testen nicht versehentlich irgendwas raus geht.

Der Vorteil bei einer Wawi für die Entwicklung sind meiner Meinung nach:
- dass du keine Multishop Lizenz brauchst, falls du nur einen Shop betreibst. https://www.jtl-software.de/jtl-store/erweiterungen/multishop-jahreslizenz
- dass du dir keine Sorgen beim Testen machen brauchst
- dass du dir deine Produktiv-Datenbank nicht zumüllst mit irgendwelchen Test-Aufträgen etc.

Was den Shop an sich angeht würde ich eine saubere Neuinstallation machen und nicht einfach die DB kopieren.
Dann mit dem JTL-Backup-Plugin alle Einstellungen in den neuen Shop portieren. https://guide.jtl-software.de/jtl-shop/shop-erweitern/jtl-backup-plugin/
Du kannst dann die Test-Wawi mit dem Test-Shop verbinden und los testen was das Zeug hält, ohne dass deine Produktive Umgebung in irgendeinem Zusammenhang steht.

VG
Tomas

 

[FPrüfer]

Was den Shop an sich angeht würde ich eine saubere Neuinstallation machen und nicht einfach die DB kopieren.
Dann mit dem JTL-Backup-Plugin alle Einstellungen in den neuen Shop portieren. https://guide.jtl-software.de/jtl-shop/shop-erweitern/jtl-backup-plugin/
Du kannst dann die Test-Wawi mit dem Test-Shop verbinden und los testen was das Zeug hält, ohne dass deine Produktive Umgebung in irgendeinem Zusammenhang steht.

Die Testszenarien und damit auch das Vorgehen unterscheiden sich jedoch, ob ich grundsätzlich ein Testsystem für Eigenentwicklungen einrichten, oder ob ich den Updatevorgang selbst testen möchte. Für Letzteres ist das kopieren der Shop-DB schon richtig, da das bei einem Update auch passieren würde bzw. dort ja die bestehende DB verwendet wird. Für diesen Test kann man die Anbindung an die Wawi auch erstmal außen vor lassen. Mein Vorschlag wäre deshalb:
- Alle Dateien der bestehenden Shop-Installation auf das Testsystem kopieren.
- In der config.JTL-Shop.ini.php und der .htaccess die URLs, ggfs. Pfade und die DB-Zugangsdaten anpassen.
- Ein Backup der Live-DB erstellen und im Testsystem einspielen.

Jetzt sollte beim Aufruf der Test-URL der Test-Shop ein 1:1 Klon des Live-Systems sein. Nun kann man im Backend des Test-Shop über "Shopdaten zurücksetzen" noch alle Kundendaten und ggfs. noch Bestellungen und Verfügbarkeitsanfragen löschen, damit beim "Rumspielen" nicht aus Versehen E-Mails an echte Kunden verschickt werden.
Zum Testen des Updates kann man jetzt auf dem Testsystem genauso vorgehen, wie man es im Live-System machen würde. Also Shopdateien über die Alten installieren, anschließend im Backend das Datenbank-Update ausführen, alle eigenen Anpassungen und ggfs. Plugin-Updates, ... etc. machen. Je nachdem ob und was schief geht, kann man diesen Vorgang sooft wiederholen, bis man eine Strategie hat, die den besten Erfolg und die kürzeste Ausfallzeit verspricht.

 

[Tomas]

Die Testszenarien und damit auch das Vorgehen unterscheiden sich jedoch, ob ich grundsätzlich ein Testsystem für Eigenentwicklungen einrichten, oder ob ich den Updatevorgang selbst testen möchte.

Da hast du allerdings Recht, da habe ich nicht drüber nachgedacht. Ich hatte direkt eine komplette Testumgebung im Kopf...war im nachhinein aber auch gar nicht wonach er gefragt hat.

 

[Ralf Römling]

Hallo Tomas, Hallo Herr Prüfer,
danke für das Feedback und wie Herr Prüfer schon richtig geschrieben hat, geht's darum, den Update-Prozess zu testen ohne Daten in die Wawi zurückzuspielen oder (das war mir gar nicht klar) evt. Mails an Kunden zu versenden.

@FPrüfer : Was muß ich denn noch konfigurieren, damit das nicht passiert und die Test-Umgebung wirklich still bleibt?

 

[FPrüfer]

Hallo,

Was muß ich denn noch konfigurieren, damit das nicht passiert und die Test-Umgebung wirklich still bleibt?

Wenn in der Testumgebung die Kunden und Newsletterempfänger gelöscht werden, sollten eigentlich keine Mails an externe Personen mehr verschickt werden. Ggfs. kann man dann in den E-Mail-Einstellungen noch ein reines Testkonto für die "Master-E-Mail-Adresse" hinterlegen. Wenn man nicht möchte, das alle Nutzer mit Backendzugriff im Live-System kann man im Testsystem noch die Backend-Nutzer in der "Benutzerverwaltung" anpassen. Wenn dann doch mal eine Test- Wawi angebunden wird, dann sollte auch noch die Tabelle tverfuegbarkeitsbenachrichtigung geleert werden, um nicht versehentlich eine Verfügbarkeitsbenachrichtigung auszulösen.

 

[raoul75]

Ein kleiner Hinweis noch zum Thema Entwicklungsserver: wir haben das in der Vergangenheit meist mit einem Inselsystem ohne Internetzugang gemacht auf dem XAMPP (gibts auch für Windows) installiert wurde. XAMPP simuliert einen Apache Webserver und bringt PHP 7, mySQL/mariaDB und alle anderen notwendigen Features mit. Auf dem gleichen Rechner kann testweise dann auch eine JTL Wawi installiert werden, die den Abgleich mit dem (virtuellen) Apache Webserver durchführt. Auf dem Webspace des (virtuellen) Apache Webservers muss man dann nur noch einen Dump der aktuellen JTL Shop Installation einspielen, die Datenbank übernehmen, alle Einstellungen an den realen Webserver anpassen und dann kann das Testen losgehen. In der Vergangenheit war das für uns bei allen Shop-Änderungen ein sehr hilfreiches Tool.

 

[Ralf Römling]

Yep, gute Lösung, allerdings möchte der Kunde die Unterschied zwischen der upgedateten Version und dem Live-System einsehen. (Das ginge natürlich auch per Screencast, aber zwei Instanzen im Web sind dann doch einfacher).

Grundsätzlich bin ich aber bei Dir, was xampp angeht. In einer virtuellen Maschine gehen dann ja auch schnelle Snapshot-Sicherungen, usw..

 

[Ralf Römling]

Sodala, nun wollte ich meine Testumgebung einrichten und dem Shop updaten gemäß (Anleitung), jedoch kommt beim Import der Datenbank in phpmyadmin dieser Fehler:

CREATE ALGORITHM=UNDEFINED DEFINER=`PW123456`@`%` SQL SECURITY DEFINER VIEW `elmar_merkmale_temp_views`  AS  select `merke`.`kArtikel` AS `kArtikel`,group_concat(distinct `am`.`cName`,',,',`aw`.`cWert` order by `am`.`nSort` ASC separator '||') AS `Merkmale` from (`tmerkmalwertsprache` `aw` left join (`tmerkmal` `am` left join `tartikelmerkmal` `merke` on((`merke`.`kMerkmal` = `am`.`kMerkmal`))) on((`merke`.`kMerkmalWert` = `aw`.`kMerkmalWert`))) group by `merke`.`kArtikel`

MySQL meldet:
#1227 - Kein Zugriff. Hierfür wird die Berechtigung SUPER benötigt

Übergehe ich diesen und versuche das DB-Update im Shop, bekomme ich diesen Fehler:

Ihre aktuelle Shopversion
     System: 4.06
     Datenbank: 4.04
Starte Update
     Update auf Migration: Add news category image erfolgreich
     Update auf Migration: Added option for dimension of articles erfolgreich
     Update auf Migration: Added new group description tab and sorting options erfolgreich
     Update auf Migration: Add new link types erfolgreich
     Update auf Migration: 404 to hidden linkgroup erfolgreich
     Update auf Migration: Add lang key dimensions_2d erfolgreich
     Update auf Migration: Lang vars poll coupon erfolgreich
     Update auf Migration: Dynamic options sources erfolgreich
     Update auf Migration: Add unique index tverfuegbarkeitsbenachrichtigung erfolgreich
     Update auf Migration: Add bisactive to link erfolgreich
     Update auf Migration: Add export format cache option erfolgreich
Fehler bei Update: SQLSTATE[42000]: Syntax error or access violation: 1091 Can't DROP 'PRIMARY'; check that column/key exists

Hat jemand eine Idee, was hier falsch läuft und wie ich dies abstellen kann?

 

[FPrüfer]

Hallo,
die View elmar_merkmale_temp_views ist kein Shopbestandteil. Die muss also mal der User "PW123456" in der Shopdatenbank angelegt haben, so dass sie beim Export mit ins Backup gewandert ist.
Zu dem Update-Fehler: Welche MySQL-Version wird verwendet? Offensichtlich scheitert dort die Migration_20160608112900 bei der ein neuer Primärschlüssel für die Tabelle tlink angelegt wird.

 

[Ralf Römling]

Hallo,
das ist mal spannend, weil ich nicht glaube, das der Kunde an seiner DB rumgeschraubt hat Kann das nicht mit dem Shopinfo-Export-Modul zu tun haben? Meinen Sie, ich kann den View einfach löschen?

Der Test-DB-Server ist wie folgt konfiguriert:
Datenbank-Server

• Server-Typ: MariaDB
• Server-Version: 10.1.38-MariaDB-0+deb9u1 - Debian 9.8
• Protokoll-Version: 10
• Server-Zeichensatz: UTF-8 Unicode (utf8)

Webserver

• Apache/2.4.25 (Debian)
• Datenbank-Client Version: libmysql - mysqlnd 5.0.12-dev - 20150407 - $Id: b5c5906d452ec590732a93b051f3827e02749b83 $
• PHP-Erweiterung: mysql mbstring
• PHP-Version: 7.0.33-0+deb9u3

phpMyAdmin

• Versionsinformationen: 4.8.2, aktuelle stabile Version: 4.8.5

 

[Ralf Römling]

Das Problem hat sich geklärt:

In der exportierten SQL-Datei ist für die Anlage des Views der berechtigte DEFINER in der Form db-user@db-server angegeben.

mariadb scheint beim Export hier eine Wildcard "%" einzufügen, die aber beim Import nicht automatisch mit der neuen IP befüllt wird.

Nach manuellem Eintragen der DB-Server-IP läuft der Import durch.