5 Ansätze, wie wir Projekte in Contao umsetzen

Moin!

Heute möchte ich dir ein wenig davon erzählen, wie wir Projekte in Contao umsetzen. Denn je nach Projekt, Agenturpartner und Projekthistorie verwenden wir unterschiedliche Ansätze.

Außerdem findest du am Ende der Mail noch das Experiment, von dem ich letzte Woche sprach. Als Kind, das mit der Knoff-Hoff-Show groß geworden ist, liebe ich Experimente! Du auch?! Aber um das Experiment zu verstehen, schau dir erstmal die 5 Ansätze an, wie wir Projekte in Contao umsetzen.

Bist du bereit?! Dann los …

1. Nur Theme + Inhalte
Wir installieren eines unserer Contao Themes, entweder direkt auf dem Kundenserver oder in einer von uns zur Verfügung gestellten Entwicklungsumgebung. Das Layout passen wir nach Absprache und in Einklang mit dem bestehenden Corporate Design (sofern vorhanden) an. Bilder und Texte werden von uns im Rahmen der „Erstbefüllung“ eingefügt. Bei diesem Ansatz arbeiten wir direkt auf dem Server.

Diese Lösung bietet sich vor allem für Kunden an, denen der Kostenvorteil wichtiger ist, als ein individuelles Layout zu haben.

2. Theme + Layout + Inhalte
Dieser Ansatz ist ähnlich wie der 1. 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.

Diese Lösung bietet sich vor allem für Websites an, die immer noch kostengünstig sein sollen, aber bei denen das zugrundeliegende Theme nicht direkt erkennbar sein soll.

3. Bestehende Websites ohne Deployment
Während es sich bei den ersten beiden Ansätzen vor allem um neue Projekte handelt, haben wir mindestens genauso oft die Situation, dass wir bestehende Projekt anpassen sollen. Oftmals Eigentlich immer ist es so, dass es noch kein Deployment gibt und auch das Projektmanagement viele E-Mails statt einem System waren. Um hier 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. Bei der Entwicklung von Erweiterungen verwenden wir eine neutrale Testumgebung und überführen die fertige Erweiterung am Ende in die LIVE-Instanz.

Diese Lösung verwenden wir vor allem bei bestehenden Projekten, die wir von Agenturen übernommen haben und bei denen noch nicht klar ist, wo die Reise hingeht (Relaunch, Weiterentwicklung, Zusammenarbeit zwischen Agentur und Kunde).

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, das durch unser Nutshell Recipe erweitert wird. Damit können wir lokal entwickeln, Änderungen auf einer Stage testen + besprechen und das Ergebnis auf dem Live-Server veröffentlichen.

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

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

Diese Lösung ist sinnvoll für große Projekte, bei denen Änderungen nicht immer unmittelbar sichtbar sind. Sie enthalten viele Erweiterungen und individuelle Anpassungen, die z.B. bei Updates überprüft werden müssen.

5. Projekte auf Basis des Nutshell Frameworks
Zu guter Letzt bleibt noch die Umsetzung eines neuen Projekts oder eines Relaunches mit unserem Nutshell Framework. Hier kommt sozusagen 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 gehosted) zur Versionierung, Dokumentation und für das Projektmanagement

Diese Lösung ist (verständlicherweise) meine bevorzugte Art, an Projekten zu arbeiten, da ich hier die Entwicklung komplett in der Hand habe und meinen eigenen Workflow verwenden kann. Sie ist vor allem für neue Projekte sinnvoll, die langfristig betreut und weiterentwickelt werden sollen, denn der initiale Einrichtungsaufwand ist höher, aber sobald ein Projekt mehr als ein paar Monate geht, rechnet sich der Aufwand schon wieder. Gitlab dient dabei auch als digitales Gedächtnis, um Entscheidungen und offene Punkte aus der Vergangenheit nachvollziehen zu können.

Das sind sie. Unsere 5 Ansätze mit denen wir Projekte mit Contao umsetzen. Und vermutlich findest du dich bei einem oder mehreren Punkten wieder, oder? Sollte sich deine Arbeit bisher auf die ersten 3 Ansätze beschränken, dann solltest du nun unbedingt weiterlesen …

Beim letzten Mal schrieb ich dir, dass ich dich zu einem Experiment einladen möchte. Und hier ist es:

Zum Experiment

Ich hoffe, dass du dabei bist.

Viele Grüße,
Dennis

PS: Ich habe mir die verrückte Zahl von 10% der Flaschenpost-Abonnenten in den Kopf gesetzt und bin gespannt, ob sich genug Interessenten finden.