Paul Boisvert startet die Meet Magento mit der Keynote über Magento 2

Nach einem leckeren, jedoch kurzen Frühstück begann der erste Tag der Meet Magento mit einer Keynote von Paul Boisvert, dem Head of Product Management bei Magento. Es stellte die Roadmap für Magento2 vor mit einigen interessanten neuen Features sowie der Advanced-CMS-Integration für die Magento Enterprise Edition und dem wichtigen Hinweis, dass jeglicher Support und dementsprechend auch Sicherheitspatches für Magento 1 ab November 2018 eingestellt wird [Das wurde mittlerweile zurückgeszogen, es soll ein verlängertes EOL für Magento 1 geben]. Seiner Meinung – und der Stimme ich voll zu – sollten Shop-Betreiber langsam Magento 2 in Angriff nehmen und sich so für die Zukunft mit einer langfristig unterstützen Version von Magento sicher aufstellen. Deshalb sehe er den Fokus der diesjährigen Meet Magento klar auf Magento 2.

Gute Desktop Version eines Shops besser als schlechter mobile first Ansatz

Danach ging es für mich nach kurzem Talk mit alten Bekannten auf der Meet Magento in einen weiteren Vortrag von Jan Sperlich, der mir hochgelobt angekündigt wurde. Und ich muss sagen, ich wurde nicht enttäuscht. Die Kernaussage seiner Präsentation war: eine guter Desktop-Shop ist besser als eine schlechte mobile Website. Er präsentierte in einem Praxisbeispiel seines Unternehmens. Durch gezielte Optimierung der Onlinepräsenz (Desktop Website) und auch Optimierung der Darstellung auf mobilen Endgeräten (ohne dedizierte App) war es möglich, die Conversion Rate des besagten Shops signifikant zu erhöhen. Und zwar anders als mit einer separaten mobilen App. Das ließ den gesamten Saal feststellen, dass Responsive-Design anscheinend immer noch weit vor der Useability oder zumindest der Beliebtheit einer mobilen App liegen.

Suche das wichtigste Feature in einem Shop

Eher kurz fassen werde ich mich zu dem Talk von Dr. David Urbansky. Nach einer ausgiebigen Mittagspause mit lauter gesundem Zeugs und leckeren Wraps erzählte uns Dr. David Urbansky etwas über seine Theorie des wichtigsten Online-Shop Features überhaupt – der Suche.
Seine Kernaussage war, dass die Suche mittlerweile das mit Abstand wichtigste Feature einer Website ist. Er präsentierte eine ca 15 Punkte-Liste welche simple und auch komplexe Funktionen einer Suche enthielt und auf den Prüfstand stellte (Synonymsuche, Fön/Haartrockner, etc.). Ein insgesamt eher komplexer Vortrag mit jedoch auch sehr verständlichen Argumenten und Tipps für die Integration einer guten Suchen in Magento 2. Die Umsetzung ist jedoch seiner Meinung nach (auch durch die Magento Suchimplementierung) verbesserungswürdig. Dem Stimme ich und nicht wenige Leute aus dem Saal zu.

Nutzerfreundlichkeit für Suchmaschinenfreundlichkeit

Der letzte Vortrag für mich an diesem Tag war ein meiner Meinung nach sehr interessanter Vortrag von Mario Jung mit der Kernaussage: Baue die Website für den User und nicht für Google/Bing/Yahoo.
Er stellte eine Liste vor mit seinen 10 Tipps, wie man die Nutzerfreundlichkeit im Shop verbessert. Einige dieser Punkte sind sinnvoll und auch SEO-technisch relevant. Ein Vorschlag von Herr Jung, wie die Implementierung eines Chatbots zur Beantwortung von Kundenfragen halte ich jedoch für etwas gewagt. Den Rest seines Vortrags kann ich nur wärmstens empfehlen, denn er empfiehlt auch Testing, Strukturierung und andere sinnvolle Sachen die PHP/Javascript Programmierer gerne mal vergessen. Alles in allem stimmt seine 10 Punkte Liste und sollte bestimmt einigen Entwicklern helfen. Die Liste möchte ich euch nicht vorenthalten:

1. Biete dem Kunden gewohnte Sachen. (Logo links oben, Cart rechts oben, etc)
2. Produktfilter und erweiterte Suche anbieten
3. Chatbot (Automatisiert oder mit Person dahinter)
4. Ladezeit so gering wie möglich halten
5. Nicht an aussagekräftigen und individuellen Bildern sparen
6. Professionelle Produktvideos stellen einen zukünftigen Trend dar
7. Linkbuilding bringt einen erhöhten Traffic
8. Arbeite mit Screaming-Tools
9. Nie aufhören zu testen! (A/B-Tests, Unit, whatever)
10. Frage andere (Kritik annehmen, eventuell sogar ein feature für Kritikannahme bauen)

Nach einem bisschen Small Talk mit anderen Magento Entwicklern, sowie viel Kaffee und einem weiteren kleinen Vortrag ging es dann gegen 19 Uhr zur Aftershowparty. Wie jedes Jahr wurde auch diese Aftershowparty in der Moritzbastei abgehalten und bestach durch eine super Atmosphäre. Gesponsert von maxcluster gab es für alle reichlich zu Essen und zu Trinken so viel das Herz begehrte.

Testautomatisierung und Sicherheit

Der zweite Tag der Meet Magento begann für mich verspätet. Durch gefühlt 300 Talks mit Entwicklern, Agentur-Chefs und Organizern der Meet Magento wurde am Tag der Aftershowparty bis spät in die Nacht „genetzwerkt“. Nach dem die Verleihung des Meet Magento Awards bereits vorbei war, ging es für mich direkt weiter in einen Vortrag von Fabian Schmengler über Test Automation in Magento. Er erläuterte verschiedene Methoden um seine Magento Extensions mit verschiedenen Tests zu prüfen. [Ich habe hier mal über Codeception als Frontend Testframework gebloggt.] [Gratulation an dieser Stelle noch mal an Rico Neitzel für den Meet Magento People Award]
Nach einer Mittagspause und reichlich Kaffee zur Beseitigung der Folgen des Vorabends ging es in einen Vortrag von Anna Völkl. Ihr Talk war zum Thema Sicherheit in Online-Shops bzw. die Verbesserung dieser. Sie zeigte einige jüngere Beispiele auf in denen bei großen Online-Shops kritische Sicherheitslücken gefunden wurden. Zudem erklärte sie Methoden und Maßnahmen zur Verbesserung der Security in Magento Shops und deren Extensions. Trotz softwaretechnischer Fokussierung waren auch Monitoring und Konfiguration des Servers Teil Ihres Talks.

