SlideShare ist ein Scribd-Unternehmen logo
VitaminExpress
Learnings aus einem Magento-Enterprise-Projekt
2
Themen
 Projektübernahme
 Verwaltung der Aufgaben
 3rd-Party-Extensions
 Geotargeting
 Bestellungsabwicklung
 Backend-Anpassungen
 Dev / Live
 Monitoring
40.000+
Personentage
3
Online-Agentur LimeSoda
 Gründung 2002 in Wien
 25+ fix Angestellte
 5 Magento-EntwicklerInnen
 4 Magento Certified Developers
3
500+
Kunden
3.000+
Projekte
40.000+
Personentage
Der Kunde
VitaminExpress
5
VitaminExpress
 Seit 1990 im Geschäft
 Online & Katalog
 Nahrungsergänzungsmittel
 Mehr als 100.000 Kunden
 Mehr als 5 Millionen ausgelieferte Produkte
 Wechsel von Java-Lösung zu Magento
40.000+
Personentage
6
VitaminExpress
www.vitaminexpress.org
Projekt-Eckdaten
Fakten, Fakten, Fakten
8
Eckdaten
 > 3500 Stunden
 Bis zu 5 LS-Backend-Entwickler gleichzeitig
 Plus externe Firmen
 Anbindungen an Amazon, 4 PSPs, Fulfillment,
Newsletter-System, …
 143 Extensions (and counting)
 > 370.000 Zeilen PHP-Dateien in
app/code/local|community
 760 Datenbank-Tabellen
Projektübernahme
„Wir sind zu 90% fertig“
10
Projektübernahme
 Laufendes Entwicklungsprojekt übernommen
 Keine Dokumentation, keine Git-History
 Zugriff auf Teile des Issue-Trackers
 Was ist der Status quo?
1111© https://economicscenter.org/media/416211/businesswoman.jpg
12
Projekt-Übernahme
 „Never trust a foreign issue tracker“
 Projekt anhand klar abgrenzbarer Aufgaben
kennen lernen
 Entwicklungsstand Modul für Modul evaluieren
Verwaltung der Aufgaben
„Issues, Issues, Issues“
© http://www.wpcentral.com/sites/wpcentral.com/files/postimages/15741/devballmey.png
14
Issues, Issues, Issues
 Issue = Aufgabe / Feature / Bug
 Issues großzügig verwenden
 Priorisieren!
• vor dem Start
• nach dem Start
 Kunde mit Leserechten = ok
 Kunde mit Schreibrechten ≠ ok
3rd-Party-Extensions
„Der liebe Gott hat einen großen Tiergarten“
16
3rd-Party-Extensions
 Probleme:
 Sicherheitslücken
 Performance-Einbußen
 Missachtung von Best Practices
 Mangelnde/r Dokumentation/Support
 Viele Extensions entsprechen den Anforderungen
nicht zu 100%
 Abwägen, ob Extensions sinnvoll sind!
Installationsaufwand
Einarbeitungs- und Anpassungsaufwand
16
Geotargeting
„Wo bin ich?“
18
Geotargeting
 a.k.a. „GeoIP“
 Zuordnung der geographischen Herkunft
anhand der IP-Adresse
 Eigenes GeoIP-Modul (basiert auf MaxMind)
 Andere IPs testbar machen
 Caching anpassen!
19
20
Bestellungsabwicklung
„Don‘t mess with order statuses!“
22
Bestellungsabwicklung
40.000+
Personentage
23
Bestellungsabwicklung
 Automatisierte Verarbeitung von Orders
 Cronjobs
 Observer
 Cronjobs
 Lagerstand überprüfen
 Bestelldaten überprüfen
 PDF-Rechnung generieren
 Order für Fulfillment vorbereiten & exportieren
 Order-Stati & Tracking-Codes importieren
 Versand-Info, Capturing, Order abschließen, …
24https://github.com/AOEmedia/Aoe_Scheduler 24
25
Bestellungsabwicklung
 Murphy‘s Law #1:
 „Anything that can be allocated wrong – will be
allocated wrong“
Fallbeispiele überlegen
Anhand von Ablaufdiagrammen durchspielen
Worst case überlegen
Viel Zeit einplanen
26
Bestellungsabwicklung
 Murphy‘s Law #2:
 „Anything that can go wrong without a transaction –
will go wrong“
„Wir müssen aufpassen, dass nichts dazwischen
funkt!“ „Nein!“ „Doch!“ „Oh!“
Race conditions!
Transaktionen:
$transaction = Mage::getModel('core/resource_transaction');
$transaction->addObject($invoice);
$transaction->addObject($invoice->getOrder());
$transaction->save();
27
Bestellungsabwicklung
 Abläufe und Überlegung dahinter dokumentieren
Externe Dokumente vermeiden
Direkt im Backend erläutern
 Nach Vereinfachungsmöglichkeiten suchen
