Tipps für die Entwicklung mit Magento: Teil 1

Das neue Jahr steht unmittelbar vor der Tür. Zeit, Vorsätze zu fassen. Für den Fall, dass sich jemand den Titel des Magento-Superentwicklers zum Ziel gesetzt hat, habe ich eine Liste mit Tipps für die Entwicklung mit Magento zusammengestellt. Quatsch, natürlich nicht deswegen, aber ich musste die Einleitung hinter mich bringen. 😉

Tatsächlich starte ich eine kleine Artikel-Serie zu diesem Thema. Mit der Liste könnt ihr bei eurer Lieblingssuchmaschine vorstellig werden, denn zu den meisten Tipps gibt es bereits viele Artikel und Postings im Web. Wenn ich hier alles detailliert beschreibe, wird der Text eindeutig zu lange und wer weiß, vielleicht gehe in zukünftigen Posts noch auf einige Punkte näher ein.

Ein Hinweis an alle, die nur kleine Anpassungen vornehmen wollen oder sich mit dem Thema erst zu beschäftigen beginnen: lasst euch nicht von den ersten zwei Tipps abschrecken und lest bei Tipp 3 weiter. 1 und 2 sind für fortgeschrittene Entwickler gedacht, aber sie sind mir so wichtig, dass ich sie nicht ans Ende stellen wollte. Früher oder später sollte man sich auf jeden Fall damit befassen.

[toc levels=3 title=“Inhalt“]

1. Versionierung verwenden

Verwendet unbedingt ein System zur Versionierung der Dateien. Bekannte und kostenlose Tools sind Subversion (kurz SVN) oder Git. Wer noch nie mit Versionskontrollsystemen (englisch abgekürzt VCS für Version Control System) gearbeitet hat, muss sich ein wenig in die Thematik einarbeiten. Gerade bei komplexen Systemen wie Magento ist die Investition aber Goldes wert. Der Wikipedia-Eintrag zu „Versionsverwaltung“ listet die Vorteile auf:

• Es wird möglich, die Änderungen zu verfolgen. Häufig muss man wissen, wer was wann wie modifiziert hat. Auch wenn man alleine arbeitet, bleiben drei „w“-Fragen, die es zu beantworten gilt.
• Wenn etwas schieft geht, kann man auf ältere Versionen zurückwechseln und Fehler leichter nachvollziehen.
• Somit verfügt man gleich über eine Archiv-Funktion. Ein VCS darf kein Ersatz für ein traditionelles Backupsystem sein, doch als Ergänzung dazu kann es die Arbeit stark beschleunigen, wenn auf Vergangenes zurück gegriffen werden muss.
• Mehrere Entwickler pfuschen sich gerne einmal ins Handwerk. Auch hier hilft das VCS, da jeder Programmierer für sich Änderungen vornehmen und ins System zurückführen kann. Konflikte zwischen Änderungen werden frühzeitig aufgedeckt und man weiß, wer was verbrochen hat. 😉
• Häufig wird an größeren Neuerungen gebastelt, die nicht ‚mal eben in einer Woche umzusetzen sind. Wenn Kunden dann Wünsche äußern, die sofort im Webshop erscheinen sollen oder gar Fehler im System auftreten, erweisen sich Entwicklungszweige als Lebensretter. Auf diese Weise kann man kurzfristig agieren, falls es nötig ist.

Kurzum: für seriöse Entwicklung kommt man um ein VCS nicht herum. Ich merke dazu an, dass nicht nur Entwickler, sondern auch Kunden diese Einsicht entwickeln müssen. Der Dienstleister muss als Experte in dieser Domäne dem Kunden darlegen, warum sich die Investition auszahlt, da sonst am falschen Ende gespart wird.

Neben den Code-Dateien können natürlich auch Shop-Daten, Datenbankschemen und andere Projektdokumente versioniert werden. Je nach Projektumfang ist das allerdings kein triviales Thema.

2. Niemals am Livesystem entwickeln