Der letzte Vortrag dieses Tages für mich war von Nils Kattau und handelte von der Optimierung der Sales bzw. der Conversion in Online-Shops. Ein sehr interessanter Vortrag mit einigen Praxisbeispielen der jedoch den Rahmen dieses Posts bei weitem sprengen würde.

Vorher leider den Hackathon verpasst

Damit war die Meet Magento für mich auch für dieses Jahr schon vorbei. Schlimm genug dass ich es dieses Jahr wieder nicht auf den Magento Hackathon geschafft habe. Dieser findet jedes 2-3 Tage vor der Meet Magento statt und sticht mit Community-Coding, viel Club-Mate und noch mehr „Netzwerken“ heraus.

Der Beitrag Recap Meet Magento 2017 – Leipzig erschien zuerst auf Entwicklungshilfe NRW.

Gerade im Webdevelopment erfordern die immer dynamischeren Marktentwicklungen und entsprechend hohen User-Erwartungen ein breites Weiterbildungsangebot für Webentwickler. In Metropolen wie Berlin, München und Köln oder Ballungsräumen wie dem Ruhrgebiet gibt es hierzu zahlreiche Möglichkeiten. Etwas anders sieht es hingegen in strukturschwachen Regionen bzw. abseits der großen Wirtschaftszentren aus. Selbst User Groups sind hier eher rar gesät.

„Wir sind hier in Großwallstadt schon etwas weit vom Schuss, wenn es um inhaltlich aktuelle Weiterbildungsmöglichkeiten für Webdeveloper geht“, sagt Philipp Packheiser, Geschäftsführer des Online-Marktplatzes für Kfz-Ersatzteile TEILeHABER. „Unsere Mitarbeiter müssten daher schon ins 50 Kilometer entfernte Frankfurt am Main fahren, um sich auf den neuesten Stand bringen zu lassen.“ Ein Problem, dass sich in ähnlicher Weise auch den Auszubildenden des unterfränkischen Ausbildungsbetriebs stellt, da der Lehrplan der örtlichen Berufsschule aufgrund der eingangs umrissenen Situation naturgemäß immer ein wenig der Zeit hinterherhinkt. „So betrachtet kommt uns das Vor-Ort-Schulungsangebot von Entwicklungshilfe NRW da sehr entgegen“, so Packheiser weiter. „Denn wir halten es für absolut unabdingbar, dass sich unsere Entwickler regelmäßig mit modernen Technologien auseinandersetzen.“

Einführung automatisierter Frontend-Tests

Gesucht hatte das 2007 gegründete Unternehmen unter anderem nach Schulungen zu automatisierten Testings und war über einen Fachbeitrag von Roland Golla im PHP Magazin auf Entwicklungshilfe NRW aufmerksam geworden. Die Wahl fiel auf die PHP-Schulung Code Rocker, die eine Art Best-of aus dem gesamten Schulungsangebot ist und einen schnellen Einstieg ins Thema ermöglicht. Mit dem 22. September 2016 wurde dann ein Schulungstermin für zwei Fachinformatiker Anwendungsentwicklung, drei Azubis Anwendungsentwicklung und den Scrum Master von TEILeHABER vereinbart.

„Wenn man eine Plattform betreibt, auf der zig Millionen einzelne Artikel angeboten werden, dann kommt man mit manuellem Frontend-Testing natürlich nicht allzu weit“, sagt Golla, der als Dozent vor Ort beim Kunden war. „Beziehungsweise bindet man dadurch jede Menge Kapazitäten, die man besser woanders einsetzen kann.“ Daher bestand das Ziel der ganztägigen, sehr individuell gehaltenen Schulung zum einen darin, einige wichtige neue Technologien und Tools vorzustellen sowie einen ersten automatisierten Test für den Shop umzusetzen, und zum anderen sollte der Workflow des jungen Teams optimiert werden, um damit die Weichen für Continuous Integration zu stellen.

Tooling und Set-up signifikant verbessert

Die Schwerpunkte lagen damit auf den Themen Codeception Frontend Testing und PhpStorm Best Practice. Zudem wurde der PHP Mess Detector vorgestellt und eingesetzt. Mit diesem lassen sich Probleme im bestehenden Code aufspüren, darunter etwa Flüchtigkeitsfehler. Alles sehr praxisnah und ganz am aktuellen Bedarf des Kunden orientiert. Die größtmögliche Praxisnähe ist ja seit jeher der Kerngedanke von Entwicklungshilfe NRW: Somit sollen die geschulten Teams in die Lage versetzt werden, das neue Wissen sofort praktisch ein- und umsetzen zu können.

„Der Tag ist echt super gelaufen“, befindet Golla. „Die Jungs haben sehr gut mitgemacht und das neue Wissen nur so aufgesaugt. Ich denke, dass ich dem Entwickler-Team von TEILeHABER schon mit diesem ersten Schritt entscheidend weiterhelfen konnte.“ Seiner Einschätzung nach wurde das Tooling und Set-up des Teams dadurch signifikant verbessert. Eine Einschätzung, die Packheiser rundum teilt: „Wir sind mehr als zufrieden mit dem Ergebnis und können uns gut vorstellen, auch in Zukunft das Weiterbildungsangebot von Entwicklungshilfe NRW zu nutzen.“

Hier erfahrt ihr mehr über das PHP-Schulungsangebot von Entwicklungshilfe NRW.

Der Beitrag Entwicklungshilfe NRW schult Team von Online-Marktplatz erschien zuerst auf Entwicklungshilfe NRW.

In diesem Artikel befassen wir uns mit den mit der Ladezeit-Optimierung von Magento Shopsystemen. Magento ist ein umfangreiches Shopsystem und ist in bestimmten Konfigurationen anfällig für Performance-Probleme. Die fünf größten Fehler mit teils massiven Auswirkungen auf die Magento-Performance haben wir hier für euch aufgelistet und erklären mögliche Lösungen.

Die 5 häufigsten Fehler bei der Ladezeit-Optimierung

1) Ladezeit-Optimierung durch Verwendung der richtigen Festplatte

Magento ist wie schon erwähnt ein umfangreiches System welches in der Ausführung „Community Edition“ mehr als 15.000 Dateien beinhaltet. Das auf PHP basierende Shopsystem arbeitet mit zahlreichen Funktionen, welche die Festplatte massiv beanspruchen. Dazu gehören das Schreiben in Logfiles (access, system, exception log), das Anfordern von Files (require, file_get_contents) und das Laden von Daten aus der Datenbank. Der Einsatz einer SSD anstelle einer HDD lohnt sich beim professionellen Einsatz von Magento umso mehr, da die Magento-Performance drastisch verbessert wird.

