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 :-)

Was ist die Summe aus 4 und 1?

Immer auf dem Laufenden bleiben

Für den Newsletter anmelden

Der Newsletter erscheint 1x im Monat