Eine Standard Magento Konfiguration wird bereits mit über 20 JavaScript-Dateien ausgeliefert. Somit ist für die meisten Entwickler schnell klar, dass die Reduzierung des JavaScripts oder dessen Zusammenführung in einer Datei anstatt 20 einen Geschwindigkeitsvorteil und eine bessere Performance bringen wird. Verbunden ist dies mit vergleichsweise wenig Aufwand im Gegenteil zu anderen Optimierungsmaßnahmen. Für solche Fälle bietet Magento standardmäßig die Funktion „JavaScript-Dateien kombinieren“, welche jedoch mehr Nachteile als Vorteile mit sich bringt. Die Nachteile werden wir in diesem Blogpost anhand von drei Beispielen detailliert erläutern.

Die Ausgangssituation:

Bei der Verwendung des von Magento bereitgestellten Features werden alle JavaScript-Dateien in einer Datei kombiniert, aus der Größe des Contents einen Hash generiert und als Datei abgespeichert. In unseren weiteren Beispielen benutzen wir anstatt der Hashes einfache Namen wie zum Beispiel „abc.js“ und „xyz.js“. Die Magento-Entwickler haben bei der Implementierung ihres Features jedoch einige zum Teil gravierende Fehler nicht berücksichtigt.

Fehler 1: Minimierte oder kombinierte JavaScript-Dateien können den ganzen Shop unbenutzbar machen!

Sobald 2-3 minimierte JavaScript-Dateien in das bestehende Shopsystem integriert werden, treten bereits die ersten Probleme auf.
Auch wenn der Entwickler auf die Idee kommen sollte Magentos JavaScript-Dateien zu komprimieren, wird es unter Umständen zu Fehlern kommen.
Das Problem an der Sache ist der Coding-Style der Magento Entwickler. JavaScript ermöglicht es beendete Funktionen ohne Semikolon abzuschließen, wovon die Magento Entwickler sehr oft Gebrauch machen. Sollte nun ein Entwickler die Magento JavaScript-Dateien zur Performance- und/oder Ladezeitoptimierung komprimieren und die Kombinierfunktion einschalten, entstehen dadurch kritische Fehler.

Durch das Komprimieren der Dateien schrumpft der Dateiinhalt auf exakt eine Zeile. Sobald beispielsweise eine „var“ Deklaration am Anfang der zweiten Datei steht und in der ersten Datei eine Funktion ohne abschließendes Semikolon beendet wurde (was in 95% der Fälle zutrifft), wird der Code fehlerhaft geparsed und beide Dateien verlieren Ihre eigentliche Funktionalität.

Fehler 2: Kombinieren der JavaScript-Dateien birgt das Risiko, die Ladezeit der Seite zu erhöhen!

Jetzt fragen sich sicherlich einige, wie dass denn überhaupt möglich ist wenn man doch anstatt 20 Dateien nur noch eine lädt und somit die HTTP-Requests in Folge der JavaScript-Optimierung massiv gesunken sind. Die Frage lässt sich durch ein einfaches Beispiel illustrieren. Nehmen wir an, auf der Startseite des Shops werden die JavaScript-Dateien „abc.js“ und „xyz.js“ geladen. Diese Dateien werden überall geladen. Nach dem Aktivieren der Kombination werden diese zu (Beispiel) „abcdef.js“ kombiniert. Wenn der Nutzer die Startseite besucht wird die Datei einmal ausgeliefert und danach gecached. So weit, so gut. Sollte der Nutzer jedoch eine Produktseite besuchen, welche außer „abc.js“ und „xyz.js“ auch noch „foo.js“ und „bar.js“ benötigt, wird nochmals eine kombinierte Datei erstellt (Beispiel) – „ghijkl.js“. Da der Nutzer bereits die beiden ersten Dateien im Cache hat, muss der Browser jetzt unnötiger Weise trotzdem beide Dateien in Form von ghijkl.js ausliefern, welche auch „foo.js“ und „bar.js“ enthält.

Fehler 3: Massiver Overhead ohne jeglichen Nutzen bei Verwendung von Protokollen wie SPDY oder HTTP/2

Falls der Shopbetreiber bzw. dessen Entwickler einen Server betreiben, welcher die Protokolle SPDY oder dessen standardisierten Nachfolger HTTP/2 benutzt, ist die ganze Kombination von JavaScript-Dateien als JavaScript-Optimierung mehr Nachteil als Vorteil. Die HTTP/2 Spezifikation erlaubt es, parallel in nur einer einzigen HTTP-Request JavaScript-Dateien auszuliefern. Je nach Größe und Masse der einzubindenden JavaScript-Dateien kann dies beim Kombinieren zu erheblichen Leistungseinbußen führen. Angenommen ein großer Shop hat 40 JavaScript-Dateien, wobei einer dieser Dateien eine für JavaScript gigantische Größe von 700 Kilobytes hat. Diese Datei wird beim Kombinieren jedes mal gelesen und wieder in die kombinierte Datei geschrieben. Dieser Overhead ist bei der Verwendung von SPDY oder HTTP/2 unnötig und verursacht eine deutlich spür- und messbare Erhöhung der „Time To First Byte“, die Zeit die der Shop zum Senden des ersten Bytes an den User braucht.