Bildquelle: https://blog.amasty.com

2) Ladezeit-Optimierung durch Verwendung eines Caches

Magento benutzt wie die meisten großen System ein internes System zum Cachen von Daten, um die Ladezeit zu verkürzen. Es können verschiede Cache-Arten verwendet werden, welche nachfolgende Vorteile und Nachteile mit sich bringen. Wir werden dies anhand von 3 Beispielen kurz erläutern.

2.1) APC / Memcached

Diese beiden Cache-Arten benutzen den internen Speicher (RAM) des Servers zum Cachen der Daten von Magento. Der Nachteil dieser beiden Cache-Varianten ist, dass RAM zum Beispiel auf einem Shared Server nur in Maßen zur Verfügung steht und sparsam damit umgegangen werden muss. Der Vorteil ist dass diese Cache-Arten relativ schnell sind, da sie kleine Datenmengen aus dem RAM schnell ausliefern können.

2.2) Der Datenbankcache

Der Datenbankcache ist eine separate Cache-Art und kann unabhängig von den beiden anderen Cache-Arten benutzt werden. Dieser Cache ist zuständig für das Zwischenspeichern von öfter ausgeführten Queries die sich ansonsten mit minimalen Änderungen wiederholen würden. Magento speichert diese Art von Anfrage im RAM zwischen und führt diese dann aus ohne jedes mal erneut mehrere Datenbankabfragen an den Server zu stellen. Der Datenbankcache kann bei genügend vorhandenem RAM oder schnellem Festplattenspeicher zu einer signifikanten Optimierung der Ladezeit führen, da Magento mehrere Queries pro Seitenaufruf benötigt und diese eingespart werden können.

2.3) Der Filecache

Dieser Cache benutzt das interne Dateisystem zum Vorhalten der Daten. Die Vorzüge dieser Cache-Art ist, dass er in Kombination mit einer SSD sehr schnell ist und die üblichen RAM limits von APC / Memcache getrost ignorieren kann, da er lediglich ein wenig Festplattenkapazität voraussetzt. Der Nachteil jedoch ist, dass diese Art von Cache ohne eine SSD extrem langsam ist. Wie beim Datenbankcache wird der Filecache das gesamte System ohne eine SSD mehr ausbremsen als beschleunigen.

Seit der Version 5.5 von PHP wird Zends sogenannter OpCache (Opcode-Cache) mitgeliefert und standardmäßig installiert. Dieser Opcode-Cache ist schnell und kostengünstig in der RAM-Benutzung. Sollte PHP 5.5 oder höher auf dem Magento System installiert sein, empfiehlt es sich den von PHP mitgelieferten OpCache in Kombination mit dem Filecache zu benutzen, sofern eine SSD vorhanden ist.

3) SQL Statements

Ein nicht zu verachtender weiterer Punkt in der Liste der Performance-Flaschenhälse sind SQL Statements. Dabei geht es hier nicht um eine bestimmte Art von SQL Statements, sondern um deren Verwendung. Das folgende Beispiel ist ein Auszug aus einem Magento Modul welches 9 Produkte einer Kategorie per AJAX nachlädt und im späteren Verlauf verarbeitet und ausgibt.

foreach ($this->getProductIds() as $productId){
    $product = Mage::getModel('catalog/product')->load($productId);
    $this->processProduct($product);
}

Wie im Code zu sehen ist, werden bei jedem Aufruf des PHP-Skripts die Produkt-IDs geladen und dann in einer foreach Schleife das jeweilige Produktmodel geladen. Das Problem dabei ist, dass jedes Produktmodel einzeln geladen wird und für jedes dieser Produkte mehrere Queries verwendet werden. Bei einer Anzahl von 500 Produkten sind wir somit bei sage und schreibe ca 2500-5000 SQL-Queries, je nachdem wie viele Attribute die besagten Produkte besitzen. Der richtige Weg unter Berücksichtigung der Magento-Performance und Logik sieht wie folgt aus:

$collection = Mage:getResourceModel('catalog/product_collection')
    ->addFieldsToFilter('entity_id', array($this->getProductIds()))
    ->addAttributeToSelect(array('name'));

foreach ($collection as $product){
    $this->processProduct($product);
}

Hier wird die ganze Produktkollektion nur ein mal geladen. Nachdem die Filter hinzugefügt wurden, werden die Produkte dann mit einer Schleife über die $collection variable verarbeitet. In diesem Code werden maximal ein bis zwei Dutzend SQL queries verwendet, was sich spürbar auf die gesamte Ladezeit der Seite auswirkt.

Quelle Beispiel: http://labs.octivi.com/ (Bad SQL Queries)

4) Ladezeit-Optimierung durch Verwendung vorgerenderter Bilder

Magento wird in seiner Standard-Konfiguration mit zahlreichen Bilder ausgeliefert. Sobald ein Shopbetreiber seine Produkte und dazugehörige Bilder anlegt, ist man schnell bei ~20-30 Bildern pro Kategorieseite und noch mehr Bildern auf der Produktdetailseite angelangt. Je nach Berücksichtigung der durchschnittlichen Bildgröße, so um die ~0.5-2 Megabyte an Daten betragen dürfte. Auch Bilder welche in ihrer Dimension zu groß sind, sollten vor dem Verwenden verkleinert werden, um so wertvolle Bandbreite zu sparen und mobile Shopbesucher nicht mit größeren Datenvolumen zu belasten. Die richtige Größe der Bilder sowie deren Optimierung durch ein externes Werkzeug wie optipng bewirken eine schnellere Ladezeit der Seite durch weniger Datenvolumen und macht sich schnell auch im praktischen Testen bemerkbar.

5) Steigerung der Magento-Performance durch Verwendung der neuesten PHP Version.

