Teil 4/5: Fallstricke und Lösungen bei der Zusammenarbeit
Moin!
Im heutigen Newsletter soll es um Fallstricke gehen, die bei der Arbeit im Team entstehen können und wie wir damit umgehen.
Wie letzte Woche erwähnt, gibt es bei unserer Arbeit mit Deployer + Contao ein großes Problem:
Änderungen, die wir in Contao machen müssen und die in der Datenbank gespeichert werden, lassen sich nicht reibungslos hin und her synchronisieren.
Das bedeutet, wenn wir zum Beispiel neue Inhalte anlegen, dass wir diese nicht beliebig zwischen mehreren Instanzen synchronisieren können. Mit syncCTO gibt es zwar eine Lösung, die die Synchronisation vereinfachen kann, aber für die Arbeit im Team dennoch an ihre Grenzen stößt.
Das hat vor allem 2 Gründe:
1. MySQL-Datenbanken sind von ihrer Struktur her ungeeignet für partielle Synchronisationen
2. Contao hat keine strikte Trennung zwischen Inhalt und Layout
Um dennoch im Team an Contao Projekten zu arbeiten, haben wir uns deswegen eine einfache Regel überlegt:
Sobald mehr als eine Person an dem Projekt arbeitet, werden alle Änderungen in der Datenbank nur noch in eine Richtung synchronisiert.
Das bedeutet, sobald es eine öffentliche Entwicklungsumgebung haben (die wir DEV oder STAGE nennen), finden alle Änderungen, die direkt in Contao gemacht werden müssen, nur noch auf dieser statt.
Hier 3 Beispiele, damit du verstehst, was ich meine:
1. Wir stellen fest, dass wir ein zusätzliches Seitenlayout benötigen. Also erstellen wir dieses in der STAGE, weisen es den Seiten zu und synchronisieren unsere lokalen Instanzen mit der STAGE über dep database:retrieve um das Seitenlayout dann lokal zu gestalten.
2. Wir benötigen eine Layout-Variante für ein bereits gestaltetes Element. Wir legen das Element in der STAGE an, geben dem Element über die Theme-Toolbox eine zusätzliche Klasse und synchronisieren wieder unsere lokale Instanz, wo wir das Element dann per SCSS stylen.
3. Unsere Partner-Agentur pflegt Texte und Dateien auf der STAGE ein. Um die Darstellung in unterschiedlichen Viewports zu testen und ggf. anzupassen, holen wir uns die Datenbank-Änderungen mit dep database:retrieve sowie neue Dateien (z.B. Bilder oder Downloads) mithilfe des Befehls dep files:retrieve.
Wir nutzen also die STAGE als Zentrale für alle datenbankbasierten Änderungen und laden uns dann diese Änderungen immer wieder herunter (Pull-Synchronisation).
Das ist in manchen Fällen zwar etwas komplizierter, aber die einfachste Lösung, um Konflikte zu vermeiden und zusätzliche Partner für die Inhaltspflege möglichst frühzeitig ins Boot zu holen.
***
Im nächsten und damit auch letzten Newsletter werde ich noch einmal auf Veröffentlichung von Projekten eingehen. Der Betreff lautet: Teil 5/5: Umzug, Launch und weitere Schritte
Viele Grüße,
Dennis