Über diesen Punkt brauchen wir eigentlich nicht lange diskutieren. Sobald Code angepasst werden muss und späestens wenn es um mehr als die private Tante-Emma-Website geht, ist von Änderungen direkt auf der Live-Website abzuraten. Wird nur z.B. das Design per CSS umzugestaltet, ist dies unter Umständen akzeptabel. Selbst da kann der Eingriff je nach Traffic-Aufkommen im Shop und der betroffenen Stelle aber zur Harakiri-Aktion werden, gerade weil bei Änderungen nicht immer abzusehen ist, welche Website-Teile noch betroffen sein könnten und wie verschiedene Browser darauf reagieren. Wenn auf einmal der „In den Warenkorb“-Button nicht mehr klickbar ist oder der Bezahlvorgang stockt, ist Schluss mit lustig. Von größeren Modifikationen der Programmlogik ganz zu sprechen.

Mein Rat daher: man sollte zumindest ein Entwicklungs– und ein Livesystem verwenden.  Häufig sind aber mehr Instanzen im Einsatz. Bei unseren Projekten bietet sich in der Regel ein Quartett aus Entwicklungs-, Integrationstest-, Staging-  und Livesystem an.

• Im Entwicklungssystem arbeiten wir als Shop-Anbieter,
• das Integrationstestsystem ist eine Testumgebung für andere Projektpartner wie z.B. die Warenwirtschaftsseite,
• das Stagingsystem simuliert das Livesystem möglichst originalgetreu und erlaubt den finalen Test von Änderungen sowie die Abnahme durch den Kunden und
• das Livesystem ist der Shop, den der Endkunde zu sehen bekommt und in dem er einkaufen kann.

Bei einer Aufteilung in mehrere Systeme muss man sich damit beschäftigen, wie man Änderungen vom Entwicklungssystem in andere Systeme übernimmt (Deployment) und wie man Änderungen gegebenfalls rückgängig macht (Rollback).

Das ist schon um einiges komplexer als die reine Versionierung, aber auch mit „kleinen“ Lösungen in Form von Linux-Shell-Skripten kommt man recht weit. Es ist damit zum Beispiel möglich, Änderungen des Entwicklungssystems im Versionskontrollsystem zu speichern, diese dann in den anderen Systemen nachzuziehen und – wo nötig – Dateien bzw. Daten zwischen den Systemen zu transferieren. Oft reicht das bereits.

Wer mehr Features, Kontrolle oder Systematik im Prozess benötigt, der kann auf Build-Systeme wie Phing oder Continuous-Integration-Systeme wie Jenkins zurückgreifen.

3. Niemals Core-Dateien verändern

Verändert niemals Magento-Core-Dateien. Nie!

1. Es ist nicht nötig.
2. Niemand dokumentiert alle Änderungen. Irgendwann weiß man nicht mehr, was original ist und was nicht. Wer ein Versionskontrollsystem verwendet (siehe Tipp 1), kann sich die Änderungen heraussuchen, aber ernsthaft: wozu?
3. Die Chance, dass „nur ‚mal schnell“ vorgenommene temporäre Änderungen dauerhaft werden, ist sehr hoch. Um schmutzige „Hacks“ später sauber auszuprogrammieren, ist später häufig keine Zeit oder kein Budget vorhanden.
4. Die Updatefähigkeit des Webshops geht verloren.

Wie man stattdessen vorgehen kann, verrät Tipp 4.

4. Änderungen updatefähig durchführen

Updatefähig heißt: man sollte möglichst wenig in das bestehende System eingreifen.

Wenn man mit den Klassen für Blöcke, Models oder Helper (den Dateien in app/code) arbeitet, kann man zwischen 4 Arten der Erweiterung unterscheiden.  Sie stellen, wie ich es nennen möchte, 4 Evolutionsstufen in der Vorgehensweise dar. Ich stelle die Reihenfolge auf den Kopf: hier ist die erste Methode die beste, die vierte die schlechteste. 😉