PHP hat seit Version 5.5 einen enormen Geschwindigkeitszuwachs erhalten. Jetzt, mit Version 7.0, ist die Sprache auf der Magento sein Grundgerüst aufbaut sogar doppelt so schnell wie sein Vorgänger PHP 5.5 bzw 5.6 und somit um ein Vielfaches schneller als das immer noch weit verbreitete PHP 5.4. Deshalb ist es empfehlenswert bei einer Magento-Installation, mindestens PHP in der Version 5.5 bzw 5.6 auf dem Server installiert zu haben. Der eingebaute Zend OpCache ab Version 5.5 beschleunigt einen frisch installierten Magento Shop um bis zu ~40% ohne jegliche Änderungen an der Konfiguration oder der Hardware. PHP Version 7.0 steigert diesen Geschwindigkeitszuwachs noch einmal um satte 100% durch die effektivere Handhabung von Arrays und großen Objekten, von welchen Magento durchweg exzessiven Gebrauch macht. Eine Magento-Installation mit PHP 7.0 lädt im Vergleich zu einer Magento installation mit PHP 5.4 um bis zu 1.6 Sekunden schneller.

Bildquelle: https://www.mgt-commerce.com/blog/

Fazit

Durch Befolgen der genannten 5 Aspekte kann man ohne viel Aufwand bereits eine spürbare Steigerung der Magento-Performance erreichen. Natürlich gibt es weitere Punkte, welche die Geschwindigkeit einer Magento-Installation beschleunigen können. Wir haben uns hier jedoch auf die Punkte mit den prozentual größten Geschwindigkeitseinbußen bei Missachtung konzentriert.

Der Beitrag Magento-Performance: Flaschenhälse erschien zuerst auf Entwicklungshilfe NRW.

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.

Die Installation

Codeception kann hier via Composer installiert werden. Jedoch wird davon in unserem Beispiel kein Gebrauch gemacht, da wir den sofortigen Einsatz von Codeception auf einer frischen VM realisieren, und somit keinen Composer installiert haben.

Mac/Linux:
Auf dem Mac bzw Linux und Unix derivaten kann Codeception auch per Command-line installiert werden.

wget http://codeception.com/codecept.phar && php codeception.phar bootstrap

mit diesem beidem Befehlen wird Codeception installiert und dessen Ordnerstruktur erstellt.

Windows:
Auf Windows muss das installationsarchiv hier manuell heruntergeladen werden von:

Nach der Installation auf Windows hat Codeception die benötigte Ordnerstruktur erstellt.

Sollte das Frontend-Testing mit Google Chrome, Firefox oder anderen Browsern durchgeführt werden, wird auch Selenium benötigt. Die Installation kann auf einem Mac/Linux per Kommandozeile mit folgenden Befehlen geschehen.

Mac:

brew install selenium-server

Linux:

apt-get install selenium-server

Auf Windows muss der Selenium Server von http://selenium.org heruntergeladen und installiert werden.

Nachdem Selenium und Codeception installiert sind, gestaltet sich der Rest der Konfiguration relativ einfach. Zunächst können im „_env“ Verzeichnis von Codeception sogenannte Testumgebungen angelegt werden, welche der Reihe nach von Codeception durchlaufen und abgearbeitet werden. Ein Beispiel für einen solche Datei sieht wie folgt aus.

In diesem .yml file wird festgelegt, dass der zu testende Browser Google Chrome sein wird.
Des Weiteren wird festgelegt, dass wir in der Auflösung 1920×1080 testen werden.
Die URL kann pro Testumgebung jeweils eine URL beinhalten, welche in unserem Testszenario momentan auf einen unserer Testserver zeigt.

Vorbereitungen für das Frontend-Testing

Nachdem wir unsere Umgebungsvariablen festgelegt haben, können wir uns der nächsten wichtigen Datei widmen. Die Datei __bootstrap.php aus dem Verzeichnis „acceptance“ wird vor jedem Test aufgerufen und erlaubt es, Variablen zu deklarieren die dann in den jeweiligen Testszenarien verwendet werden können. Diese Variablen bestehen den ganzen Test über und können von den verschiedenen Szenarien gemeinsam benutzt werden. Eine sinnvolle Verwendung dieser Datei wäre zum Beispiel eine Funktion zum erkennen des benutzten Browsers, um in den Tests darauf entsprechend reagieren zu können und die Tests für den jeweiligen Browser besser anzupassen.

Beispiel: Sollte die Funktion in __bootstrap.php ein mobiles Endgerät entdecken, kann der darauf folgende Test in seinem Testszenario darauf reagieren und zum Beispiel die mobile Navigation anstatt die normale Navigation Testen.

Hinweis: Bevor die Testszenarien durchlaufen werden können, muss Selenium entweder auf Windows mit einem Doppelklick, oder auf Mac bzw Linux/Unix derivaten mit dem Konsolenbefehl „selenium-server -p 4444“ gestartet werden.

Das Testszenario

Kommen wir nun zu den eigentlichen Tests. Jedes Testszenario das wir anlegen wollen, muss sich im „acceptance“ Verzeichnis befinden. Jede PHP datei außer __bootstrap.php wird dort für jede einzelne Testumgebung die wir im „_env“ Verzeichnis liegen haben durchlaufen. Haben wir zum Beispiel ein Testszenario wie „Navigation.php“ im „acceptance“ folder, wird dieses Szenario für chrome_1920x1080.yml aufgerufen.
Ein Beispiel eines solchen Tests sieht wie folgt aus.

amOnPage("/");
    $I->wantTo("test elements of the navigation (upper categories)");
    $I->click(".menu-button");
    $I->click("#nav-wide .level0.nav-1 a span");
    $I->moveMouseOver("#nav-wide .level0.nav-1 a span");
    $I->click(".level1.nav-1-1  a span");
?>

Der obrige test wurde mit dem Befehl „php codecept.phar run acceptance –env chrome_1920x1080“ aufgerufen. Für jede weitere Testumgebung die in die Testszenarien eingebunden werden soll, wird eine weitere –env Direktive benötigt.

Beispiel 2 Browser:

php codecept.phar run acceptance --env chrome_1920x1080 --env firefox_1920x1080

Hint: Während eines Tests der Funktionen wie $i->moveMouseOver() enthält darf die Maus nicht bewegt werden!

Je nach Generalisierung der Tests wie Beispielsweise oben beschrieben, lässt dich der Test für mehrere Anwendungszwecke verwenden. In unserem Fall ist der oben zu sehende Test für jegliches Login-Formular einer Magento-Shop Webseite einsetzbar.

Nachdem Codeception die Tests erfolgreich (oder auch nicht) beendet hat, wenden wir uns dem Verzeichnis „records“ zu. Im Verzeichnis „records“ befinden sich Screenshots von jedem einzelnen Schritt unserer Tests und dem Ergebnis. Es bleibt einem die Möglichkeit entweder die Datei „index.html“ zu öffnen und sich in einem minimalistisch gestalteten Web-interface durch die Ergebnisse zu klicken oder sich die einzelnen Fehlgeschlagenen Tests heraus zu suchen. Fehlgeschlagene Tests haben eine „.fail.“-Endung im Dateiname und sind direkt in „records“ Ordner zu finden.

