Hallo in die Runde.
So ganz kann ich das aber auch nicht stehen lassen.
Beispiel: In eine bestehende Website kommt ein News-Modul nachträglich
rein. Fluid-Templates, CSS, usw steht alles in den Dateien einer
Setup-Extension und lässt sich wunderbar versionieren.
Aber was machst du mit den ganzen funktionellen Seiten? Wo konfigurierst
du Detail-Seite, Liste und Ablageordner? Alle Seiten-IDs in allen
Plugins? Am besten auch noch für alle Sprachen?
Und sagt jetzt bitte nicht ja - denn damit hast du die
News-Konfiguration in Plugins vorgenommen und damit in der Datenbank
stehen und nicht in versionierten Dateien.
Letztlich läuft es so:
Variante A - Datenübernahme LIVE->DEV:
Sofern das leicht machbar ist, Kopieren wir Datenbank und den fileadmin
von LIVE nach DEV. Mit TYPO3 9 müssen noch nicht mal Domain-Records
(falls vorhanden) umgestellt werden. Die gibt es nicht mehr.
VOR dem Kopieren werden neue "Dummy-Seiten" versteckt angelegt. Nach dem
Kopieren wird in DEV das Feature implementiert, es sind ja alle
relevanten IDs vorhanden. Und wenn es fertig ist, kommt es per
Repository ins LIVE-System und wird nach finaler Content-Befüllung Live
gestellt. Fertig.
Variante B - TYPO3_CONTEXT:
Sofern das Überschreiben von DEV mit LIVE nicht so leicht machbar ist,
kann dieses Szenario greifen. TYPO3_CONTEXT ist bei uns IMMER gesetzt.
Dann werden in DEV und LIVE die Seiten mit unterschiedlichen IDs
generiert und im Typoscript über eine CONTEXT-Abfrage für DEV und LIVE
unterschiedlich konfiguriert. Fertig. Sofern dann ab und zu tatsächlich
auch mal wie bei A alles kopiert wird, müssen die Weichen dann halt
angepasst werden.
Viele Grüße,
André Spindler
Am 08.07.2019 um 19:01 schrieb _doc:
Hallo Rainer,
Die Antwort von Marcus ist falsch, sofern man sich an die Regel der
stricten Trennung von Inhalten und Code hält. Der Code und die
Konfigurationen sollte sich dann nur in Dateien finden lassen, die man
z.B. mit GIT versionieren kann.
Was optimierst du denn auf DEV? Normalerweise kann alles zur
TYPO3-Optimierung in Dateien ausgelagert werden. Eine gute
TYPO3-Aufsetzung enthält keine Configurationsdaten in der Datenbank
(bzw. fast keine). TypoScript, TSConfig, Templates,
BackendKonfigurationen, ... ist ausgelagert in Extensions und Dateien,
die man zum Beispiel unter git versioniert. In der Versionierung Git
habe ich einen Brach Master und einen Develop, wenn alle Einstellungen
im Develop-Branch gut sind, merge man die Version in den
Master-Branch. Dann lädt man die Dateien aus dem Master-Branch auf den
Server. Am besten per ssh-Tunnel mit einem Upload-Programm wie
Magallanes v4 - Documentation, um Uploadfehler und Down-Zeiten klein
zu halten. (Ich habe extra unter Windows ubuntu installiert, um dies
privat machen zu können.)
Wenn man natürlich alles TypoScript und TSConfig in der Datenbank hat,
dann sollte man das vorher rausziehen und in eine Extension auslagern.
Mit besten Grüßen
Dieter
Am 08.07.2019 um 15:26 schrieb Marcus Raphelt:
Hi Rainer,
so wirklich zuverlässig würde es nur gehen, wenn Typo3 hier, wie
bspw. Oxid, auf UUIDs statt AutoInc-Spalten setzen würde. Numerisch
laufen Dev und Live *immer* auseinander.
Als Helferlein könnte ich SQLYog empfehlen, die Pro-Version hat einen
Synchronisations-Wizard, der ganz gut funktioniert und zwischen zwei
MySQL-Instanzen "rsyncen" kann.
Wirklich lösen lässt es sich nach meinem Kenntnisstand nur politisch
/ organisatorisch.
Gruß
Marcus
Am 08.07.19 um 15:00 schrieb Rainer Schleevoigt:
Nun pflegen Redakteure im PROD-System Seiten und deeren Inhalte ein.
Ich wiederum verbessere die TYPO3-Seite auf DEV. Nun kommt der
Wunsch des Mergings.
Geht das überhaupt - best Practice?
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