Testszenarien und Auswertungen der JavaScript-Optimierung

Die hier gezeigten Ausschnitte des Testtools Webpagetest sollen lediglich der Illustration des Ladevorgangs dienen.
Die Zeiten der einzelnen Dateien sind hier nicht wirklich relevant, da wir kein wiederhol- und überprüfbares Testsetup aufgesetzt haben. Das soll in einem späteren Thread aber folgen.

Ladevorgang bei Verwendung von HTTP/1.1

Ladevorgang bei Verwendung von HTTP/1.1 mit Kombinierungstool

Ladevorgang bei Verwendung von HTTP/2

Ladevorgang bei Verwendung von HTTP/2 mit Kombinierungstool

Fazit

Trotz eines eingebauten JavaScript-Kombinierungstools ist es nicht ohne Weiteres möglich, Magentos eingebaute Performance Tools wie „JavaScript-Dateien kombinieren“ in einem produktivem Umfeld ohne ausgiebiges manuelles Testen zu benutzen. Es können schnell unverschuldet Fehler entstehen, welche die ganze Seite unbenutzbar machen. Des weiteren kann bei Benutzung von Magentos Funktion schnell eine Erhöhung der Seiten-Ladezeit anstatt der gewünschten Reduzierung eintreten.

Der Beitrag JavaScript-Optimierung in Magento erschien zuerst auf Entwicklungshilfe NRW.

In der Welt der Versionskontrollsysteme ist Git mit Abstand eines der effektivsten und einfachsten Tools die uns zur Verfügung stehen, um unseren Arbeitsalltag bzw. unseren Workflow zu optimieren. In diesem Artikel zeigen wir euch, wir ihr Git mit git-flow effektiver nutzt.

Git Branching

Wir gehen in unserem Beispiel davon aus, dass zwei neue Features für unser aktuelles Projekt geplant sind. Diese wollen wir, ohne uns als Entwickler gegenseitig auf die Füße zu treten, zeitgleich erledigen.

Dafür gibt es in Versionskontrollsysteme sogenannte Branches. Bei Git enthält jeder Branch eine eigene Kopie des jeweiligen Repositories zum Zeitpunkt der Erstellung des Branches. Den Verlauf einer Feature-Entwicklung im normalen Git-Workflow erklärt der nächste Absatz. Person A erstellt hier zum Beispiel eine Navigation speziell für Smartphones in unserem Projekt.

Einfacher Workflow ohne Branching-Modell:

Als erstes beziehen (clonen) wir das Git-Respository vom Server, um eine lokale Kopie des gesamten Projektes zu erhalten. In diesem wird nun auf dem Hauptbranch (Master) das Feature „Smartphone Navigation“ nach und nach programmiert. Die Schritte schliessen jeweils mit commit und anschliessendem push der Änderungen an das globale Repository ab. Die Webseite auf dem Produktions-Server wird anschliessend mit einem pull aktualisiert.

Das Problem an diesem Beispiel ist Folgendes:
Sobald eine weitere Person am selben Projekt arbeitet kann es zu Überschneidungen kommen. Angenommen Person A arbeitet an der Smartphone Navigation während Person B einen wichtigen Bugfix einspielt. Dadurch, dass Person B seinen Bugfix so schnell wie möglich auf der Live-Instanz des Projektes haben will, wird nach dem Hinzufügen des Bugfixes sofort der Master-Branch auf den neusten Stand gebracht. Das hat die Nebenwirkung zur Folge, dass auch Teile des Codes von Person A auf den Live-Server geladen werden und somit Probleme bzw. Fehler produzieren werden, da man nicht sicher sein kann, dass Person A seine Arbeit beendet hat. Und seien wir ehrlich – in Projekten mit mehr als einem Entwickler kommt es IMMER zu solchen Zuständen.

Lösungsansatz mit Git und einem einfachen Branching-Modell

Um solche Probleme zu umgehen hat man in Git die Möglichkeit einen oder mehrere Branches zu erstellen. Ein Branch ist eine Abzweigung der Codebasis zu einem bestimmten Punkt. Ab diesem Punkt kann man auf seinem Zweig (Branch) parallel zum Beispiel zum Hauptstrang in Ruhe entwicklen und erst das fertige Feature wieder zurück mergen.