Hint: Der Befehl $i->wait() veranlasst Codeception dazu, eine gewisse Zeit zu warten und einen neuen Screenshot zu erstellen.

Fazit:

Codeception ist ein effizient einsetzbares Tool mit noch kleinen Schönheitsfehlern, wie zum Beispiel das unnötige Erstellen eines Screenshots nach Verwendung des $i->wait() Befehls, die einen Entwickler jedoch keinesfalls am produktiven Einsatz des Frameworks hindern. Es stellt mit seiner einfachen Syntax und leichten Bedienbarkeit eine effektive Methode für das Frontend-Testing dar.

Der Beitrag Frontend-Testing mit Codeception erschien zuerst auf Entwicklungshilfe NRW.

Mein Plan als Magento-Entwickler für das Wochenende

Mein Plan war es eigentlich, für mein bestehendes Projekt und die darin schon gefundenen Stolpersteine Hilfe zu finden. Aus Entwickler-Sicht ist das Projekt relativ klein, da es sich lediglich um eine Migration von Magento 1.x auf 2.x ohne aktivierte Einkaufsmöglichkeit handelt. Damit entfällt die ganze Warenkorb/Checkout/AfterSales-Funktionalität. Auch E-Mail-Templates sind nicht großartig zu beachten. Das Projekt enthält jedoch ein komplettes Redesign. Damit kam es mir als Einstiegsprojekt für eine Migration sehr gelegen.

Die Stolpersteine, die sich so auftaten, während ich mich alleine mit den Dokus ans Projekt machte, tauchten an diesem Wochenende auch bei anderen auf – puuh, ich war also nicht alleine.

Da wäre zum Beispiel die einfache Aufgabe, Nummer 2 erstmal ans Laufen zu kriegen. Der Umstieg der anwesenden, durch die Bank erfahrenen alten Magento-Hasen auf das Neue-und-Alles-ist-besser-Magento gelang nicht ganz so flüssig, wie die Magento-Marketingler das gerne auf allen Kanälen hinausschreien. Beim ersten Anlegen des Projektes damals liefen bei mir die Installation und auch alles andere reibungslos. Beim Anlegen der neuen Installation für das Wochenende aber hatte ich dann Probleme damit und habe mir nebenbei mit einem Update von Version 2.0.0 auf 2.0.1 das oben beschriebene Projekt so zerschossen, dass nur noch ein Backup half.

Auch die ersten Schritte eines eigenen Templates mit der Frage „Wie bekomme ich jetzt Magento dazu, meinen Style auszuliefern?“ kamen mir seltsam bekannt vor.

Was wirklich geschah am Wochenende

Nun ja, was soll ich sagen …? Ich habe zum ersten Mal eine Pre-Party verpasst und bin erst morgens am Tag der Veranstaltung angereist. Man wird halt nicht jünger. Da ich wegen meiner Diplomarbeit letztes Jahr recht selten auf Firegento-Events war, musste man auch erstmal ordentlich netzwerken und persönlich werden. Da das aber einer der Hauptgründe für mich ist, solche Events zu besuchen, fing ich damit an. Also MacBook auf, Magento 2 laden und anfangen zu quatschen. Alibimäßig hatte ich mich deswegen auch in die Gruppe „Ist Magento 2 Mist?“ geschmissen. Das ging so den ganzen Samstag: Versuchen Magento zu installieren, quatschen über das letzte halbe Jahr, auf den Bildschirm gucken, ob die Kiste vorankommt, essen, quatschen. Zack war abends, und man saß noch in einer kleinen Runde im Brauhaus. Man ahnt es: quatschen.

Der nächste Tag sollte produktiver werden, und ich gesellte mich direkt zum Team „Migration von Firegento-PDF auf Magento 2“, dem ich samstags schon ein wenig helfen konnte.

Der Sonntag verlief dann recht flüssig mit richtiger Arbeit an Magento 2. Bis zum Versuch, die Abschlusspräsentation per Videokonferenz mit gleich zwei Ablegern des Hackathons zu halten. Am Ende gelang es irgendwie, und es ging für mich zurück nach Köln (Notiz an mich: App entwickeln, die für Events Fahrgemeinschaften erzwingt).

Schönen Dank an dieser Stelle an code-x fürs Gastgeben und an die Sponsoren!

Was ich über Magento 2 gelernt habe

Zusammenfassend lässt sich sagen: Nicht alles läuft glatt am Anfang jeder neuen Version – das ist das tägliche Brot für uns PHP-Entwickler. Ich war nicht alleine mit meinen Problemen und habe Trost und Hilfe bekommen. Da ich schon etwas tiefer in der Materie drin war, konnte ich auch selbst ein paar Mal helfen. Schönes Gefühl.

Magento 2 ist schon ein ausgereifteres Softwareprodukt als die damalige Frühversion von Magento 1 – aber aus meiner Sicht noch nicht wirklich startklar als Shop-System-Lösung für deutsche Kunden. Zudem sind bisher zu wenige Module portiert. In welchem Zeitrahmen sich das ändert, bleibt abzuwarten und zu beobachten. Die Neugierde und der Wille, mit Magento 2 zu arbeiten, war an dem Wochenende jedoch deutlich spürbar.

Der Beitrag Besuch beim Magento 2 Hackathon in Paderborn erschien zuerst auf Entwicklungshilfe NRW.

In Stellenausschreibungen steht heute immer öfter die Anforderung, Git über die Command Line zu nutzen. Gerade bei Senior-Entwicklern wird dieses Wissen bereits explizit vorausgesetzt. Das Command-Line-Wissen kannst du dann auch anwenden, wenn dir kein Rechner mit Sourcetree zur Verfügung steht, weil du dich vielleicht direkt auf den Linux-Servern lokal oder remote bewegen musst.

Git Commands, die tatsächlich gebraucht werden

Es sind nicht so viele Git Commands, die für die tägliche Arbeit gebraucht werden, wie man vielleicht glaubt. Hier mal ein einfacher Task mit den Git-Commands direkt auf der Command Line.

Git Repository klonen

git clone https://url.com/example-repo

