Release-Datum: Shopware 3.5.4 wird am 08.06.2011 gegen 15.00 Uhr bereitgestellt.

Zur Anleitung zum Update von 3.5.3 auf 3.5.4

Das Auto-Update Plugin wird in Kürze bereitgestellt

{trac method=ticketlist version=3.5.4 hide=reporter}

Komplette Übersicht

{trac method=chart graph=priority version=3.5.4 width=400 height=250}

Tickets nach Priorität

{trac method=chart graph=type version=3.5.4 width=400 height=250}

Tickets nach Typ

{trac method=chart graph=component version=3.5.4 width=600 height=400}

Tickets nach Komponente

3.5.4 wird ein Meilenstein in der Entwicklung von Shopware. Als Vorbereitung für das anstehende Code-Refactoring in Version 4 wurde ein Unit-Test Framework auf Basis von PHPUnit in das Produkt integriert. Dadurch können mittelfristig wesentlich kürzere Release-Zyklen ermöglicht werden und eine noch bessere Produkt-Qualität und Stabilität gewährleistet werden.

Durch die Implementierung eines Continuous Integration Servers kann die Entwicklung kontinuirlich am Produkt und der Roadmap arbeiten. Die Zeit zwischen der Meldung eines Bugs und der potentiellen Problemlösung, wird sich da durch noch weiter verkürzen.

Unser interner Bug-Tracker wird "Public", so dass man sich jederzeit einen Überblick über die Fortschritte eines beliebigen Releases verschaffen kann. Außerdem kann man so Feedback direkt an die Entwicklung geben und auch gefundene Bugs zentral reporten.

In Verknüpfung mit dem Continuous Integration Server sollen so auch Hotfixes für Major-Probleme schnell und unkompliziert bereitgestellt werden - und das in Release-Qualität.

Weiterhin wird es einen Public-Mirror unseres SVN gegeben. So können Entwicklungsversionen der Software frühzeitig evaluiert und getestet werden. Alle nicht kommerziellen Plugins, werden ebenfalls via SVN zur Verfügung gestellt.

Auch technisch wird sich einiges tun. In erster Linie ist die 3.5.4 als Bugfix-Release geplant. In zweiter Linie werden wir einige Änderungen und Neuerungen bereitstellen.

Weitere Details erhalten Sie unten, in der voraussichtlichen Roadmap.

Das Shopware Testing-Framework ermöglicht den automatisierten Test von allen Shopware Komponenten. Es stehen Sub-Frameworks für Controller, Models, Komponenten, Plugins und Core-Klassen zur Verfügung. Die Tests unterteilen sich im wesentlichen in folgende Kategorien:

• Unit-Tests

Testen der logischen Strukturen eines Objekts

• Regressions-Tests

Für jeden bekannten Fehler wird ein passender Regressionstest geschrieben. Das bedeutet das genau dieser Fehler zukünftig automatisch durch den CI-Server bei jedem Commit gegengeprüft wird. Ein einmalig aufgetretener Fehler wird es so mit hoher Wahrscheinlichkeit nicht erneut in ein Release schaffen.

• Integration-Tests

Hier geht es im wesentlichen um den Test der Systemstrukturen im Zusammmenspiel. Ein Controller-Test zum Beispiel hat ggf. diverse Abhängigkeiten. So müssen zum Beispiel ein Request-Objekt und ein Datenbank-Connector zur Verfügung stehen. Das Integration-Test Framework liefert im Prinzip eine vollwertige Shopware-Instanz, die die wesentlichen Abhängigkeiten zwischen den Komponeten auflöst.

• System / Selinium - Tests

Die System-Tests testen das Shop-System via Selenium in einer Browser-Session. So können komplexe Workflows automatisiert geprüft werden. Zum Beispiel der komplette Registrierungsvorgang oder die Warenkorb-Funktionalität.

Die Anzahl der Tests wird mit jedem neuen Release steigen, so dass eine immer höhere Code-Abdeckung gewährleistet wird. Sobald das Refactoring der Core-Funktionen für Shopware 4 beginnt, werden vorab Tests entwickelt, die die Konsistenz der API sicherstellen. Somit wird sichergestellt, dass die Methoden und Rückgabewerte zwischen den Versionen kompatibel bleiben.

