5 Gründe, Contao Projekte lokal zu entwickeln

Immer wieder werden wir von Agenturen gefragt, warum wir für den Großteil unserer Contao Projekte eine lokale Entwicklungs­umgebung verwenden. Auch unsere Contao Themes sind für die Entwicklung auf einem lokalen Webserver gemacht.

Das klingt zunächst nach doppelten Aufwand und Mehrarbeit, die man sich sparen könnte. Die lokale Entwicklung bringt aber eine Vielzahl von Vorteilen, von denen ich 5 Gründe in diesem Artikel zusammengestellt habe. Wenn du bisher noch nicht lokal arbeitest, dann ist dieser Artikel für dich.

1. Schnelleres Arbeiten

Einer der größten Vorteile einer lokalen Entwicklungsumgebung ist Geschwindigkeit. Mit den richtigen Werkzeugen kannst du gerade beim Aufbau einer Website und der Umsetzung eines Layouts bei jeder Änderung ein paar Sekunden sparen. Denn mit den richtigen Werkzeugen verringerst du nicht nur die Wartezeit beim Seiten-Reload, du kannst den Reload sogar stellenweise überflüssig machen.

„Ein paar Sekunden?!? Und dafür muss ich mehrere Stunden in die Installation einer lokalen Entwicklungsumgebung stecken?“

 Es stimmt. Bei kleineren Projekten solltest du genau prüfen, ob sich die Einrichtung lokal lohnt. Aber je länger du an einem Projekt arbeitest, desto größer wird deine Zeitersparnis im weiteren Verlauf der Umsetzung.

Ich muss dabei immer wieder an die Geschichte des Holzfällers denken, die ich neulich in einem Buch las: 

Ein Spaziergänger geht durch den Wald und beobachtet einen Holzfäller, wie er einen großen Haufen Holz hackt. Der Gute kommt nur langsam voran und müht sich sichtlich ab, da seine Axt stumpf ist. Daraufhin fragt der Spaziergänger den Holzfäller:

„Warum schärfen Sie denn nicht zuerst ihre Axt?“

Der Holzfäller deutet auf den Holzhaufen, der noch vor ihm liegt und antwortet:

„Keine Zeit! Ich muss noch diesen ganzen Holzhaufen fertigmachen.“

Was ich damit sagen möchte: Die Einrichtung einer lokalen Entwicklungsumgebung mag auf den ersten Blick länger dauern, aber je länger du an dem Projekt arbeitest, desto mehr Zeit sparst du in der Umsetzung.

Um Zeitersparnis geht es auch bei Punkt 2.

2. Hilfe durch Tools

In Punkt 1 erwähnte ich bereits, dass es Werkzeuge gibt, mit den du die Ladezeiten verbessern bzw. überflüssig machen kannst. Wir setzen hierfür auf den Taskrunner gulp.js, der auf der Kommandozeile arbeitet und auch bei unseren Contao Themes sowie dem Nutshell Framework zum Einsatz kommt. Gulp kann aber noch mehr, als nur die CSS-Änderungen in Echtzeit in das Layout zu injizieren.

Da wir mit SASS arbeiten, muss es auch irgendeinen Dienst geben, der SASS in CSS umwandelt. Das kann man auch von Contao übernehmen lassen, Taskrunner wie gulp.js oder Grunt bieten aber einen entscheidenden Vorteil: Das autoprefixer-Plugin. Das Plugin gibt es für alle gängigen Taskrunner und sorgt dafür, dass CSS3-Anweisungen, die einen Vendor-Prefix benötigen, automatisch um diesen ergänzt werden.

Beispiel:
Ich schreibe
.example {
    display: flex;
    transition: all .5s;
    user-select: none;
    background: linear-gradient(to bottom, white, black);
}
und autoprefixer macht daraus in der CSS:
.example {
    display: -webkit-box;
    display: -ms-flexbox;
    display: flex;
    -webkit-transition: all .5s;
    -o-transition: all .5s;
    transition: all .5s;
    -webkit-user-select: none;
       -moz-user-select: none;
        -ms-user-select: none;
            user-select: none;
    background: -webkit-gradient(linear, left top, left bottom, from(white), to(black));
    background: -webkit-linear-gradient(top, white, black);
    background: -o-linear-gradient(top, white, black);
    background: linear-gradient(to bottom, white, black);
}

Das kann Contao leider aktuell nicht und es sieht auch nicht so aus, als würde es in absehbarer Zeit kommen.

Auch Aufgaben wie die automatische Bildkomprimierung und CSS-Minifizierung sowie JS-Minifizierung lassen sich durch gulp, Grunt und Co. abnehmen.