Mit dem Git Command wird das Repo in das Verzeichnis „example-repo“ geklont. Gibt man hinter der URL ein anderes Ziel oder Target an, wird ein anderer Ordner genommen. Das macht bei der späteren Anwendung keinen Unterschied, kann aber zu mehr Übersicht in der Dateistruktur genutzt werden. Mit der Angabe von „.“ wird das Repository in das aktuelle Verzeichnis geklont. Das ist zwar ein seltener Anwendungsfall, spart einem aber bei Bedarf Zeit. Dafür muss der Ordner allerdings vollständig leer sein. Auch die Verzeichnisse der PHP-IDEs, wie PhpStorm, dürfen hier nicht vorhanden sein.

Branch erstellen

git checkout -b myNewTask
Mit dem Checkout-Befehl und dem Parameter -b wird ein neuer Branch „myNewTask“ erstellt und automatisch auf diesen gewechselt. Hier ist darauf zu achten, auf welchen Branch man sich zu dem Zeitpunkt der Erstellung befindet, und natürlich auch darauf, dass man den aktuellsten Stand auscheckt – also vorher ein „git pull“ ausgeführt hat.

Developing auf dem Branch

git add . && git commit -m “#myNewBranch add css file”
oder
git add layout/mynewtask.css && git commit -m “#myNewBranch add css file”

Generell soll ja bei jeder funktionierenden Änderung ein Commit gemacht werden. Hier ist Disziplin gefragt. Grafische Tools wie Sourcetree verleiten jedoch dazu, dies zu einem späteren Zeitpunkt zu machen. Hier kann man sehr einfach einzelne geänderte Zeilen separaten Commits zuweisen. Das bedeutet leider noch lange nicht, dass der Commit tatsächlich alles tut, was er soll, und wie gewünscht funktioniert hat.

Insofern ist es besser, regelmäßig kleine Commits zu machen. Der Git-Add-Befehl dient dabei einmal für das separate File und einmal für alles seit dem letzten Commit. Auch hier gilt: Regelmäßige und sinnvolle Commits machen einem das Leben leichter und sind effektiver. Vorher ist es zudem immer sinnvoll, sich die aktuellen Änderungen mit „git status“ noch einmal anzeigen zu lassen. Denn schließlich kommt es vor, dass man etwas übersehen hat. Das trifft auch auf von der Applikation generierte Files zu, die eventuell noch über .gitignore ausgeschlossen werden müssen.

Commit Messages

Damit man die Historie einer Entwicklung nachvollziehen kann, sind Commit Messages wichtig. Diese müssen aussagekräftig sein und beinhalten idealerweise eine Ticket-ID. Denn somit können die Arbeitsschritte direkt zugeordnet werden. Nicht aussagekräftige Commit Messages indes schaden dem Team und einem selbst.

Mit Pre Hooks ist es möglich, Commits ohne Ticket-ID direkt zu unterbinden. Das kann sogar erweitert werden, dass sich das Ticket im richtigen Status befinden muss. Solche Maßnahmen einzuführen und umzusetzen, ist allerdings nicht so einfach wie deren technische Implementierung.

Es gibt einige Spaßseiten zu dem Thema wie beispielsweise Commits from last night – dabei ist das Thema doch eigentlich sehr ernst. Denn es dient der Dokumentation der eigenen Arbeit und zeigt, dass du ein Profi bist. Soll heißen: Arbeite immer möglichst professionell. Das ist wichtig und richtig.

Git-flow installieren und sofort nutzen

git flow feature start myNewBranch
git flow feature finish myNewBranch

Git-flow hat sich in vielen Projekten bewährt und wird vor allem gerne bei neuen Projekten eingesetzt. Auf dem Mac ist es schnell mit Homebrew installiert, und nach einem „git flow init“ kann es nach einigen Bestätigungen der Default-Settings sofort eingesetzt werden. Mit dem oben aufgeführten Start-Befehl wird dabei ein neuer Branch aus dem aktuellen Develop Branch erstellt. Danach kann man sein Feature entwickeln und mit dem Finish-Befehl wieder abschließen. Hier wird ein Merge zurück in den Develop Branch ausgeführt und der Feature Branch sofort gelöscht. Falls man das aber nicht unbedingt möchte, geht es auch mit Hotfixes und Releases.

Eine gute Übersicht zu all dem bietet http://danielkummer.github.io/git-flow-cheatsheet/. Ausführliche Informationen zu Git-flow gibt es außerdem unter https://github.com/nvie/gitflow. Wir haben uns im praktischen Einsatz dazu entschlossen, nach dem Git-Flow-Workflow zu arbeiten, die zusammengeführten Branches allerdings zu archivieren und zu erhalten.

Git-Workflow nur auf der Command Line

Der Git-flow ist eine Zusammenfassung von Befehlen, die man selbstverständlich auch eigenhändig und einzeln ausführen kann. In meinen Augen ist aber ein großer Nachteil, dass Branches, die zurückgemerged wurden, auch gelöscht werden.

Persönlich finde ich es zudem besser, Bugfixes auf dem Feature Branch durchzuführen und sich öfter mit dem aktuellen Stand abzugleichen. So kann man die Arbeit auf einem Feature besser dokumentieren. Das Ganze geht manuell auf der Command Line – CLI – wie folgt:

// Aktuellen Develop Branch auschecken und aktualisieren
git checkout develop
git pull

// Feature Branch für Jira Ticket SUP-123 erstellen
git checkout -b feature/SUP-123

// Commits auf das Ticket
git status
git add . && git commit -m “#SUP-123 what i have done”

// Git Pushes sollten mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
git status
git push

// Feature Branch zurück in Develop bringen
git checkout develop
git pull
git merge feature/SUP-123
git status

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”
// Push mit Tags
git push && git push –tags

Die oben aufgeführten Commands in oh-my-zsh
// Aktuellen Develop Branch auschecken und aktualisieren
gco develop
gl

// Feature Branch für Jira Ticket SUP-123 erstellen
gcb feature/SUP-123

// Commits auf das Ticket
gst
gaa && gcmsg “#SUP-123 was ich gerade getan habe”
gst

// Git Push sollte mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
gst
gp

// Feature Branch zurück in Develop bringen
gco develop
gl
gm feature/SUP-123
gst

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”

// Push mit Tags
gp && gp –tags

Mit oh-my-zsh sind eine Vielzahl von Git Commands als Alias abgelegt. Im praktischen Einsatz kommen in meinen Augen die oben abgebildeten zum Tragen. Allein gaa && gcmsg „my message“ bringen einem sehr viel, da sie ein häufiger Anwendungsfall sind. Auch gc für git checkout geht schnell in Fleisch und Blut über.

Probleme mit Git