Fühlt es sich falsch an, dann ist es meistens auch
falsch
28
Bestellungsabwicklung
 „Don‘t mess with order states (and statuses)“
 Magento-Standard-States verwenden
 Externe Systeme ignorieren die eigene
Geschäftslogik
Asynchrone Bestellstatusaktualisierungen
Lösung:
 3rd-Party-Extensions überschreiben oder
 Bestellungen regelmäßig auf fehlgeleitete Stati überprüfen
Wir überprüfen die Bestellungen im Rahmen der
Order-Flow-Cronjobs
29
Backend-Anpassungen
Optimierungen in Callcenter-Prozessen
31
Backend-Anpassungen
 Backend-Grids
 Spalten hinzufügen / umsortieren / entfernen
 Adressdaten von anderen Tabellen beziehen
 Einträge hervorheben
32
Backend-Anpassungen
 Callcenter-Funktionalität
 Store-Auswahl überspringen
 Letzte Bestellungen anzeigen
 Liste der bestellbaren Produkte anpassen
 Zusätzliche Kunden- und Produkt-Informationen
 Link zum Kundenkonto hinzufügen
 Reduzierung der AJAX-Loads bei Adressdaten
33
Backend-Anpassungen
 Backend Grids in der Enterprise Edition
 Achtung bei zusätzlichen Joins:
SQL-Errors für eingeschränkte User
„ambiguous column names“ beseitigen
 Grids allgemein
 Performance-Verluste beim Joinen von Tabellen
 Views helfen nur, wenn sich Daten selten ändern
Werte vorberechnen
Grid-Tabellen erweitern oder eigene Grid-Tabellen
entwerfen => automatische Propagation erweitern!
34
Backend-Anpassungen
 Create New Order
Anpassungen sind mühsam:
 AJAX-Calls
 Nachladen von Blöcken
 Abhängigkeiten / Verbindungen zwischen Blöcken
 Wenig Events
Dev / Live
Handling unterschiedlicher Umgebungen
36
Dev / Live
 Mehrstufiger Prozess
 Entwicklung (Dev)
 Staging / Testing
 Live
 Bis zu 9 Umgebungen gleichzeitig
37
Dev / Live
 Git-Workflow
 master-Zweig immer deployfähig halten
 Feature-Branches, Stashing, Remote-Branches…
 Deployment
 Selbstverantwortlich
 Häufig
 Schnell
 Software für Build & Deployment:
phing
38
Dev / Live
 Aktuelle Files und Daten
Files aktualisieren:
Git & ugitsub & rsync
Datenbank rückportieren:
backportlive
Daten und Umgebungskonfiguration anpassen:
LimeSoda_EnvironmentConfiguration @ GitHub
3939
40
Dev / Live
 Pro Umgebung zu berücksichtigen
 Automatismen abstellen?
 Importe / Exporte deaktivieren?
 Cronjobs deaktivieren?
 Andere externe Systeme verwenden?
 Häufig keine vollfunktionalen Testsysteme vorhanden
 Testsysteme verhalten sich häufig anders als Livesysteme
 Manchmal gar keine Testsysteme
(I‘m looking at you, Amazon)
 Echtdaten anonymisieren/entfernen?
41
Dev / Live
 Live-Systeme schützen
Extension:
LimeSoda_LiveGuard @ GitHub
Ergänzt LimeSoda_EnvironmentConfiguration
Überwacht jeden Magento-Aufruf
„Defensive“ Taktik
Plugin-Architektur
Testen auf
Konfigurationswerte
E-Mail-Adressen
FTP-/SSH-/REST-/SOAP-Verbindungsdaten
Monitoring
Überwachung der Systeme
43
Monitoring
 Aktive Überwachung von
 Server-Auslastung & HDD-Speicher
 Logs, Exceptions und Logs (Tabellen und Files)
 Session-Files
 Website-Erreichbarkeit
 Ausführung von Cronjobs
 …
44
Monitoring
 Tools
Icinga
pnp4nagios
n98-magerun
Shell-Skripte
 Vielen Dank!
46
Kontakt
LimeSoda Interactive Marketing GmbH
Syringgasse 5, 1170 Wien, Austria
office@limesoda.com
www.limesoda.com

Weitere ähnliche Inhalte

PPTX
Presentation metal work2003
PPTX
Präsentation1
PDF
Werkzeug und Kunstwerk der Meistererzählers - Anton Tschechow und die Russisc...
PPTX
#mmd15 - Christian Daubner, BR24
PPTX
Human Behaviour
PDF
Pemerintah kab. soppeng
PPT
PDF
Brochure Armonia 2010 - Du Lac et Du Parc Grand Resort Riva del
Presentation metal work2003
Präsentation1
Werkzeug und Kunstwerk der Meistererzählers - Anton Tschechow und die Russisc...
#mmd15 - Christian Daubner, BR24
Human Behaviour
Pemerintah kab. soppeng
Brochure Armonia 2010 - Du Lac et Du Parc Grand Resort Riva del

