You are here: Wiki>SE Web>ThesesHome>ThesisBuildsystemShopware (15 Oct 2019, matthaes)Edit

Ein Buildsystem für Shopware-basierte Shops

worked on by: Björn Matthäs

Outline

Diese Arbeit befasst sich mit der Erstellung einer Automatisierung des Buildprozesses für Shopware-basierte Shops auf Basis einer kontinuierlichen Integration und Deployment, um das Zusammenspiel von Shopware-Features zu testen und die Qualität der Programmierung zu erhöhen, als auch halbautomatisiert zu verteilen. Des Weiteren wird eine eigene Notation und Schnittstelle eingeführt um die Unabhängigkeit von Continuous Integration Server zu gewährleisten.

Ziel soll es sein, eine Automatisierung der Prozesse für das kontinuierliche Integrieren und Ausliefern (Deployment) von Onlineshopsystemen zu entwickeln, um das Zusammenspiel der einzelnen Features zu testen und die Qualität der Programmierung zu erhöhen. Darüber hinaus soll ein schnelles Deployment der Shopprojekte mit deren zum Teil unterschiedlichen Anforderungen erzielt werden. Es soll eine Möglichkeit gefunden werden, die eine Art Schablonensystem implementiert und die Projekte automatisiert auf Continuous Integration-Server (CI-Server) erstellt, baut und testet sowie anschließend auf einem Staging- / Testsystem ausliefert. Dies soll exemplarisch für einen Shopware-basierten Shop in die Continuous Integration (CI) - / Continuous Delivery (CD) - Pipeline mittels Containerisierung durchgeführt und getestet werden.

Problemstellung

Das Unternehmen "`Portaltech Reply"' hat sich auf den Bereich des E-Commerce spezialisiert und ist ein mittelständisches IT-Beratungsunternehmen. Hier werden für Kunden unter anderem Onlineshops erstellt oder Erweiterungen für bestehende Onlineshops umgesetzt. Es werden gleichzeitig viele unterschiedliche Shops auf Basis von Shopware in vielen kleinen Teams realisiert. Über das Kundenfeedback unterschiedlichster Projekte, sowohl bei Neuerstellungen von Onlineshops als auch bei System- und Featureupdates, kristallisierte sich heraus, dass Releases sich oft zeitlich verzögern. Häufig genannte Gründe sind die späte Integration aller Implementierungen oder auch notwendige Rollbacks der Releases nach Livestellung, da nicht alle möglichen Fehlerquellen während der Entwicklung erfasst und getestet wurden. Während der Entwicklung werden die Tests manuell ausgeführt, sowohl von Entwicklern, Projektmanager, als auch von Kunden. Meist werden diese gegen Ende der Projektphase ausgeführt. Dies bringt die Problematik mit sich, dass Fehler sehr spät oder gar nicht entdeckt werden und sich dadurch die Dauer des Projektes verlängert, was häufig in Nacht- und Wochenendeinsätzen endet. Darüber hinaus werden die Tests auf unterschiedlich konfigurierten System (lokal, interne Staging- / Testsysteme und für Kunden bereitgestellte Staging- / Testsysteme) ausgeführt. Ein daraus entstehende Schwierigkeit ist, dass Entwicklungen auf einem System funktionieren, jedoch nicht auf einem anderen, was die Fehlersuche schwierig und langwierig macht. Aufgrund zu erwartender Problemen nach Liveschaltung von Onlineshops und sich damit einhergehenden hohen Entwicklungskosten werden zudem selten Shopsystem- und Feature-Updates durchgeführt.

Thesis Requirements

(Wichtigkeit von oben nach unten - I = Pflicht, II = gehört dazu, III- weniger wichtig)

* Interview / Befragung der Entwickler, Projektmanager und Projektteams (I)

* Entwurf einer Schnittstelle / Notation für den CI-Server (I)

* Umsetzung der Schnittstelle (I)

* Bau eines Prototyps der Continuous Integration - / Continuous Delivery - Pipeline (I)

* Umsetzung einer automatisierten Benachrichtigung per E-Mail- / Messagingsystem als Feedbackmechanismus (I)

* Iteratives Anpassen / Verbessern und Testen der Pipeline in Zusammenarbeit mit den Entwicklern und Projektteams (I)

* Containerisieren der Kundenprojekte (II)

* (halb-)automatisiertes Deployment auf internen und Kundentest- und Staging-Systemen (III)

* Einführung der Automatisierung als soziotechnisches System in den Projektteams (III)

* Livegang von Realkunden mittels der Pipeline (III)

Milestones and Planning

Milestone no. Past daysSorted ascending CW Goals target accomplished wrench
1 DONE 1 CWXX Goals accomplished

...

Weekly Status

Week 1 (CW XX)

Activities

  • been there, done that
  • ...

Results

  • achieved XYZ

Next Steps

  • planning ...

Problems

  • ...
Topic revision: r1 - 15 Oct 2019, matthaes
 
  • Printable version of this topic (p) Printable version of this topic (p)