Wer die Kommandozeile scheut, für den gibt es Codekit für Mac oder Prepros für Windows. Hier wird ebenso vorausgesetzt, dass lokal entwickelt wird.

Auch hier kannst du während und zum Projektende wertvolle Zeit sparen, da deine Entwicklung durch kleine Tools automatisch verbessert wird.

3. Arbeiten im Team

Sobald du im Team an der Umsetzung eines Projektes arbeitest, ist Vorsicht geboten. Denn was Anna in stundenlanger Arbeit aufgebaut hat, kann Bernd mit Klick auf speichern wieder entfernen – wenn sie zeitgleich an einer CSS-Datei direkt auf dem Server arbeiten.

Dabei spreche ich aus eigener Erfahrung. Rückblickend betrachtet muss ich schon ein wenig schmunzeln, wenn ich mir vorstelle, wie sowohl mein damaliger Kollege als auch ich etwas in der CSS-geändert haben, speichern drückten, die Seite aktualisierten, einen Moment warteten und die Änderung wieder verschwunden war. 

Es hat bestimmt eine halbe Stunde gedauert, bis wir merkten, dass wir zur gleichen Zeit an der gleichen Datei arbeiteten.

Wenn du dich entschließt, lokal zu entwickeln, dann steht dir auch die Tür für eine Versionsverwaltung wie Git offen. Über ein Git-Repository könnt ihr parallel an den gleichen Dateien arbeiten und die Änderungen werden (mehr oder weniger) automatisch zusammengeführt.

Git hat außerdem den Vorteil, dass du/ihr die Änderungen dokumentieren könnt und ein Backup der zu entwickelnden Website habt, womit wir beim nächsten Punkt wären.

4. Backups der zu entwickelnden Seite

Backups sind ein leidiges Thema. Trotzdem kann man gar nicht genug davon haben. Die meisten Hoster weisen explizit darauf hin, dass du für Backups selbst verantwortlich bist. Sie machen zwar regelmäßig Backups und es ist sehr unwahrscheinlich, dass während der Entwicklung der Server ausfällt und kein Backup vorhanden ist. Aber es kann halt auch mal eine Weile dauern, bis sie dir ein Backup zur Verfügung stellen können.

Unnötige Wartezeit, wenn du versehentlich die falsche Datei gelöscht hast.

Wenn du lokal arbeitest, dann kannst du dir den Anruf beim Hoster sparen und die Datei aus deinem eigenen Backup – beim Mac zum Beispiel über Time Machine – wiederherstellen.

Und wenn du mit einer Versionsverwaltung wie Git arbeitest, kannst du sogar zeilenweise entscheiden, welchen Stand du wiederherstellen möchtest.

5. (Weiter-)Entwicklung, unabhängig von Kunde und Öffentlichkeit

Ob es nun nach Livegang oder während der Umsetzung des Projekts ist: Manchmal ist es gut, wenn du einen zusätzlichen Bereich hast, in dem du Dinge testen und weiterentwickeln kannst, ohne dass der Kunde oder die Öffentlichkeit es sieht.

Deswegen arbeiten wir bei größeren Projekten mit einer zusätzlichen Entwicklungsumgebung. Unser Workflow sieht dann wie folgt aus: 
  • Lokale Entwicklungsumgebung (nur für das Team)
  • Staging-Umgebung auf Kundenserver (für das Team und den Kunden)
  • Live-Umgebung auf Kundenserver (für die Öffentlichkeit)
Die lokale Entwicklungsumgebung dient dazu, dass du Dinge testen kannst, bevor der Kunde es sieht. Ist die Entwicklung abgeschlossen oder soll mit dem Kunden besprochen werden, wird der Stand auf die Staging-Umgebung übertragen. Die Staging-Umgebung dient dazu, den aktuellen Stand mit dem Kunden besprechen zu können, da er ja vermutlich keinen Zugriff auf deine lokale Entwicklungsumgebung haben wird. Nach der Freigabe werden die Änderungen auf den Live-Server übertragen.

Wenn du verhindern möchtest, dass Kunden panisch anrufen, während du gerade an den Änderungen für das Projekt arbeitest, solltest du eine lokale Entwicklungsumgebung verwenden.