Git-Konflikte sind ein großes Thema bei Git und natürlich auch Themen wie Rebase. Aber in diesem Artikel gehe ich nicht zusätzlich auf diese Themen ein. In Zukunft werden wir hier in unserem Webdevelopment-Blog das Thema Git auch in anderen Zusammenhängen aufgreifen. Auch gehe ich nicht auf Tools, wie Tig ein. Aber natürlich ist es wichtig und richtig, mit visuellen Tools zu arbeiten.

Fazit zu Git auf der Command Line CLI

Git ist in der heutigen Zeit des Webdevelopments der Quasi-Standard. Jeder Entwickler, egal ob Frontend oder Backend, muss damit umgehen können. Man braucht und darf keine Ausreden bei der Nutzung einer Command Line haben. Nur so wird man zum Profi – sonst ist man nur ein Anwender. Ein User.

In diesem Artikel ist ein einfaches Beispiel über die Entwicklung eines Feature Branches abgebildet. Man sieht ganz deutlich, dass nur wenige Commands nötig sind. Es ist wichtig, diese einfachen Vorgänge zu 100 Prozent auf der Command Line durchführen zu können und dies auch regelmäßig zu tun. Nur so lernt man Git richtig.

Unsere Git-PHP-Schulung

Git wird von vielen Webdevelopern benutzt. Sie haben es aber leider häufig nicht verinnerlicht oder verstanden, warum man damit genau so arbeitet, wie man es tut. In unserer Schulung gehen wir ganz praktisch vor und erklären Git von den Grundlagen bis zu praktischen und etablierten Workflows. Wir gehen auf die Anwendungsfehler ein und geben unsere persönliche Erfahrung direkt an die Teilnehmer weiter. Es ist eine sehr individuelle Intensiv-Schulung. Alle Informationen zu dem Thema gibt es auf
http://www.entwicklungshilfe.nrw/seminare/git-flow-git-branching-model-fuer-agile-software-projekte/

Wie nutzt du Git bislang? Hast du es schon mal per Command Line versucht, und wie sind da ggf. deine Erfahrungswerte?

Der Beitrag Git auf der Command Line CLI einsetzen 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.

Legacy-Code-Probleme sind überall bekannt

„Nirgends werden tote Pferde so weit geritten wie in der Software-Entwicklung“ heißt es auf meiner Website. Nicht von ungefähr. Denn als Trainer und Dozent im Bereich der Software-Qualität kann ich infrage kommende Code-Stellen, die nach Robert C. Martin gerne als „Code smells“ bezeichnet werden, auch ohne die Unterstützung von Software sehr schnell ausfindig machen. Zudem sind sie unter Webdevelopern durchaus bekannt. Aber sie werden aus Zeitgründen umschifft.

Dabei ist Legacy Code längst kein Problem mehr, welches nur auf den Backend-PHP-Teil betrifft. Denn da heute Webapplikationen geschrieben werden, ist der Anteil von Javascript beträchtlich – und in den kommenden Jahren wird sich das noch weiter verschieben: API-Schnittstellen, Webservices und Microservices werden den Teil des Backends in der Applikation darstellen und unterschiedlichste Clients im Frontend die bereitgestellten Daten verarbeiten. Mit Technologien wie React und AngularJS zeichnet sich hier ein sehr klares Bild des zukünftigen Webdevelopments ab.

Legacy-Code-Nester in Webdevelopment-Projekten

Bei den Frontend-Teilen eines Webprojekts braucht man gar nicht lange zu suchen. Große Ansammlungen sind hier z. B. main.css, style.css und natürlich script.js und app.js. Das sind große und historisch gewachsene Files, die immer nur erweitert werden und selten ein Code-Refactoring gesehen haben. Auch im Bereich der Backend-Entwicklung wird trotz Software-Design und Patterns oft nicht sauber gearbeitet.

Eben dort ist PhpStorm eine große Hilfe: Code, der offensichtlich nicht verwendet wird, wird farbig ausgegraut und kann so recht zuverlässig entfernt werden. Aber auch hier ist große Vorsicht geboten: Ohne automatisierte Tests ist es nahezu unmöglich, effektiv zu arbeiten. Fakt aber ist, dass durch die gewachsene Komplexität und die schlechte Lesbarkeit viel Zeit und Motivation verloren gehen. Wenn man da überhaupt noch durchsteigt. Dann wird gerne kapituliert, was sogar bis zur Krankmeldung gehen kann. Hier Licht reinzubringen, ist, wenn man es nicht regelmäßig macht, ein immenser, unausweichlicher und stetig wachsender Kostenfaktor.

Legacy Code verursacht weitaus höhere Projektkosten

Webdevelopment-Projekte sind in einem schlechten Software-Zustand nicht mehr wartbar, zumal nach und nach immer mehr Bugs ans Tageslicht kommen. Das richtet großen Schaden in sämtlichen Bereichen einer Firma an und kann diese sogar in den Ruin treiben.

Auch Kunden ist das mittlerweile klar geworden: Rund 30 Prozent Mehrkosten sind als On-Top-Budget für Software-Qualität längst eine feste kalkulatorische Größe. Damit werden dann beispielsweise automatisierte Tests eingeführt, um den Entwicklungsprozess optimieren zu können.

Legacy Code verhindert die Weiterentwicklung der Berufssparte

Wenn die verfügbaren Ressourcen eines Webdevelopment-Teams völlig aufgebraucht werden, leiden darunter Weiterbildung und Motivation sowie die Bereitschaft, sich mit Herzblut in seine Arbeit einzubringen. Code wird dann sprichwörtlich hingerotzt. Dabei ist gerade bei der heutigen Programmierung ein enorm hohes und komplexes Wissen gefragt. Das kann nicht mal eben mit einer einzelnen PHP-Schulung abgebildet werden.

Zudem wird es Junior-Webdevelopern auf diese Weise nahezu unmöglich gemacht, sich in die vorhandenen Strukturen zu integrieren. Hinzu kommt die vertane Zeit. Denn sich mit Problemen aus einer „anderen technischen Epoche“ auseinandersetzen zu müssen, ist nicht zielführend. Innovationen und Sprünge in der Entwicklung sind so nicht machbar. Man steckt im Sumpf der Legacy-Projekte fest.

Refactoring ist der Anfang vom Ende des Legacy Codes

Software-Qualität entsteht durch Refactoring von Quellcode. Man spricht hier auch von „Aushärten“. In allen Arbeitsbereichen wird dabei noch einmal über die bestehende Arbeit geschaut, um diese zu korrigieren und zu verbessern. Sogar ein einfacher Blog-Artikel wie dieser hier bekommt dadurch mehr als zehn Revisionen.

