Gerade wenn man im Team mit anderen Entwicklern an einem Onlineprojekt arbeitet, sollten die Arbeitsabläufe zuvor genau geplant werden. Bei kleineren Teams oder Freelancern werden Änderungen häufig direkt im Live-System vorgenommen. Wir waren da keine Ausnahme. Zu oft schon saß ich verwundert vor meinem Rechner, als eine eben von mir vorgenommene Änderung in der CSS-Datei vor meinen Augen verschwand. Ein Anruf bei meinem Kollegen brachte Licht ins Dunkel, da er just in diesem Moment die gleiche Datei bearbeitete und meinen Stand unwissentlich überschrieben hat.
Im Folgenden wollen wir daher unseren Workflow mit Contao vorstellen.
Lokale Installation mittels Xampp
Zuerst erfolgt eine lokale Installation der gewünschten Version von Contao lokal auf unseren Rechnern. Dafür müssen (ab Contao 4) zuvor einige Werte in der php.ini angepasst werden, um den Voraussetzungen der Installation zu entsprechen. Wer eine grafische Benutzeroberfläche bevorzugt, der kann sich vom Contao Manager Schritt für Schritt durch die Installationsroutine führen lassen. Wer jedoch wie wir lieber mit der Konsole arbeitet, kann sich ebenso per composer create-project die bevorzugte Version von Contao ins Zielverzeichnis laden. Im Forum gibt es hierfür eine recht detaillierte Anleitung.
Wir durchlaufen also den Installationsprozess und tragen die Zugangsdaten unserer Datenbank ein. Welche Daten wir hier eintragen, hängt davon ab, ob wir mit einer Remote-Datenbank oder einer lokalen Datenbank arbeiten. Die Unterschiede werden wir im folgenden Part beleuchten.
SSH-Tunnel oder Datenbank-Dump?
Zugegeben, diese Frage hat uns lange Kopfzerbrechen bereitet. Da beide Optionen sowohl Vor- als auch Nachteile haben, ist die Wahl abhängig vom jeweiligen Projekt und den individuellen Workflows der Entwickler. Aber was meinen wir eigentlich mit Dump bzw. SSH-Tunnel?
Arbeiten mit einer lokalen Datenbank
Diese Arbeitsweise ist ideal für kleinere Teamsoder Entwickler, welche ein Projekt alleine betreuen. Dabei wird, sobald am Live- bzw. Develop System Änderungen vorgenommen werden, ein Abbild der Datenbank erzeugt, heruntergeladen und auf den lokalen Testserver übertragen.
Da unsere Kunden gerne selbst Hand anlegen und Inhalte auf ihren Websites selbst verwalten, ist es wichtig, das Dev-System vor dem Beginn der Arbeiten auf den neuesten Stand zu bringen.
Der Vorteil dieser Arbeitsweise besteht vor allem darin, dass man komplett auf der lokalen Entwicklungsumgebung arbeiten kann.
Der Nachteil ist, dass sollten nach der Erstellung des Dumps Änderungen (von Kunden oder gar Kollegen) vorgenommen werden, die Datenbanken teilweise aufwendig miteinander synchronisiert werden müssen. Dies kann schnell ausarten und sollte nicht unbedacht durchgeführt werden.
Arbeiten mit einer Remote-Datenbank mittels SSH-Tunnel
Die Verwendung einer Remote Datenbank bietet den entscheidenden Vorteil, dass mehrere Entwickler gleichzeitig an einer gemeinsamen Datenbank arbeiten können. Wir stellen hierfür mit einem SSH-Client wie WinSCP einen SSH-Tunnel zum Zielserver her. Dies ermöglicht einen Zugriff auf eine externe Datenbank, welche sich auf unserem Dev-Server befindet.
Auf diese Weise können mehrere Entwickler und Redakteure gleichzeitig an Struktur und Inhalt der Website arbeiten, da sie sich, wie auf einem Livesystem, eine Datenbank teilen.
Ein Nachteil hierbei ist eine für Anfänger komplizierte Einrichtung des Tunnels, teils schlechte Down- und Uploadgeschwindigkeit und die ständige Aufrechterhaltung des SSH-Tunnels, da bei schließen der Verbindung logischerweise keine Datenbank mehr erkannt wird.
Versionierung mit GitHub
Das Versionskontrollsystem Git hat die Softwareentwicklung, seit es vom Linux Erfinder Linus Torvalds im Jahre 2005 entwickelt wurde, vollkommen revolutioniert. Auch in unserem Workflow ist es nicht mehr wegzudenken.
Beliebte Editoren wie Atom oder Visual Studio Code kommen mittlerweile mit nativer GIT-Integration daher, wodurch einem größtenteils sogar die Konsole erspart bleibt.
Wir erzeugen also eine leeres GIT-Repository in unserem Root-Verzeichnis und geben unser Remote-Repository an.
Danach schließen wir mittels .gitignore statische oder gänzlich für die Entwicklung irrelevante Dateien vom Staging-Prozess aus. Dadurch können Merging-Konflikte und lange Wartezeiten beim "Push"-Vorgang vermieden werden.
Im nächsten Schritt landen dann alle gepushten Dateien im zugehörigen Verzeichnis auf GitHub (funktioniert natürlich auch mit anderen Filehosting Anbietern), von wo sie von uns mittels Pull-Request vom Dev-Server abgeholt werden können.
Fazit
Wir hoffen, wir konnten mit diesem Beitrag dem ein oder anderen etwas weiterhelfen. Bestimmt ist auch der von uns beschriebene Arbeitsablauf ausbaufähig, doch haben wir damit die letzten Jahre gute Erfahrungen gemacht und konnten Projekte sehr strukturiert umsetzen. Auf Tipps und Anregungen würden wir uns natürlich sehr freuen, schreibt uns doch einfach eine E-Mail!
Weitere interessante Beiträge...