Es gibt noch viele weitere Gründe, warum sich die Entwicklung in einer lokalen Umgebung lohnt. Sei es die Möglichkeit offline zu arbeiten oder bessere Debugging-Möglichkeiten mit Contao 4 dank Symfony Profiler (bei Contao 4 einfach mal app_dev.php an die Domain anhängen, z.B. http://domain.localhost/app_dev.php).

Aber gerade für Nutzer, die bisher immer direkt auf dem Server gearbeitet haben, sollten die oben stehenden Punkte Grund genug sein, sich mit der lokalen Entwicklungsumgebung für Contao Projekte zu beschäftigen.

Jetzt bist du gefragt: Wie arbeitest du an Contao Projekten? Nutzt du regelmäßig eine lokale Entwicklungsumgebung oder arbeitest du direkt auf dem Server? Warum arbeitest du, wie du arbeitest? Schreib es in die Kommentare. 

Zurück

Einen Kommentar schreiben

Kommentar von Enrico Kalkbrenner |

Hallo Dennis, ein guter Beitrag.

Ich nehme an, dass dein Fokus im Wesentlichen bei den „Client“-seitigen Themen wie HTML/CSS/JS liegt. Sobald auch „Server“-seitige Themen wie PHP/SQL mit hinein spielen, ergibt sich bei der lokalen Entwicklungsumgebung die Herausforderung, zu dem MW/DB-Stack des jeweiligen WebHosters kompatibel zu sein. Mindestens wegen #Contao bist du damit ja auch konfrontiert. Sobald dann unterschiedliche Projekte bei verschiedensten Anbietern gehostet werden (müssen), wird es schnell ein sehr bunter Strauß an Versionsausprägungen. Insofern halte ich die von dir bereits aufgezählte „Staging“-Umgebung für einen sehr wichtigen Punkt auf dem Weg zur LIVE-Schaltung.

In diesem Sinne, ich wünsche dir ein schönes Wochenende.

Antwort von Dennis

Moin Enrico,

guter Punkt: Die PHP- und MySQL-Version sollte auf allen Systemen – Lokal, Staging und Live – pro Projekt im Idealfall identisch sein. Sonst macht man sich das Leben unnötig schwer. Bisher war ich aber angenehm überrascht, wie wenig Probleme wir hatten, wenn Entwicklungsumgebung und Liveumgebung doch mal andere PHP-Versionen hatten (in den Fällen war Live PHP 7.0 und Lokal PHP 5.6) 

Kommentar von karsten |

Hallo Dennis,

wußte gar nicht, dass es eine große Gemeinschaft gibt, die ausschließlich online entwickelt!

Kleine Ergänzung zu Tools:
ich nutze "Koala" (http://koala-app.com/) für's automatische Übersetzen von SCSS in CSS und erziele mit "FileOptimizer" (http://nikkhokkho.sourceforge.net/static.php?page=FileOptimizer) regelmäßig bessere Ergebnisse als mit Prepros. Wenn auch nicht automatisiert, so doch einmalig vor dem Veröffentlichen.

@Enrico:
Ich habe zu unterschiedlichen PHP Versionen und verschiedenen Umgebungen Wampserver für mich und die lokale Entwicklung schätzen gelernt. Da kann ich auf Knopfdruck zwischen verschiedenen PHP Versionen umschalten (5.6, 7.0, 7.1, ...), php.ini Direktiven setzen u.v.m.
Das hilft mir auch lokal Effekte zu testen, wenn bspw. der live Server auf die nächste PHP Version gehoben werden soll.

my 2 cents

Grüße aus Münster!

Antwort von Dennis

Moin Karsten,

danke für deine Ergänzungen. Ja, tatsächlich entwickeln sehr viele Agenturen mittlerweile online. Mittlerweile bedeutet, dass die lokale Entwicklung für sie ein Rückschritt ist. Deshalb der Artikel.

Kommentar von Jens |

Moin,
ich baue alle Contao-Seiten lokal; dann bin ich auch produktiv, wenn mal kein Internet verfügbar ist ... doch, so etwas gibt es in der "Provinz" noch ;-)
Grüße vom Land
Jens

Antwort von Dennis

Moin Jens,

ja, das ist natürlich auch ein Grund :-)

Kommentar von Detlef |

Servus und hallo,

habe bis jetzt eigentlich immer lokal unter Win und XAMPP entwickelt, aber seit Contao 4 gibt´s da ja leider Probleme durch den Contao-Manager. Deine Gründe sind handfest und sprechen für sich.
Überlege jetzt, ob ich das ganze unter Linux und XAMPP/LAMPP machen soll.
Was haltet Ihr davon, bzw. welche Lösungen habt Ihr gefunden?

Antwort von Dennis

Moin Detlef,