Hier ein Beispiel:
Person A möchte eine Navigation für Smartphones erstellen ohne jemandem in die Quere zu kommen und geht jetzt wie folgt vor:
Git-Repository vom Server ziehen für eine lokale Kopie des gesamten Projektes. Neuen Branch erstellen mit dem Namen „develop“.
Auf diesem Branch kann jetzt unabhängig von anderen Branches weiter gearbeitet werden. Jegliche Änderung auf dem neu erstellten Branch wird zunächst keinerlei Auswirkung auf andere Branches haben. Sobald das neue Feature fertig ist, wird Person A seine Änderungen pushen und seine Änderungen in den Hauptbranch „mergen“ (zusammenführen).
Dieses Merging vom Branch „develop“ in den Hauptbranch des Projektes bewirkt, dass alle Änderungen im Smartphone Branch nun auch auf dem Hauptzweig des gesamten Projektes verfügbar sind.

Sollte während der Entwicklungszeit der Smartphone-Navigation Person B einen kritischen Bugfix in den Hauptbranch pushen, kann der Administrator ohne Einfluss der Codeänderungen für die Smartphone-Navigation den Hauptbranch updaten. Der Bugfix der auf dem Hauptbranch von Person B eingefügt wird, hat keinerlei Auswirkungen auf die Arbeit von Person A (Smartphone-Navigation Branch). Auch werden Codeänderungen von Person A keinen Einfluss auf die Arbeit von Person B haben, da beide verschiedene Branches verwenden.

Wenn dann jedoch nach der Fertigstellung der Smartphone-Navigation das gesamte Projekt diese neue Navigation erhalten soll, wird der Branch des neuen Features, in unserem Fall „develop“, einfach mit dem Hauptbranch zusammengeführt, woraufhin alle anderen Projektmitglieder die neuen Änderungen schließlich auch erhalten. Ausgenommen davon sind natürlich wieder die Projektmitglieder, die sich gerade auf einem anderen Branch befinden.

Lösungsansatz git-flow als Branching-Modell

„Git-flow“ ist ein Tool das den Workflow von Git erweitert und fest spezifiziert. Es kann per Kommandozeile oder per Tool bedient werden. So bieten zum Beispiel Sourcetree von Atlassian und PhpStorm Untersützung für git-flow. Die sehr feste Spezifizierung von git-flow hält den Workflows konstant und fördert den dezentralisierten Entwicklungsansatz. Zusätzlich zu den bekannten Hauptzweigen „master“ und „develop“ werden sogenannte Support-Branches erstellt, welche später für differenzierte Aufgaben verwendet werden. Diese werden auf verschiedene Art und Weise mit unseren Hauptzweigen „master“ und „develop“ zusammengeführt. Wir werden diese Support-Branches anhand von drei Beispielen kurz erklären.

Support-Branches bei git-flow

Derzeit haben wir in unserem Projekt zwei Zweige, „master“ und „develop“. „Master“ ist die aktuelle Live-Version des Projektes während „develop“ einen aktuellen Entwicklungsstand darstellt. „Git-flow“ fügt nun drei weitere Arten von Branches zu unserem Workflow: „release“, „feature“, und „hotfix“.

Hotfix-Branches

Der Hotfix-Branch wird von den beteiligten Entwicklern lediglich dazu benutzt Fehlerbehebungen des Live-Systems durchzuführen. Sobald ein Fehler behoben ist, wird der Hotfix-Branch geschlossen und mit „master“ und „develop“ zusammengeführt. Dieses führt auf der einen Seite zu einem sauber aktualisierten Live-System und auf der anderen Seite wird der Hotfix in die Entwicklungsschiene transferiert, da sämtliche anderen Branches vom „develop“ Branch abhängen.
Hotfix-Branch Workflow © nvie.com

Feature-Branches

Der Feature-Branch wird als Zweig zur Erstellung neuer Funktionen verwendet. Sobald eine neue Funktionalität abgeschlossen ist, wird der Feature-Branch auf mit dem Develop-Branch zusammengeführt und kann auf einer Testinstanz unabhängig von unserem Master branch getestet werden. Feature-Branches sollten in dieser Struktur lediglich lokal vorkommen.
Feature-Branch Workflow © nvie.com

Release-Branches

Der Release-Branch wird bei jedem neuen Release oder großen Codeänderung (Milestone) benutzt. Ein Release kann zum Beispiel eine Sammlung von verschiedenen Features sein, welche als Release-Branch gruppiert bzw. zusammengefasst werden, um gemeinsam deployed zu werden. Ein Release-Branch sollte immer mit „master“ als auch „develop“ zusammengeführt werden, wobei letzterer für die Qualitätssicherung inklusive Testing Vorrang hat.