Andere mochten auch (14)

PDF
Pemerintah kabupaten kepulauan selayar
PPT
Ansgar Mayer
PDF
Via 06 2013 ursula meier
PDF
SEM & Recht - Die neuesten Rechtstipps zum Suchmaschinenmarketing
PDF
Pemerintah kab. wajo
PDF
Rensing - Adaptivität von mobilen Lernanwendungen
PDF
Social Media in der Touristik: Facebook, Twitter & Co |
PDF
Google+: Seien Sie da, wo die Kunden Sie suchen!
PDF
Calidad total
PDF
Wien - live-liveonline
PPTX
Transforming Media 2015 - Mut zum Neustart: Wie sich das Wissenschaftsmagazin...
PPTX
Präsentation radio in
PDF
Was geschieht eigentlich beim Austausch einer defekten Laptop-Netzbuchse?
Pemerintah kabupaten kepulauan selayar
Ansgar Mayer
Via 06 2013 ursula meier
SEM & Recht - Die neuesten Rechtstipps zum Suchmaschinenmarketing
Pemerintah kab. wajo
Rensing - Adaptivität von mobilen Lernanwendungen
Social Media in der Touristik: Facebook, Twitter & Co |
Google+: Seien Sie da, wo die Kunden Sie suchen!
Calidad total
Wien - live-liveonline
Transforming Media 2015 - Mut zum Neustart: Wie sich das Wissenschaftsmagazin...
Präsentation radio in
Was geschieht eigentlich beim Austausch einer defekten Laptop-Netzbuchse?
Anzeige

Ähnlich wie Learnings aus einem Magento-Enterprise-Projekt (20)

PDF
High Performance Multi-Server Magento in der Cloud
PPTX
Pimp My SharePoint - Performanceprobleme vorbeugen, analysieren und beheben
PDF
DACHNUG50 panagenda BigFix Notes Domino.pdf
PDF
Mehr Sicherheit durch Automatisierung
PPTX
BizSpark goes Cloud
PDF
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
PPTX
REST: Versprechen, Wirklichkeit & Alternativen: GraphQL, GRPC, JSON RPC...
PPTX
ShareConf 2014: 10 Gründe warum der SharePoint langsam ist
PDF
GWT – Google Web Toolkit in der Praxis
PPTX
Avoid Network-Issues and Polling
PDF
Meet Magento - High performance magento
PDF
Make Developers Fly: Principles for Platform Engineering
PPTX
TDD für Testmuffel
PDF
Domino 12(.0.2) Lessons learned - DNUG Stammtisch Hamburg
PDF
IBM Connections Troubleshooting oder "get the cow off the ice"
PDF
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
PDF
XPages: Performance-Optimierung - Ulrich Krause (eknori) SNoUG 2013
PPTX
REST Problems
PDF
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
PPT
High Performance Multi-Server Magento in der Cloud
Pimp My SharePoint - Performanceprobleme vorbeugen, analysieren und beheben
DACHNUG50 panagenda BigFix Notes Domino.pdf
Mehr Sicherheit durch Automatisierung
BizSpark goes Cloud
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
REST: Versprechen, Wirklichkeit & Alternativen: GraphQL, GRPC, JSON RPC...
ShareConf 2014: 10 Gründe warum der SharePoint langsam ist
GWT – Google Web Toolkit in der Praxis
Avoid Network-Issues and Polling
Meet Magento - High performance magento
Make Developers Fly: Principles for Platform Engineering
TDD für Testmuffel
Domino 12(.0.2) Lessons learned - DNUG Stammtisch Hamburg
IBM Connections Troubleshooting oder "get the cow off the ice"
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
XPages: Performance-Optimierung - Ulrich Krause (eknori) SNoUG 2013
REST Problems
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
Anzeige

Learnings aus einem Magento-Enterprise-Projekt