sehr gute Frage. Bei uns arbeiten die meisten Leute zwar mit Mac, wo sich das Problem nicht stellt, aber Basti zum Beispiel hat als Hauptrechner einen PC. Nachdem er mehrere Tests gemacht hat und wir die Diskussionen um Contao auf Windows mitverfolgt haben, hat er für Contao 4 Projekte ein Linux in Virtualbox laufen.

In diesem Zuge ist vielleicht auch Docker interessant (selbst noch nicht getestet).

Kommentar von Philipp |

Das mit der schnelleren Ladezeit ist meiner Meinung nach in Contao 4 obsolet.
Das Caching ist mittlerweile so dominant, das wir keine Andere Lösung gefunden haben, als alle Assets automatisch bei jedem Seiten-Reload neu erstellen zu lassen, sonst übernehmen sich keinerlei CSS Änderungen.

Oder haben wir da etwas übersehen?

Antwort von Dennis

Lässt du die CSS- und JS-Dateien eventuell über Contao komprimieren? Dann wird die externe CSS-Datei unter assets abgelegt und bekommt auch einen anderen Namen. Um Browsersync nutzen zu können, muss die Option deaktiviert sein, das heißt eine default.css wird auch als solche eingebunden, Änderungen in der CSS-Datei sind sofort sichtbar.

Oder meinst du etwas anderes?

Kommentar von Philipp |

Das Zusammenfassen machen wir nur im Produktivbetrieb. Wir verwenden aber direkt SCSS und lassen das durch Contao kompilieren und da müssen wir alle Scripts neu generieren lassen, damit Änderungen wirksam werden.

Antwort von Dennis

Das habe ich bei einem Projekt auch schonmal festgestellt. Im Dev-Mode (app_dev.php) sollen die SCSS-Dateien angeblich auch zur Laufzeit geprüft werden, habe ich aber bisher nicht getestet. Mit gulp.js kann man das Problem elegant umschiffen

Kommentar von Patric |

Servus Dennis,
Ich arbeite auch schon seit geraumer Zeit lokal, was wie du schon richtig angesprochen hast, allein wegen Taskrunner Versionierung immense Vorteile bringt.
Ich stehe jedoch vor dem Problem, dass wenn ich mit Kollegen zusammen entwickle, wir keine Möglichkeit haben unsere Datenbank entsprechen aktuell zu halten. Das bremst uns noch etwas aus.
Wie handhabt ihr das im Team?
Grüße aus Bayern!

Antwort von Dennis

Moin Patric,

soweit ich weiß gibt es aktuell keine zufriedenstellenden Lösungen für dein Problem. Folgende Optionen verwenden wir aktuell:

  1. externe Datenbank, auf die alle zugreifen. Hat den Vorteil, dass die DB immer aktuell ist, aber den Nachteil, dass bei fehlenden Templates die Seite zwischenzeitlich nicht läuft
  2. Master-Datenbank, von der man sich regelmäßig eine Kopie zieht. Man arbeitet dann auf der Stage in die DB und holt sich die DB-Änderungen dann immer wieder lokal

Beide Lösungen sind nicht das Gelbe vom Ei, aber soweit ich weiß gibt es keine automatisierte Lösung. Variante 2 ließe sich auch mit SyncCTO o.ä. Tools lösen, aber das Kernproblem bleibt. 

Kommentar von Katja Karrer |

Mal ein Beitrag von "Kundenseite" - zumindest gegenüber dem technischen Entwickler.

Ich bin kundenseitig tätig und arbeite viel mit Agenturen zusammen, die mir die verschiedenen CMS aufsetzen, Layouts generieren, Funktionen einbinden. Das alles normalerweise in einer Sandbox auf dem Zielserver, damit ich schon mal Seiten anlegen und Inhalte einpflegen kann, sodass der Entwickler auch immer reale Inhalte zur Verfügung hat, mit denen er arbeitet. Seit es mir so angeboten wird, verkürzt das meine Projektzeiten erheblich, weil ich mit einpflegen fertig bin bis zur Endabnahme und nicht dann erst damit anfangen kann.

Antwort von Dennis

Moin Katja,

das ist ein guter Hinweis. Mit einer lokalen Entwicklungsumgebung + einer Staging-Umgebung kommen sich Entwickler und Redakteure deutlich weniger in die Quere und können parallel an einem Projekt arbeiten. Das geht natürlich auch ohne lokale Entwicklungsumgebung, birgt aber die Gefahr, dass man sich gegenseitig bei der Arbeit behindert. 

Bitte rechnen Sie 7 plus 1.

Immer auf dem Laufenden bleiben

Für den Newsletter anmelden

Der Newsletter erscheint 1x im Monat