Teamarbeit: Datenbank-Änderungen nur in eine Richtung synchronisieren

Teil 4 unserer Serie zum Projekt-Workflow — vorher: Deployment mit Deployer.

Bei unserer Arbeit mit Deployer + Contao gibt es 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.

Legen wir zum Beispiel neue Inhalte an, können wir diese nicht beliebig zwischen mehreren Instanzen synchronisieren. Mit syncCTO gibt es zwar eine Lösung, die die Synchronisation vereinfachen kann, die aber für die Arbeit im Team dennoch an ihre Grenzen stößt. Das hat vor allem zwei 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

Die Regel

Um dennoch im Team an Contao-Projekten zu arbeiten, haben wir uns 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 gibt (die wir DEV oder STAGE nennen), finden alle Änderungen, die direkt in Contao gemacht werden müssen, nur noch auf dieser statt.

Drei Beispiele

1. Wir stellen fest, dass wir ein zusätzliches Seitenlayout benötigen. Also erstellen wir es 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 ihm über die Theme-Toolbox eine zusätzliche Klasse und synchronisieren wieder unsere lokale Instanz, wo wir das Element 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) mit dep files:retrieve.

Wir nutzen die Stage also als Zentrale für alle datenbankbasierten Änderungen und laden uns 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.

Weiter mit Teil 5: Launch, Go-Live und Wartung.