1. Eigene Frontend- und Backend-Models verwenden: Stufe 1 ist besonders elegant und updatesicher, die feine Klinge, ein minimialinvasiver Eingriff… Ihr wisst, was ich meine. An manchen Stellen, zum Beispiel bei Produkt- und Kategorieattributen, kann man angeben, welche Frontend- bzw. Backend-Models für die Attribute verwendet werden sollen. Um hier die Daten wie gewünscht zu speichern, zu laden und darzustellen, kann man Events vermeiden und stattdessen direkt eigene Models für die Attribute implementieren. Zum ersten Mal davon gelesen habe ich in der Präsentation von Vitaly Korotun, dem Technical Lead von Magento Professional Services.  Ich gebe zu, ich habe das selbst erst selten gemacht und bereits auf meinen Zettel mit den guten Vorsätzen fürs neue Jahr geschrieben.
2. Das Event-/Observer-Modell verwenden: Stufe 2 ist gut für Updates gerüstet und in vielen Fällen der beste Weg. Magento löst bereits an vielen Stellen im Code“Events“ aus. Dort kann man sich in das System einklinken, indem man einen „Observer“ programmiert, der den Code „beobachtet“ und aktiv wird, sobald die gewünschten Events ausgelöst werden. Im Magento-Wiki gibt es eine Einführung zur Event-Observer-Methode. Der Vorteil gegenüber Stufe 3 ist, dass sich bei Stufe 3 Extensions in die Quere kommen können. Dazu gleich mehr.
3. Klassen über die Konfiguration überschreiben: Stufe 3 geht in Ordnung und ist immer wieder nicht zu vermeiden, weil man an Orten im Code Anpassungen vornehmen muss, an dem keine Events vorhanden sind (oder die Events benötigte Information und Objekte nicht übergeben). Für Stufe 3 trägt man in der XML-Konfigurations-Datei der Erweiterung einen Rewrite ein und teilt Magento so mit, welche Core-Klasse (z.B. ein Block oder ein Model) durch welche selbstgeschriebene Klasse ersetzt wird. Einer von mehreren Einstiegslinks ist dieser Wiki-Eintrag.
   Wenn man mehrere Extensions im Einsatz hat und die Programmierer alle Rewrites verwenden, kann es passieren, dass die Erweiterungen dasselbe Model (z.B. Mage_Catalog_Model_Product) überschreiben und sich damit behindern.
4. Kopien der Core-Dateien in local anlegen: Methode 4 sollte man nur verwenden, um schnell etwas zu testen und sie dann gleich wieder aus dem Kopf verbannen. Angenommen, man möchte nur *wirklich* schnell etwas im Entwicklungssystem probieren oder der Fortbestand der Welt hängt davon ab, dass im Code *sofort* etwas geändert wird, dann kann man eine Kopie der originalen Datei im Ordner app/code/local ablegen. Das funktioniert sowohl für Dateien aus dem Verzeichnis app/code/core als auch für jene aus dem Ordner lib/. Vermeidet diese Methode, bei Updates könnt ihr auf gröbere Probleme stoßen.

Wenn Anpassungen in den Design-Dateien unter app/design oder skin/ gemacht werden müssen, kopiert man die benötigten Dateien vom Original-Verzeichnis in sein eigenes Theme-Verzeichnis.

Fazit Teil 1

Im ersten Posting haben wir vier wichtige Punkte für die professionelle Entwicklung mit Magento abgehandelt: man sollte

• sein Projekt in einem Versionskontrollsystem vorhalten,
• je nach Bedarf mehrere Entwicklungs- und Testsysteme für die Umsetzung von neuen Funktionen und Änderungen verwenden,
• niemals Magentos Core-Dateien verändern und
• auf die Updatefähigkeit des Shops achten.

Im nächsten Posting schreibe ich über die Trennung der drei Schichten Model, View und Controller in Magento und gebe ein paar Hinweise, wie man vorgeht.

Habt einen guten Start ins neue Jahr!