Findologic-Shopware-Plugin: für den Enterprise-Einsatz neu aufgebaut
Das Findologic Search & Navigation-Plugin für Shopware 6 mit hoher Testabdeckung, GitHub Actions CI/CD und Multi-Versions-Support neu aufgebaut. Null Regressionen ausgeliefert.
Die Herausforderung
Ich habe das Findologic Search & Navigation-Plugin übernommen, als Shopware 6 noch im Release Candidate war. Das Plugin war vielversprechend, aber instabil: keine Tests, keine CI, ein Release-Prozess, der von manuellen Smoke-Checks abhing. Enterprise-Kunden sprangen erst auf, wenn sich das ändert.
Kritische Problempunkte
- Das Plugin musste die Shopware-6-RCs mitziehen, während die Plattform selbst noch in Bewegung war
- Es gab keine automatisierte Test-Infrastruktur und keine Release-Pipeline
- Enterprise-Kunden wollten Stabilität nachgewiesen sehen, bevor sie einsetzen
- Multi-Versions-Support über aktive Shopware-Releases hinweg war Pflicht
- Such- und Facettennavigationslogik war komplex genug, um echte Tests zu brauchen
Ohne Testabdeckung und echte Release-Pipeline war das Plugin immer eine Regression von einer Eskalation entfernt. Vertrauen baut sich einmal auf und ist an einem Nachmittag wieder weg.
Die Lösung
Ich habe das Plugin nach dem Prinzip "erst Tests, dann Automatisierung, dann Features" neu gebaut. Stabilität ging vor allem anderen.
95%+ Code-Abdeckung
Eine PHPUnit-Testsuite, die Kernflows, Randfälle und Integrationspunkte abdeckt. Coverage läuft bei jedem Commit.
GitHub Actions CI/CD
Tests laufen bei jedem Push. Releases taggen, bauen und veröffentlichen sich selbst. Der Release-Prozess wurde zu einem Häkchen.
Multi-Versions-Testmatrix
Die Pipeline läuft bei jeder Änderung gegen fünf Shopware-Versionen. Kompatibilitäts-Regressionen tauchen vor dem Merge auf, nicht nach dem Release.
Lesbare Dokumentation
Code und öffentliche APIs auf einem Stand dokumentiert, dass neue Entwickler einsteigen können, ohne den ursprünglichen Autor zu fragen.
Ergebnisse & Geschäftsauswirkungen
Null Produktionsbugs während des Rebuilds
Während der Rebuild-Phase blieben Kundenmeldungen über plugin-bedingte Regressionen bei null.
Shopware 6 RC bis 6.4 überstanden
Das Plugin zog die Shopware-Entwicklung mit, ohne Releases zu brechen. CI fing jeden Breaking Change ab, bevor Kunden ihn sahen.
Weniger Wartungsaufwand
Automatisierte Tests fangen Regressionen früh ab. Brandlöscharbeit ging zurück, Feature-Arbeit ging hoch.
Enterprise-Adoption
Große Shopware-Betreiber haben das Plugin eingesetzt, sobald die Test- und Release-Story belastbar war.
Verwendete Technologien
- Shopware 5
- Shopware 6
- PHP 8
- Symfony
- PHPUnit
- GitHub Actions
- CI/CD
- REST APIs
Plugin in Produktion ohne Tests?
Wenn ein Shopware-Plugin Ihr Produkt oder Ihre Abhängigkeit ist, ist ungetesteter Code ein Vorfall in Zeitlupe. Sprechen wir über Test-First-Plugin-Entwicklung.
Beratung buchenVerwandte Fallstudien
Multi-Plattform-Spenden-Plugin
Native Spenden-Plugins für Shopware 5, Shopware 6, Shopify und WordPress mit voller Feature-Parität. Für eine deutsche gemeinnützige Organisation, vier Plattformen.
Fallstudie lesen → Plugin-EntwicklungVariantenvorauswahl
Shopware 6-Plugin, das die beste verfügbare Variante über Listings, Suche, Herstellerseiten und PDP auflöst. Ein Service, keine N+1-Abfragen.
Fallstudie lesen → B2B-LösungenIndustrielle Ausschreibungsplattform
Shopware 6 B2B-Ausschreibungs-Plugin für einen DACH-Industriehändler. Mehrstufige Genehmigungen, Status-Workflows und Self-Service-Dashboard. Zykluszeit von 6 auf 3 Wochen reduziert.
Fallstudie lesen →