Unsere fünf Ansätze, ein Contao-Projekt umzusetzen

Je nach Projekt, Agenturpartner und Projekthistorie setzen wir Contao-Projekte auf unterschiedliche Weise um. Diese fünf Ansätze haben sich bei uns etabliert:

1. Nur Theme + Inhalte

Wir installieren eines unserer Contao-Themes, entweder direkt auf dem Kundenserver oder in einer von uns bereitgestellten Entwicklungsumgebung. Das Layout passen wir nach Absprache und im Einklang mit dem bestehenden Corporate Design (sofern vorhanden) an. Bilder und Texte fügen wir im Rahmen der Erstbefüllung ein. Bei diesem Ansatz arbeiten wir direkt auf dem Server.

Geeignet für Kund:innen, denen der Kostenvorteil wichtiger ist als ein individuelles Layout.

2. Theme + Layout + Inhalte

Ähnlich wie der erste Ansatz — allerdings bekommen wir hier zusätzlich ein Layout zur Verfügung gestellt, das auf einem unserer Themes basiert.

Normalerweise arbeiten wir auch hier auf dem Server, es sei denn, es wurden Layoutanpassungen gestaltet, die über die Theme-Funktionen und -Darstellung deutlich hinausgehen. In diesem Fall arbeiten wir zunächst lokal und aktualisieren regelmäßig die Entwicklungsumgebung, um eine gemeinsame Gesprächsgrundlage zu haben.

Eine zusätzliche lokale Installation lohnt sich normalerweise, sobald die Layoutanpassungen mehr als 4 Stunden betragen. Denn dann nutzen wir z. B. gulp.js, um Änderungen im SCSS direkt über Browser-Sync sichtbar zu machen.

Geeignet für Websites, die kostengünstig bleiben sollen, bei denen das zugrunde liegende Theme aber nicht direkt erkennbar sein soll.

3. Bestehende Websites ohne Deployment

Mindestens genauso oft wie neue Projekte betreuen wir bestehende Projekte. Eigentlich immer ist es so, dass es noch kein Deployment gibt und das Projektmanagement aus vielen E-Mails statt einem System bestand. Um die Kosten gering zu halten, verzichten auch wir zunächst auf ein Deployment und nutzen zwar ein Projektmanagement-System, aber ausschließlich intern. Änderungen machen wir — sofern möglich — direkt auf dem Server. Erweiterungen entwickeln wir in einer neutralen Testumgebung und überführen sie am Ende in die Live-Instanz.

Geeignet für bestehende Projekte, die wir von Agenturen übernommen haben und bei denen noch nicht klar ist, wo die Reise hingeht (Relaunch, Weiterentwicklung, Zusammenarbeit zwischen Agentur und Kund:in).

4. Bestehende Websites mit Deployment

Bei einer längerfristigen Zusammenarbeit setzen wir auf ein Deployment mit Deployer. Dafür nutzen wir das von Richard entwickelte Contao Recipe, erweitert durch unser Nutshell Recipe. Damit können wir lokal entwickeln, Änderungen auf einer Stage testen und besprechen und das Ergebnis auf dem Live-Server veröffentlichen.

Dank der 2-Wege-Synchronisation von Dateien und Datenbanken können auch neue Entwickler:innen relativ schnell an einem Projekt mitarbeiten. Bestehende Workflows (z. B. Layouts, die mittels 2–3 CSS-Dateien umgesetzt wurden) behalten wir aber bei und stellen sie ggf. bei einer Überarbeitung von Teilbereichen oder einem Relaunch zur Diskussion.

Zur Kommunikation mit unseren Projektpartnern verwenden wir GitLab (speziell die Ticket-Funktion); außerdem wird das Projekt so versioniert und dokumentiert.

Geeignet für große Projekte, bei denen Änderungen nicht immer unmittelbar sichtbar sind — mit vielen Erweiterungen und individuellen Anpassungen, die z. B. bei Updates überprüft werden müssen.

5. Projekte auf Basis des Nutshell Frameworks

Bleibt noch die Umsetzung eines neuen Projekts oder eines Relaunches mit unserem Nutshell Framework. Hier kommt das Beste aus allen Welten zusammen:

• das Layout basiert auf dem Nutshell Framework, genauer: auf dem Nutshell Starterkit
• wir verwenden Deployer für die halbautomatische Aktualisierung von Stage- und Live-Umgebung
• wir nutzen GitLab (selbst gehostet) zur Versionierung, Dokumentation und für das Projektmanagement

Das ist unsere bevorzugte Art, an Projekten zu arbeiten, weil wir die Entwicklung komplett in der Hand haben und unseren eigenen Workflow verwenden können. Sie lohnt sich vor allem für neue Projekte, die langfristig betreut und weiterentwickelt werden sollen: Der initiale Einrichtungsaufwand ist höher, aber sobald ein Projekt mehr als ein paar Monate läuft, rechnet er sich. GitLab dient dabei auch als digitales Gedächtnis, um Entscheidungen und offene Punkte aus der Vergangenheit nachvollziehen zu können.

Die Serie zum Workflow

Die einzelnen Bausteine dieses Workflows beschreiben wir in einer fünfteiligen Serie:

1. Projektstart mit dem Nutshell Starterkit
2. GitLab für Projektmanagement und Entwicklung
3. Deployment mit Deployer
4. Teamarbeit: Datenbank-Änderungen nur in eine Richtung synchronisieren
5. Launch: Go-Live und Wartung

Außerdem hilfreich: Umgebungsvariablen in Contao: die Dotenv.