Fazit

Das Arbeiten mit git-flow oder generell die korrekte Nutzung von Branching stellt eine qualitätssichernde sowie Workflow-optimierende Maßnahme da, die uns hilft sauber und getrennt voneinander unseren Aufgaben nach zu gehen, ohne die Arbeit des Anderen zu beeinträchtigen.

Der Beitrag git-flow – das Branching-Modell erschien zuerst auf Entwicklungshilfe NRW.

Voraussetzungen für einen erfolgreichen Workflow

Grundlage für den hier gezeigten Workflow sind PhpStorm als IDE mit installiertem git-flow-Plugin sowie ein funktionierendes Ticketsystem Redmine. Natürlich gibt es Alternativen zu dieser Kombination. PhpStorm arbeitet mit sehr vielen Systemen zusammen, und auch andere IDEs haben ähnliche Funktionen. Der Workflow im Versionskontrollsystem basiert auf unserer git-flow-Präsentation und ist aus meiner Sicht zwar im Feinen anpassbar, im Groben aber alternativlos.

Ticketsystem Redmine richtig einstellen

Das Ticketsystem sollte von außen erreichbar sein. Der zur Verknüpfung benutzte User sollte im Ticketsystem aktiv sein und Projekte und Tasks – im Weiteren auch Issues genannt – zugewiesen haben. Zusätzlich muss die REST-Api in der Konfiguration des Ticketsystems aktiviert sein.

In PhpStorm geht es weiter

In PhpStorm geht man zunächst über die Tastenkombi cmd+“,“ (Mac) in die Einstellungen und navigiert zu Tools -> Tasks -> Servers. Dort setzt man nach Auswahl des Ticketsystems die URL und Zugangsdaten zu seinem Ticketsystem.

Ein Klick auf den Test-Button liefert das Ergebnis:

Im zweiten Reiter stellt man die Commit-Einstellungen ein. Das Ticketsystem Redmine ist in der Lage, Commit-Nachrichten auszulesen und darauf zu reagieren. Eine sinnvolle Einstellung zur Automatisierung spart hier wertvolle Zeit.

Optimaler Workflow in PhpStorm mit dem Ticketsystem Redmine

Die Voraussetzungen sind hier ein Projekt im ausgecheckten develop-Branch, ein vorhandenes Ticket und eine eingerichtete Entwicklungsumgebung.

Die Steuerungsleiste für das Taskmanagement befindet sich im rechten oberen Bereich.

Über das Dropdown kommt man in den „Task öffnen“-Dialog.

Nach erfolgreichem Öffnen eines Tasks sollte man eine für den Task eingerichtete Changelist in PhpStorm und auf Ebene der Versionskontrolle einen Feature-Branch ausgecheckt haben.

Sollte man seine relevanten Entwicklungen lokal abgeschlossen haben, kommt der Zeitpunkt, an dem man seinen Code committet. Durch die Nutzung der taskrelevanten Changelisten ist dies selbst bei Bearbeitung mehrerer Issues in einem Projekt durchschaubar. Zudem verringern die voreingestellten Informationen aus dem Ticketsystem die manuell einzugebenden Informationen.

Vor dem anschließenden Push zeigt PhpStorm eine Zusammenfassung der Änderungen.

Als Abschluss muss man das Feature leider noch manuell über das git-flow-Plugin schließen, aber ich hoffe, dass das in naher Zukunft automatisiert wird.

Als Meldung sollte PhpStorm einblenden, dass der Feature-Branch erfolgreich zurückgemerged wurde.

Es kann zudem vorkommen, dass PhpStorm die Changelist nicht löscht. Um die Ordnung nicht zu verlieren, hilft das manuelle Löschen.

Außerdem kann es helfen, bei zu vielen Issues in der Liste auch diese manuell zu löschen.

Überprüfung in der Versionskontrolle und im Ticketsystem Redmine

Wer ähnlich wie wir Redmine mit gitolite und dem redmine git hosting nutzt, kann jetzt in seinem Projekt bei Redmine im Projektarchiv seinen neuen Workflow überprüfen.

Weiterführende Informationen zum Beispiel vom PhpStorm-Hersteller Jetbrains bekommt ihr hier.

Nutzt ihr in euren PHP-Projekten eine andere Kombination von Ticketsystem, Versionskontrolle und IDE? Wenn ja, dann schreibt uns hier doch bitte mal, welche das sind. Denn von einem solchen Know-how-Austausch profitieren ja letztlich alle. Die oben beschriebene Kombination schulen wir übrigens auch.

Der Beitrag PhpStorm mit dem Ticketsystem Redmine nutzen erschien zuerst auf Entwicklungshilfe NRW.