Hinweis der Redaktion

  • #9: PSPs: Acceptance, Sofortüberweisung, Billsafe, PayPal Datenbank: EE Standard 447, M2E Pro 179, Sonstige 134
  • #13: Zustand des externen Issue Trackers: veraltete Information, nicht hilfreich => zu viel implizites Wissen - Es war sinnlos, zuerst den kompletten Status quo zu erheben - Arbeitspakete zusammenstellen: Anhand klarer Aufgaben kann man arbeiten, sich im System orientieren lernen
  • #15: Issues großzügig verwenden: lieber zu viele Issues als zu wenige verwenden Viele Aufgaben, wenig Zeit => wir mussten priorisieren! Aufteilung in 2 Phasen: => bietet mehr Flexibilität => bei harter Deadline: Weniger wichtige Issues auf nach dem Start verlagern oder simplere Lösung finden
  • #17: Man sollte vor Einsatz Code-Checks machen! (Fabian: 2 PT Aufwand für Check) Sicherheitslücken: SQL-Injection, Textfile mit letzter Transaktion im Root-Verzeichnis Performance: Cross-Selling-Extension: Produktseite: +2,5 Sekunden, + 600 Queries Missachtung von Best Practices: Haarsträubender Code: Original-Dateien überschrieben, unnötige Rewrites, vorhandener Code nach programmiert, Model/View/Controller vermischt, … Kunden glauben es meistens nicht, und doch ist es so: gekaufte Extensions verursachen ebenfalls Kosten, manchmal mehr als eine Eigenprogrammierung (plus: Aufwände bei Upgrades)
  • #19: Caching: Cache-Keys für Blöcke anpassen, die GeoIP berücksichtigen!
  • #23: Order wird erstellt => nach Bezahlung im Status Processing. Lagerstand wird reduziert und wir merken uns, wieviele Stück reserviert sind. Wir benötigen den allokierten Lagerstand, um aufgrund des Versandlager-Lagerbestands die tatsächlich im Shop verfügbare Menge zu berechnen.
  • #24: Cronjobs (für regelmäßige Abläufe, die man planen kann) Observer (schießen irgendwann dazwischen): Wareneingänge, Stornierungen / Refundierungen, …
  • #25: Lücken: entstehen durch lang laufenden Cronjobs. Sind inzwischen in extra Prozesse ausgelagert. Außerdem haben wir nun auch häufiger laufende Cronjobs. Außerdem indiziert die EE laufend.
  • #26: „Lagerstandsverwaltung = komplexes Thema“ Fallbeispiele erstellen: komplexe Fälle durchüberlegen Worst case besprechen: was passiert, wenn XY schief geht? => ist wichtig, denn irgendwann wird es schief gehen! Vorbereitung wichtig: wenn es schief geht, hat man nicht die Zeit dafür.
  • #27: Wir: „Was passiert, wenn gerade die Aktion X ausgeführt wird und mittendrin Aktion Y passiert? Kunde: „Das wird in der Praxis nicht passieren!“ => Lücke von max. 0,1 Sekunde bei Order-Speichern und Verarbeiten => Bis zum nächsten Abend hatten wir den ersten Fall.
  • #28: Externe Dokumente sind schnell outdated Direkt im Backend = man erfasst schneller, worum es geht. Hinweis auf Issues sind möglich Vereinfachungen suchen: „Manchmal sieht man den Wald vor lauter Bäumen nicht“. Wenn es sich falsch anfühlt, ist es meistens auch falsch. Zuerst hatten wir 4 variable Lagerstände: Versandlager Lagerstand Reservierter Lagerstand Freier Lagerstand Magento-Lagerstand Reduzierung auf: Extern definierten und berechneten Versandlager-Lagerstand Reservierter Lagerstand (variabel) Magento-Lagerstand (berechnet sich aus Versandlager - reserviert)
  • #29: Don‘t mess: Keine eigenen States Eigene Statuses gefahrloser, aber potentiell problematisch mit externen Systemen - Externe Schnittstellen und deren Extensions scheren sich normalerweise nicht darum, welchen Status eine Extension gerade hat und ob der neue Status Sinn macht   => Entweder alle Extensions überschreiben oder Orders regelmäßig überprüfen => Entscheidung für Cronjob, siehe Order-Stop-Rules und Order-Status-Flow
  • #32: Wir gehen nur auf die Anpassungen rund um die Sales- und Customer-Menüs ein Adressdaten von woanders beziehen
  • #34: Auto-Propagation: Herausforderung, eigene Daten in Grids aktuell zu halten => man muss die Auto-Propagation erweitern, damit diese Daten !
  • #35: AJAX-Calls schießen kreuz und quer Blöcke werden kreuz und quer nachgeladen Es gibt Verknüpfungen zwischen Blöcken Es gibt keine anständigen Events / Rewrites
  • #38: Deployfähig = „funktionsfähiger und stabiler Code, der ohne wenn und aber ins Live-System darf“
  • #39: Files und Daten in den Entwicklungskopien müssen aktuell gehalten werden ugitsub: Bash-Script, das alle Submodule aktualisiert backportlive: Shell-Skript: Umgebung und Backup angeben: holt sich eines der nächtlichen Backups vom Live-Server, spielt sie ein, passt die Konfiguration etc. der Datenbank an. LimeSoda_EnvironmentConfiguration: Hilft, die Umgebung vorzubereiten (Beispiele folgen gleich)
  • #40: Variablen und Befehle Beliebig viele Vererbungen
  • #42: Daraus ergibt sich im Gegenzug eine weitere Anforderung: Live-Systeme müssen geschützt werden