Best practices for Magento Deployment

Question

Ich bin auf der Suche nach der Einrichtung eines Bereitstellungsprozesses für eine stark angepasste Magento-Website und frage mich, wie andere Leute das machen.

Ich werde Dev-, UAT- und Prod-Umgebungen einrichten. Alle Magento-Dateien werden in der Quellkontrolle (SVN) sein. Zu diesem Zeitpunkt sehe ich keine Anforderungen für eine Änderung der DB, daher werden die 3 Datenbanken manuell gepflegt.

Konkret,

• Wie wenden Sie Magento-Upgrades an? (Individuell in jeder Umgebung, oder auf Dev und dann rollout, oder einfach auf Upgrades verzichten?)
• Welche Dateien/Ordner lassen Sie in jeder Umgebung unberührt (z. B. magento/app/etc/local.xml)
• Beschränken Sie Entwickler darauf, bestimmte Dateien/Ordner zu bearbeiten?
• Beschränken Sie Designer von Themes darauf, bestimmte Dateien/Ordner zu bearbeiten?
• Wie verwalten Sie Datenbankänderungen?

---

Dateien/Ordner des Designers des Themes

Designer können darauf beschränkt werden, die folgenden Ordner zu bearbeiten-

app/design/frontend/your_interface/your_theme/layout/
app/design/frontend/your_interface/your_theme/template/
app/design/frontend/your_interface/your_theme/locale/
skin/frontend/your_interface/your_theme/

---

Dateien/Ordner des Erweiterungsentwicklers

Erweiterungsentwickler können die folgenden Ordner/Dateien bearbeiten-

/app/code/local
/app/etc/modules/_.xml

---

Verwaltung der Datenbankumgebung

Da die Basis-URL des Stores in der Datenbank gespeichert ist, kann man die Datenbanken nicht einfach zwischen den Umgebungen kopieren. Optionen sind-

• Überschreiben der Basis-URL in PHP. Blogartikel zur Einrichtung von Dev- und Staging-Datenbanken
• Ändern der Basis-URL in der Datenbank nach dem Kopieren. (Wo ist das gespeichert?)
• Einen MySQLDump oder ein Backup machen und dann eine Ersetzung der URL in der SQL-Datei durchführen.

Answer 1

Ich empfehle die Verwendung von Git anstelle von SVN. Einfacheres Verzweigen und Zusammenführen bedeutet, dass all diese Punkte reibungsloser für Sie verlaufen werden.

Upgrades anwenden: Tun Sie dies in der Entwicklungsumgebung. Erstellen Sie einen Branch (hier glänzt Git wirklich), wenden Sie die Patchdateien an oder noch besser, entpacken Sie eine neue Magento-Version und verweisen Sie auf Ihre alte Datenbank. Noch keine Erweiterungen. Öffnen Sie das Admin-Panel in der neuen Magento-Installation und hoffen Sie auf das Beste. Ein Upgrade zwischen geringfügigen Versionen wird wahrscheinlich kein Problem darstellen. Sie müssen wahrscheinlich alle neuen Elemente indizieren, nachdem sie installiert wurden. Führen Sie einen Commit durch, sobald dies stabil ist, bringen Sie dann allmählich Ihre Erweiterungen und Themes in den Branch, nehmen Sie eventuelle Code-Anpassungen vor und führen Sie nach jedem Schritt einen Commit durch, der sich als stabil erweist.

Umgebungsabhängige Dateien: .htaccess und app/etc/local.xml. Ich erstelle für jede eine separate Version: local.dev.xml, htaccess-dev local.staging.xml, htaccess-staging local.production.xml, htaccess-production

... und dann erstellen Sie Softlinks zu jeder Umgebung:

ln -s htaccess-dev .htaccess 
cd app/etc/ ln -s local.dev.xml local.xml 

und so weiter.

Zugriff auf bestimmte Entwickler beschränken: Das mache ich nicht. Sie können jedoch eine Bereitstellungsstrategie in Git entwickeln, die einem Release-Manager ermöglicht zu entscheiden, was hinzugefügt wird und was nicht.

Verwaltung von Datenbankänderungen: Das ist der kniffligste Teil. Wir verwenden einfach mysqldump von der Produktionsumgebung und haben einige vorgefertigte "env-setup.sql"-Dateien für jede Umgebung. So etwas Ähnliches (Ihre IDs können variieren):

UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4);

Ich füge normalerweise weitere Anweisungen hinzu, die Zahlungsgateways in Testumgebungen umstellen, ausgehende E-Mails ändern usw. Die meisten davon finden Sie in core_config_data.

Denken Sie daran, dass Module in der Regel ihre eigenen Änderungen an der DB vornehmen, also sorgt das Anwenden eines gut gemachten Moduls normalerweise von selbst für die Anpassung. In jedem Fall sollten Sie niemals ungetestete Änderungen auf die Produktionsumgebung anwenden, sondern immer "Proben" auf lokalen und Staging-Umgebungen durchführen.

Sie können die CMS-Daten (Seiten und statische Blöcke) aus der Datenbank extrahieren, indem Sie nur die cms_*-Tabellen aus der Entwicklungsumgebung dumpen und laden.

Viel Glück!

Answer 2

Ich verwende die gleichen bewährten Verfahren wie bei jeder Web-App, während ich Magento entwickle. Ich vermeide auch religiös, Änderungen an den Kerndateien vorzunehmen (viele Dokumente im Magento-Wiki fordern Sie auf, Kerndateien zu ändern).

Answer 3

Ich benutze Git, um alle meine Magento-Projekte und -Bereitstellungen zu verwalten. Es ist viel einfacher, neue Versionen zusammenzuführen, besonders wenn Sie den Magento-Spiegel verwenden, den ich auf GitHub pflege. (GitHub Magento Mirror)

Was deine spezifische Frage betrifft, wo die Basis-URL in der Datenbank gespeichert ist, probiere dies aus:

SELECT * FROM core_config_data WHERE path = "web/secure/base_url" OR path = "web/unsecure/base_url";

Answer 4

Sie können die DB-Manipulation vermeiden (auf Deutsch): http://blog.tudock.de/startseite/beitrag/2010/09/17/deployment-prozess-eines-magento-shops.html

Answer 5

Nach vielen Versuchen und Fehlern haben wir einen Arbeitsablauf entwickelt, der uns gut passt:

http://www.dhmedia.com.au/blog/perfect-magento-workflow-using-git

Beinhaltet Datenbankverwaltung, alle Codes unter Versionskontrolle (mit Git), Bereitstellungen, Staging- und Entwicklungsumgebungen, mehrere Entwickler, mehrere Umgebungen usw...

Hoffentlich hilft dies jemandem!