Contao-Update Workflow im laufendem Betrieb

[Schnippel]

Hi Leute,

wenn eine Website von verschiedenen Benutzern / Redakteuren ständig mit neuen Inhalten gepflegt wird,
der Admin aber für eine Umstellungen z.B. von Contao 4.13 auf 5.2, eine Testumgebung hat, wie kann dann der Admin die in der Zwischenzeit aufgelaufenen neuen Inhalte der Benutzer / Redakteure in die Testumgebung einpflegen?

Die Benutzer Redakteure arbeiten z.B. noch in der 4.13er Version, während der Admin in der 5.2er Version schon Templates und Erweiterungen angepasst hat.

Reicht es da aus, einfach die Datenbank aus der 4.13er Version in die 5.2er zu importieren?

[Spooky]

5.2? Ich hoffe du meinst 5.3 .

Im "Normalfall" ist es so, dass du das Update auf 5.3 zuerst lokal testest, ggf. Anpassungen und Migrationen implementierst - und dann wenn das Update Live gehen soll, wird ggf. die Website für alle Backend Redakteur*innen gesperrt und das Update deployed. Danach werden die Redakteur*innen wieder freigeschalten.

[Schnippel]

Im "Normalfall" ist es so, dass du das Update auf 5.3 zuerst lokal testest, ggf. Anpassungen und Migrationen implementierst

Wenn ich z.B. am 1. Mai das Ganze System in einer Testumgebung kopiert habe und die Anspassungen, Update von 4.13 auf 5.3 durchführe, und am 10. Mai damit fertig bin, dann haben die Redakteure aber innerhalb der 10 Tage Inhalte in das noch alte System eingegeben.
Was muß ich am 10. Mai machen, damit das neue 5.3er System, vor der Freischaltung, noch die zwischen 1. Mai und 10. Mai erstellten Inhalte der Redakteuere aus dem alten 4.13er System in das neue 5.3er System bekomme? Ist das mit dem Exportieren der 4.13er Datenbanken aus dem alten System und diese importieren in die 5.3er Datenbank im neuen System abgetan?

[fiedsch]

Datenbank vom 10. Mai in die lokale Installation einlesen und die ganzen Migrationen (die programmiert und nicht von Hand gemacht wurden) erneut laufen lassen. Danach das System "deployen".

[Spooky]

Man muss nichts importieren oder exportieren. Einfach aktualisieren im Live System.

[mlweb]

Es kommt ja immer auch auf das konkrete Projekt an.

Ich mache Updates bei Versionssprüngen in der Regel in einer Parallelinstallation und sperre das System für die Zeit des Updates.
Dazu brauche ich dann aber nur einen Tag (und kündige zur Sicherheit an, dass das System für 3 Tage gesperrt ist für Redakteure). Gibt es dann eine ganz wichtige Änderung (kommt nur ganz selten vor), dann wird die Änderung ggf. in beiden Systemen eingepflegt.
Meist habe ich das Update selbst dann schon mal vorab grob getestet, um zu sehen was auf mich zukommt.
Vorteil beim Update in der Paralelinstallation - man kann auch nachträglich noch mit dem ehemaligen Livesystem vergleichen, wenn man es noch eine zeitlang über eine Subdomain am Leben lässt.
Das "schützt" insbesondere beim Update von Fremdinstallationen auch vor den Kunden, die alle möglichen Probleme (z.B. CSS), die schon vorher da waren versuchen auf das Update zu schieben.

Wenn es ein System mit sehr vielen Änderungen täglich ist, würde ich auch im Livesystem updaten. Ist bei mir bisher aber nur einmal vorgekommen

[zoglo]

Man muss nichts importieren oder exportieren. Einfach aktualisieren im Live System.

Wie Spooky schon sagt - Einfach im Livesystem, wenn man Vorkehrungen trifft

Mein Workflow für solche Updates bei "normalen Seiten*" ist immer folgender:

• Download der composer.lock (Damit man via composer install wiederherstellen kann)
• @php vendor/bin/contao-console contao:maintenance-mode on (Wartungsmodus für alle)
• @php vendor/bin/contao-console contao:backup:create (Backup in var/backups)
• Download des Backups aus var/backups (Damit man mit contao:backup:restore wieder zurückgehen könnte)
• composer update - Vollständige Paketaktualisierung (Man hat ja vorher schon alles kontrolliert - gehört ja dazu)
• @php vendor/bin/contao-console contao:migrate (Migrationen durchlaufen lassen)
• @php vendor/bin/contao-console contao:maintenance-mode off (Wartungsmodus aus)
• Testen

Wenn was schief gelaufen ist:

• @php vendor/bin/contao-console contao:maintenance-mode on
• Upload der composer.lock
• composer install
• @php vendor/bin/contao-console contao:backup:restore
• @php vendor/bin/contao-console contao:maintenance-mode off

Bis dato ist noch nie was schief gelaufen, ich kontrolliere aber auch immer alle Abhängigkeiten und lese mir die Release-Notes / Migrations / Upgrade.md / Deprecations durch.
Bei Eigenentwicklungen hat man so oder so immer eine lokale Dev-Umgebung, in welcher man sowas testet.

* Normale Seiten:
- Keine Eigenentwicklungen / Keine unbekannten Abhängigkeiten / Keine Premium Contao Themes / Keine unbekannten Themes


___

Und wenn der ganze Prozess nur 5-15 Minuten dauert, dann war es ein erfolgreiches Update. Der Kunde zahlt ja nicht nur für das "Klicken" auf Update, es gibt halt noch die Vorarbeit und Recherche.

[zonky]

Vorteil beim Update in der Paralelinstallation - man kann auch nachträglich noch mit dem ehemaligen Livesystem vergleichen, wenn man es noch eine zeitlang über eine Subdomain am Leben lässt.

... ganz wichtig, da üblicher Weise nach einem größeren Update/Upgrade jemand von Kundenseite kommt und meint, das war vorher "ganz anders"... - mit der alten Liveseite kann man sagen "neee!"