Nachdem wir uns in den letzten beiden Ausgaben vom „Aquarium im Eigenbau“ mit dem Aufsetzen der virtuellen Maschine und Installation von Barracuda und Octopus beschäftigt haben, machen wir uns an den Feinschliff und fügen sozusagen das Piratenschiffchen hinzu.

Dateisystem

Die offensichtlichste Frage ist natürlich, wie man am besten Dateien editiert. Im Idealfall wollen wir dem Editor unserer Wahl im Hostsystem arbeiten und das Ganze ohne ständigen Upload in die virtuelle Maschine transferieren.

Jede der gängigen Virtualisierungslösungen bietet eine Möglichkeit, Ordner des Hostsystems für die Virtuelle Maschine freizugeben. Wie das im Detail gelöst ist, kann man auf den jeweiligen Websites nachlesen. Gemein haben sie alle, dass die geteilten Verzeichnisse unter Linux als Laufwerke zur Verfügung stehen, die aber noch gemountet werden müssen. Es wäre also prinzipiell möglich, einen Ordner freizugeben und innerhalb der VM an der richtigen Stelle einzubinden. Die Festplattenzugriffe auf Shared Folders sind aber merkbar langsamer, und man wartet auf jeden Seitenreload gut 2-3 Sekunden.

Eine andere Option wäre es, einen FTP-Client zu verwenden, der das Mounten von Verzeichnissen unterstützt (zb. Cyberduck, Transmit oder Forklift). Damit bindet man ein Verzeichnis der Virtuellen Maschine als Laufwerk am Hostsystem ein. Bei mir traten aber hie und da Probleme mit doppelt eingebundenen oder wechselnden Ordnernamen auf, was nervig ist, wenn man in der IDE fixe Projekte einrichtet.

Die für mich beste Lösung ist das Deployment Feature von PHPStorm. Damit kann man für jedes Projekt einen Host angeben und optional Dateien direkt beim Speichern hochladen. Damit arbeiten beide System auf ihrem nativen Dateisystem und man verliert nirgends Leistung. Der Upload passiert automatisch im Hintergrund. Ausserdem kann man schnell und einfach den Deployment Server wechseln und das Projekt auf einen Live-Server synchronisieren.

Hakt man die entsprechende Option in der Deployment-Konfiguration an, überwacht PHPStorm auch externe Veränderungen und synchronisiert diese automatisch. Also zum Beispiel SASS oder CoffeeScript Dateien, die erst durch den entsprechenden Preprocessor laufen.

Nachtrag: NFS Sharing

Danke an Sebastian (siehe Kommentare) für den Hinweis! Dass NFS so viel schneller ist als die mitgelieferten Sharing Optionen war mir nicht bewusst. Eine kleine Anleitung wie man das Sharing unter Mountain Lion einrichtet:

Man editiere (oder erstelle wenn nicht vorhanden) die Datei /etc/exports im Hostsystem.

/Users/philipp/Barracuda -mapall=philipp -network 10.211.55.0 -mask 255.255.255.0

Der Ordner /Users/philipp/Barracuda ist natürlich zu ändern, je nach dem wo man seine Plattformen speichern will.

showmount -e im Terminal ausgeführt sollte im Idealfall folgenden Output zurückliefern:

Exports list on localhost:
/Users/philipp/Barracuda            10.211.55.0

Dann melden wir uns als root in unserer virtuellen Maschine an und installieren das nfs-Dateisystem …

apt-get install nfs-common

… fügen folgende Zeile in /etc/fstab hinzu …

10.211.55.2:/Users/philipp/Barracuda /data/disk/dev/static nfs defaults 0 0

… und führen mount -a aus um den geteilten Ordner jetzt und für alle Zeit direkt ins Plattformverzeichnis unseres Octopus-Users einzubinden. Die IP-Adresse ist jene des Hostsystems im Netzwerk von Parallels, VMware oder Virtualbox. Diese lässt sich recht einfach über ifconfig herausfinden. Jetzt können wir nach belieben Plattformen in den Ordner spielen, Quellcodes verändern oder mit Git arbeiten und die Änderungen werden ohne Umschweife in die virtuelle Maschine übernommen.

Caching

Barracuda erzwingt für alle Seiten standardmäßig CSS und JS Aggregation, was, wenn man das erste mal damit herumspielt, etwas frustrieren kann. Die Lösung ist aber recht einfach.

Für Subdomains die in irgendeiner Form dev enthalten ist das gesamte Caching automatisch komplett deaktiviert. Wenn man zum Beispiel eine neue Seite „www.drupal.bcd“ im Hostmaster anlegt, reicht es ein Alias „dev.drupal.bcd“ hinzuzufügen. Das hat gleich ein paar Vorteile. Ich nutze die normale Domain, bsp. für klicklastige Tätigkeiten wie Views und Panels Konfiguration, da das Interface dann noch einen Tick schneller läuft. Parallel kann ich in der dev-Domain die Seite beim bearbeiten der Stylesheets betrachten ohne ein/ausloggen zu müssen.

Livereload

Wo wir schon beim Thema Stylesheets sind. Auch Livereload funktioniert mit unserem Setup.

Wer Livereload noch nicht kennt: Dabei handelt es sich um eine kleine Mac-App, die Website Ordner überwachen und in Kombination mit Browserplugins die Darstellung aktualisiert sobald sich dort eingebundene Dateien ändern. Im Falle von CSS Sheets geschieht das sogar ohne Refresh sondern wirklich instant. Wer viel mit SASS/LESS/CSS arbeitet und gewillt ist seine Arbeitsgeschwindigkeit zu verdoppeln sollte sich das ansehen. Für mich waren es ein paar der am besten investierten Euro meiner beruflichen Laufbahn.

Der Sofort-Refresh funktioniert natürlich nicht, wenn wir die Datei erst per FTP auf unsere virtuelle Maschine spielen müssen. Zum Glück hat Livereload ein cleveres Feature namens „Url Rewrite“, welches man pro Projekt separat aktivieren kann.

Damit tauscht LiveReload alle Stylesheets Urls in der Seite aus und ersetzt sie durch Aufrufe an einen integrierten HTTP-Server der diese dann direkt ausliefert. Damit funktioniert der Instant-Refresh unabhängig davon, wo das Projekt wirklich gerade gehostet wird.

Seitenmigration

Wir haben jetzt ein tolles Setup mit wir unter realen Bedingungen und vor allem ohne ständigen Konfigurationsaufwand eine Menge Seiten installieren und entwickeln können. Wichtig wäre es aber natürlich auch, alte Projekte in unsere neue Entwicklungsumgebung zu migrieren. Ich werde hier nicht jeden Schritt einzeln durchgehen, denn Omega8 hat eine ausführliche Anleitung bereitgestellt, mit der sich bisher jedes Projekt innerhalb von Minuten installieren ließ.

Development Workflow

Wer noch regelmäßig mit MySQL-Dumps arbeitet ist vielleicht schon ein wenig nervös geworden. Barracuda abstrahiert die Datenbank relativ weit weg, und eigentlich ist es am besten das auch so zu belassen. Wir arbeiten im Normalfall mit Installationsprofilen und Features, und transportieren damit jegliche Konfiguration in den Quellcode. Damit kann man innerhalb von Aegir die Seite im Idealfall auch mithilfe eines Klicks installieren, ohne weiter konfigurieren zu müssen. Es zahlt sich aus sich mit dem Thema zu beschäftigen.

Eine sehr gute Präsentation zu dem Thema wurde von Nuvole verfasst. Zu Installationsprofilen gab es auf den Drupal Developer Days Brussels eine Session die es auch wert ist gesehen zu werden.