Betrachtet man hingegen Code-Stellen, bleibt man im unteren einstelligen Bereich. Hier muss wesentlich mehr Zeit investiert und eingeplant werden. Dies ist dann zugleich eine Investition in das eigene Webdevelopment-Team. Denn warum sollte man sich schwieriger und langsamer in Projekten bewegen, bloß weil der Kunde an diesem Punkt keinen Bedarf sieht …? Schließlich geht es nicht zuletzt um die eigene Software-Qualität – und damit letztlich auch um Lebensqualität.

Wir können Software-Projekte nicht neu schreiben

Noch immer gibt es die Illusion, dass eine Website alle paar Jahre komplett neu gemacht werden muss. Selbst auf Internetseiten, die an Werbekampagnen gebunden sind, soll dies zutreffen. Doch in „Wegwerf-Seiten“ wurde in aller Regel keine aufwendige Business-Logik implementiert – wie etwa in Bereichen des E-Commerce. Insofern ist es purer Wahnsinn, zu denken, man könne mit den vorhandenen personellen Ressourcen parallel einfach mal eine neue Seite entwickeln. Das ist der falsche Weg.

„Same old thinking – same old result“ ist hier ein Problem an sich. Es verhindert, dass sich Entwickler mit neuem Wissen frisch ans Werk machen können, zumal dadurch alte Probleme am Ende nur neu verpackt werden. Zudem ergeben sich beträchtliche Spannungen, wenn ein Teil des Teams neue Software schreiben muss, während der andere Teil den bestehenden Teil weiterpflegt. So kommt nur unnötige Unruhe auf, die dem Teamgeist schadet und das Projekt behindert. Allerdings ist es ohne Weiteres möglich, bestimmte Routen eines Projekts neu zu erstellen und somit sukzessiv Teile zu erneuern. Zu diesem Thema beraten wir gerne.

Mit Pair Programming Probleme erkennen und lösen

Vor allem Refactoring im Team bietet eine hervorragende Möglichkeit, mit Pair-Programming anzufangen. Nutzt man diese Chance, so bildet man gleich auch das Webdevelopment-Team weiter und spart eine ganze Menge Zeit, die sonst für Absprachen und Konventionen nötig wäre. Gerade der „doppelte Blick“ ist ja der Schlüssel dafür, Probleme zu erkennen und aus einem anderen Blickwinkel betrachten zu können. Wir bieten Schulungen mit genau diesem Ziel an. Da der Start mit Pair Programming jedoch nicht immer ganz einfach ist, ist eine externe Meinung umso wichtiger, damit es hier nicht zum Kompetenzgerangel kommt.

Legacy Code und der innere Schweinehund

Sport ist gut für die Gesundheit, gesunde Ernährung ohnehin, und Bewegung tut ihr Übriges. Ein gesunder Körper kann am Ende immer auf einen gesunden Geist zählen. Und halten wir zur Genüge daran? Nein. Wir verfügen über einen regelrechten Ausreden-Katalog, der von täglichen Problemen bis hin zum Wetter immer eine passende Ausrede für uns parat hält. Und dabei ist es doch einfach nur eine Kopfsache.

So ist es auch in der Software-Entwicklung. Hier verhalten wir uns aus mehreren Gründen unvernünftig. Wobei oft gar nicht erst nach Gründen gesucht, sondern ebenso wie beim Thema Sport & Gesundheit bei jeder Gelegenheit der „Keine-Zeit-Joker“ ausgespielt wird. Einfach mal mit einem festen Termin über zwei Stunden in der Woche freitags ab 16 Uhr starten! Das kommt auch erstmal gut an. Aber hier sind Ausdauer und Disziplin gefragt!

Wenn der Budget-Plan keine Software-Qualität zulässt

Investitionen in die Software-Qualität und in das Personal sind dringend notwendig. Aber oft lässt der Budget-Plan dies nicht zu. Doch wie weit kommt man mit einem Auto mit brennender Motorleuchte, ohne einen Motorschaden zu riskieren …? Schlimmstenfalls bis zum Totalschaden. Gleichermaßen riskant ist ein solch „blindes“ Vorgehen in der Software-Entwicklung. Und noch einmal: Darunter leidet immer auch die Stimmung in der gesamten Firma.

In puncto Software-Qualität muss also die richtige Entscheidung getroffen werden! Es gilt, konsequent Ziele zu beschließen und zu erreichen. Der Prozess muss kontrolliert und überwacht werden.

Mit zu viel Legacy Code werden Entwickler verheizt

Als Webentwickler mit Berufserfahrung findet man derzeit in jeder Stadt Arbeitgeber und kann sofort eine Stelle besetzen. Die Stellen selbst sind dabei, auch wenn die Gehälter einander entsprechen, höchst unterschiedlich. Wird der Entwickler gefordert und gefördert – oder doch nur verheizt? Etwa durch zu viel Legacy Code. Letzteres findet man überall. Ersteres vielleicht in den vier großen Städten. Vor allem Berlin zeigt, wie es geht. Und gerade deshalb gibt es dort auch so tolle Erfolgsstories.

Der Ruf der Entwicklungsabteilung und der Software-Qualität im Unternehmen ist ein zunehmend wichtiges Entscheidungskriterium für die Karriere. Daher gilt auch hier: Ist der Ruf erst ruiniert … Treffen Unternehmen indes die richtigen Entscheidungen, so festigt man die bestehenden Strukturen und macht sich attraktiv für neue Bewerber.

Mein Fazit zum Thema Legacy Code

Legacy Code ist nach wie vor ein großes Problem, das sich nur mit Arbeit lösen lässt. Doch ist man diesen Weg einmal gegangen, dann lohnt er sich. Denn klar ist:

• Die Software-Qualität steigt.
• Die Kunden sind zufriedener.
• Die Abteilungen können effektiv arbeiten.
• Der Spaß kehrt zurück an den Arbeitsplatz.

So betrachtet ist die gezielte und intensive Beschäftigung mit Legacy Code ein notwendiges Übel. Denn niemand mag es, ständig aufzuräumen und Ordnung zu halten. Für Profis gehört aber genau das nun einmal dazu.

Welche Erfahrungen hast du mit Legacy Code gemacht? Du kannst gerne das Kommentarfeld unter diesem Beitrag nutzen, um deine Erfahrungen mit anderen zu teilen.

Der Beitrag Legacy Code – Entstehung, Ursache und Auswirkung erschien zuerst auf Entwicklungshilfe NRW.