Die Einführung des CI-Servers Jenkins ermöglicht uns mittelfristig eine deutlich höhere Entwicklungs-Performance. So können Fehler frühzeitig erkannt und behoben werden. Die Qualitätssicherung kann in weiten Teilen autonom und durch das Test-Framework auch automatisch erfolgen. Für behobene Major-Probleme können zukünftig Hotfixes bereitgestellt werden. Die Community kann deutlich stärker in die Entwicklung einbezogen werden, da Nightly-Builds und Vorab-Versionen mit wenig Aufwand bereitgestellt werden können.

Zwei weitere, wesentlich Änderungen betreffen die Code-Qualität als solches.

Ab sofort wird der Programmcode von Shopware durch eine Reihe von Tools auf die Qualität hin untersucht. So muss neuer oder geänderten Quellcode nun grundsätzlich dokumentiert in das SVN eingecheckt werden. Methoden und Klassen werden auf ihre Komplexität hin untersucht, so dass sich im Prinzip automatisch eine Liste von Kandidaten ergibt, die im Zuge des 4.0 Releases refaktoriert werden müssen. Auch generelle Coding-Standards wurden eingeführt - die Einhaltung dieser Konventionen wird mit PHP-Code-Sniffer sichergestellt.

Jenkins erzeugt bei jedem Nightly-Build automatisch Statistiken zur Code-Qualität und auch eine vollwertige Objekt-Dokumentation auf Basis von PHPDocumentor. Diese Ressourcen werden mittelfristig ebenfalls der Community zur Verfügung gestellt.

Die Community ist uns wichtig. So stellen wir in Kürze einen öffentlichen Bug- und Feature-Tracker bereit, so dass jeder nachvollziehen kann, welche Probleme ggf. bereits bekannt sind und welche Lösungen zur Verfügung stehen.

Die Community kann sich so noch aktiver in die Entwicklung integrieren. Es können Bug-Reports direkt an die Entwicklung durchgereicht - Feature-Requests aus der Roadmap werden ebenfalls automatisch in Tickets umgewandelt, so dass man leicht nachvollziehen kann, in welchem Release ein bestimmtes Feature voraussichtlich kommen wird.

Für "kritische" Probleme, werden in der Regel Hotfixes bereitgestellt, so dass diese kurzfristig gelöst werden können und man nicht auf das nächste Release warten muss.

Außerdem wird es Release-Statistiken geben. So sieht man sofort, an welchen Problemen die Entwicklung gerade arbeitet und wie die Releases voran schreiten.

Unser internes Repository erhält einen öffentlichen Mirror. So kann man bequem auf alle Shopware-Versionen zurück greifen, Änderungen im Code nachvollziehen und sogar auf aktuelle Entwicklungsversionen zugreifen.

Der Programmcode wird kommentierbar gestaltet, so dass Bugfixes und Optimierungsvorschläge direkt zwischen der Community und unseren Entwicklern ausgetauscht werden können.

Der neue Plugin-Manager wird folgende Änderungen beeinhalten:

• Verbesseres Fehler-Reporting
• Neue Konfigurationsfelder in der Plugin-Konfiguration
• Die Möglichkeit eigene Konfigurations-Controller in die Plugin-Stammdaten einzubinden
• Automatisches Update von Plugins
• (Ihre Version / Aktuelle Version [Upgrade])

Das Backend erhält einen Widget-Container. So können auf der Backend-Startseite via Plugin verschiedene Reporting-Tools implementiert werden.

Bislang müssen wesentliche Konfigurationsparameter in der Datenbank gespeichert werden. Mit 3.5.4 bieten wir eine Möglichkeit, die Datenbank-Konfiguration via Einträgen in der Application.php zu überschreiben. Das vereinfacht zum Beispiel die Synchronisierung zwischen Produktiv- und Test-Umgebungen, da hierzu keine Datenbank-Anpassungen mehr erforderlich sind.