Aktualisierung der Daten auf Produktionsserver

Eddy Wolbert

Hallo TYPO3-Kollegen, vielleicht hat hier mir jemand einen Tipp bzgl. Datenaktualisierung auf dem Produktionsserver.

Habe den Deploymentprozess nach Wolfgangs Video nachgebaut. Auf Produktionsseite wurde eine Subdomain bei Mittwald eingerichtet.

Wird nun nach einer Änderung auf lokaler Ebene (z.B. neue Seite anlegen, Dateiänderung etc.) git push abgesetzt, läuft die Pipeline bei gitlab ohne Fehler durch und auch die Änderungen im Repository sind dort sichtbar.
Auf Produktionsseite wird, wie erwartet, ein neuer Releasestand erstellt, jedoch sind dort die Änderungen nicht durchgeführt worden, d.h. die Inhalte entsprechen dem Vorgängerrelease.

Ist vielleicht jemand schon auf dieses Szenario gestossen und hat auch eine Lösung gefunden ?

Wolfgang Wagner

Also wenn du Änderungen im Seitenbaum bzw. innerhalb fileadmin/ meinst: das wird durch das Deployment natürlich nicht abgedeckt.

Peter Oberzier

Ich kenne das Video zwar bisher nicht, aber für gewöhnlich werden im Deploymentprozess lediglich die Dateien aus dem Dateisystem übertragen, nicht aber die Einträge in der Datenbank. Die Dinge, die Du geändert hast, werden jedoch in der Datenbank gespeichert.

Eddy Wolbert

Ich hatte tatsächlich zunächst mit einer Testdatei innerhalb fileadmin getestet.

Eigentlich ging ich auch davon aus, das eine Datenbankänderung berücksichtigt wird (deswegen neue Seite anlegen etc.) ?
So müsste ich quasi bei Datenbankänderungen auch immer manuell einen DB-Dump nachschieben ?

Ähm, was kann/sollte dann letztlich automatisiert auf Produktionsseite ankommen ?

Marc Ahlene

Eddy Wolbert Eine Datenbankänderung wäre nicht unbedingt zielführend. Evtl. überschreibst du dann Änderungen von Redakteuren, die am Produktionsweb arbeiten.
Ein Deployment ist nicht unbedingt dazu gedacht, lokal wilde Contentänderungen durchzuführen und Datenbanken zu deployen. Das machste besser per SSH direkt.

Klaus

TYPO3 (oder auch andere Anwendungen) bestehen so gesehen aus mehreren Teilen:

Applikation
Dateien
Datenbank

Applikation

Dabei handelt es sich um die Applikation. Im Falle von TYPO3 ist das der Core, sämtliche Extensions, Konfigurationen, usw. Diese werden mittels eines "Deployments" auf die verschiedenen Stages deployed. Im Grunde genommen handelt es sich dabei um das "Composer" Projekt.

Dateien

Im TYPO3 Fall ist das (meisten) der "fileadmin" Ordner. Dabei handelt es sich um Benutzer Daten. D.h. Dateien, welche vom Benutzer hochgeladen und verwendet werden. Diese sind NICHT Teil der Applikation.

Datenbank

Last but not least die "Datenbank". Dort werden Informationen wie "Seiten", "Inhaltselement", "Redakteure", usw. abgespeichert. Dies sind ebenfalls Daten, welche vom User bereitgestellt sowie verändert werden. Diese sind NICHT Teil der Applikation.

ACHTUNG!

Diese 3 Teile sind zwar immer getrennt zu betrachten, beeinflussen sich aber gegenseitig. Z.B.: Hat man eine Extension in der Applikation aktualisiert (mittels Composer), kann es sein, dass man "Analyze Database Structure" machen muss, um neue Tabellendefinition zu erstellen. Ansonsten wirft die Applikation einen Fehler.

Datenhandhabung

Auch, wie es schon jemand vorher gepostet hat, muss man mit Datenbank und Dateien (fileadmin) sehr vorsichtig umgehen. Diese verändern sich ja durch User Eingaben ständig, und sind eigentlich nur auf dem PROD System aktuell. Würde man hier auch dem DEV System etwas verändern, und dann auf die PROD kopieren/synchronisieren, hätte man einen Datenverlust zwischen dem Datum, wann man dem Dump von der PROD gezogen hat, bis eben jetzt. Da die inzwischen eingegebenen Inhalte überschrieben wurden.

Wenn man Daten verändern möchte, muss man sicherstellen, dass in der Zwischenzeit niemand auf PROD Daten eingibt (die würden einem ja fehlen). Dazu kann man sich mit "adminOnly" behelfen. Sodass keine Redakteure einsteigen, und Inhalte eingeben oder verändern können.

Wir machen das gerne für "Upgrades". D.h.

Backend auf PROD sperren ("adminOnly" setzen)
Daten auf DEV System spielen
Auf DEV System Migration durchführen (wenn es mehrere Dinge sind, die auf der Datenbank angepasst werden müssen)
Daten von DEV auf PROD spielen (durch "adminOnly" kann man sicher sein, dass keine Inhalte in der Zwischenzeit eingegeben wurden)

Ich hoffe, ich konnte das Thema etwas genauer erklären. Ansonsten gerne fragen 😁

Marc Ahlene

Super Zusammenfassung!
Ein DB Compare ist beim deployen vielleicht nicht gut, aber ein Database Updateschema geht beim deployen via composer durchaus, da ja in der Regel nichts Bestehendes in der Datenbank geändert, sondern nur was hinzugefügt wird, z.B. wenn man eine Extension nachinstalliert.

Klaus

Marc Ahlene Ich hab mich da evtl. ein bisschen "altmodisch" ausgedrückt. Mit "DBCompare" meine ich ein "Database Updateschema". Früher hat das glaube ich "DB Compare" geheissen. Und wir sagen das noch immer so. Danke für den Hinweis.

Marc Ahlene

Klaus Das DB Compare gibt es ja noch immer. Im Install Tool. Und das schlägt dir dann auch vor, Felder z.B. zu löschen. Das wollen wir aber in der Regeln nicht und geht auch gottseidank nicht per typo3_console ... 😉

Eddy Wolbert

Ja, ein DB-Deployment ist natürlich bei näherer Betrachtung unter den angegebenen Bedingungen heikel. Die "adminOnly"-Variante wäre hier tatsächlich eine Option für Upgrades.

Übrigens eine tolle Zusammenfassung der Thematik, danke Klaus 😀

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS