Projektstrukturen @ Vereinheitlichung und Vereinfachung Fabian Schmengler Magento Stammtisch Aachen/Niederrhein 22.06.2015 #mageburgers 

Gemeinsame Strukturen ● Warum? – Leichteres Wechseln zwischen Projekten – Nicht nur jeweils einer findet sich zurecht – Einfachere Wiederverwendung von Tools ● Was? – Verzeichnisstruktur, Namenskonventionen – Nutzung von Tools: Composer, Modman, … 

Agenda 1. Ziele 2. Werkzeuge 3. Verzeichnisstruktur 4. Deployments 

Ziele (1) • Deployment mit Build Server möglich - Aber nicht notwendig (Alternativ: Git) - Keine externen Abhängigkeiten • Ohne Umstände lauffähig auf - Windows - Mac - Linux VM (Vagrant) • Prozesse für Frontend-Entwicklung berücksichtigt • Einfache Transition von bestehenden Projekten 

Ziele (2) ● Module und Core separieren ● Einfaches Wechseln zwischen Branches ● Notwendigkeit von zusätzlichen Tools bei der Entwicklung minimieren ● Kleine Änderungen durch Nicht-Entwickler ermöglichen: z.B. Modul installieren, Übersetzungen anpassen ● KISS 

Composer + Modman www composer install .modman ● composer_{$vendor}_{$name} ● {$project}_{$name} ● {$vendor}_{$name} composer install symlinks Github packages.firegento.com integer_net/magento modman deploy-all (modman.php) 

Composer Installers • Aoe Composer Installers • Legt fest, wo Magento und Module installiert werden • mehr nicht! • http://fbrnc.net/blog/2014/11/how-to-install-a-magento-module • IntegerNet Magento Scripts • package.xml => modman Konvertierer • modman.php (Fork von sitewards/modman-php) • https://bitbucket.org/integer_net/magento-scripts 

Composer Installers composer.json { "require": { "aoepeople/composer-installers": "dev-master", "integernet/magento-scripts": "dev-development", }, "extra":{ "installer-paths": { "www/" : [ "type:magento-source" ], "src/composer_{$vendor}_{$name}/" : [ "type:magento-module" ] } }, "scripts":{ "post-install-cmd": [ "IntegerNet\\MagentoScripts\\ComposerScripts::copyScriptsToBin", "IntegerNet\\MagentoScripts\\ComposerScripts::convertPackageXmlToModman", "php bin/modman.php deploy-all --force" ], "post-update-cmd": [ "IntegerNet\\MagentoScripts\\ComposerScripts::copyScriptsToBin", "IntegerNet\\MagentoScripts\\ComposerScripts::convertPackageXmlToModman", "php bin/modman.php deploy-all --force" ] } } Installationsziel Magento Connect Module Symlinks setzen 

Composer Verwendung ● composer install [--dev|--no-dev] – Bei Einrichtung einer neuen Instanz – Nach Update von Magento – Nach Update von Dev Dependencies ● composer update {$vendor}/{$name} – Zum Update des angegebenen Moduls – Zur Installation des angegebenen Moduls ● composer update ohne Parameter nur als separater Commit – Wichtig: Versionen in composer.json möglichst so angeben, dass nur Bugfix-Updates automatisch geschehen (z.B. “~1.1.3”). Bei Packages ohne Semantic Versioning konkreten Tag oder Commit angeben. Niemals “dev-master” oder “*”! https://getcomposer.org/doc/01-basic-usage.md#package-versions 

Modman Verwendung ● modman deploy-all --force - Automatisch nach composer update - Automatisch auf Server beim Deployment - Build Server - Git Hook - Optional automatisch mit PhpStorm File Watcher, oder Grunt Watcher ● modman deploy {$module-directory} - Manuell lokal nach Änderung von modman Datei, wenn Effekt sichtbar sein soll (“deploy-all” hat unübersichtliche Ausgabe) 

LimeSoda_EnvironmentConfiguration ● Umgebungspezifische Konfiguration in config.xml – z.B. Base URL, Google Analytics, Sandbox Mode ● Nutzt n98-magerun – n98-magerun ls:env:configure dev – Magerun Commands zur Konfiguration ● Environment Indicator im Backend ● https://github.com/LimeSoda/LimeSoda_EnvironmentConfiguration app/etc/local.xml 

LimeSoda_EnvironmentConfiguration config.xml 

Verzeichnisstruktur ● Verzeichnisse – src Alle(!) Magento-Module – bin Skripte – etc Reserviert für Konfigurationsdateien, die nicht ins Hauptverzeichnis müssen – doc Reserviert für Dokumentation und Sonstiges – .modman Link auf src – shared media und var Verzeichnisse, local.xml – www Magento Core + Symlinks – vendor 3rd Party Packages (außer Magento Module) – var Lokale/temporäre Dateien ● Dateien – composer.json – composer.lock – README.md }.gitignore 

src ● Alle Magento-Module auf einen Blick ● Composer installiert direkt dorthin ● Composer Module sind im Projekt-Repository versioniert ● Kein „modman link“ notwendig, nur „modman deploy-all“ ● package.xml von Magento Connect Modulen kann in modman Datei konvertiert werden ● Für Kaufmodule ohne modman-Datei wird sie selbst geschrieben src bin etc doc .modman shared www vendor var Symlink 

www ● Document Root für Webserver ● Magento Core + Symlinks ● Magento Core wird mit Composer hierher kopiert. ● Nicht versioniert (wegen Symlinks) ● Angepasste Dateien wie index.php, favicon.ico in Modulen pflegen und ebenfalls symlinken src bin etc doc .modman shared www vendor var 

shared ● Trennung von Daten und Source ● Wichtig für Deployment mit Build Server ● Wichtig, damit composer install das bestehende Media Verzeichnis nicht überschreibt ● Liegt idealerweise ganz außerhalb des Repositories ● Symlinks auf Server: – shared/media => [release/current/]www/media – shared/local.xml => [release/current/]www/app/etc/local.xml – shared/var => [release/current/]www/var – Ggf. weitere Verzeichnisse z.B. für import/export src bin etc doc .modman shared www vendor var 

bin ● Dev Tools: composer.phar, n98-magerun.phar, modman.php ... ● Deploy Scripts: shared-links.php, build-artifact.sh, deploy-artifact.sh ... ● Alle nicht projektspezifischen Skripte (außer composer.phar) in eigenem Repository verwalten und über Composer hier hinzufügen – Keine Symlinks, soll mit versioniert werden! ● WIP: https://bitbucket.org/integer_net/magento-scripts src bin etc doc .modman shared www vendor var 

vendor ● Composer Packages (außer Magento-Module) ● Sollten nur bei der Entwicklung benötigt werden (Composer Installer, PHPUnit, ...) etc ● Konfiguration anderer Tools, z.B.: – Frontend Boilerplate (grunt, bower) – Vagrant – Code Analyse (phpcs, phpcpd, …) src bin etc doc .modman shared www vendor var src bin etc doc .modman shared www vendor var 

var • Datenbank Dumps • Heruntergeladene Extensions • Import-Daten doc ● Reserviert für Dokumentation ● (noch) nicht standardisiert src bin etc doc .modman shared www vendor var src bin etc doc .modman shared www vendor var 

Deployments - Variante 1: Git - schnell, wenig Einrichtungsaufwand - für kleine Projekte, Projekte mit sehr häufigen Änderungen und Testsysteme für Feature Branches - Git Hook startet modman & Environment Configurator - .git/hooks/post-merge - .git/hooks/post-checkout Bitbucket Server git pull git fetch && \ git checkout feature/to-test 

Deployments - Variante 2: Jenkins - zuverlässig, wiederholbar - für große Projekte und Projekte mit hoher Verfügbarkeit build: run composer+modman create artifacts check: run static code analysis install: install dev artifacts on CI run env. configurator run integration tests deploy-staging: deploy prod artifacts run env. configurator deploy-live: deploy prod artifacts run env. configurator Bitbucket git pull Artifacts: www.tar.gz www-dev.tar.gz bin.tar.gz 

Sonderfälle ● Composer: Handhabung von Magento Modulen in „require-dev“ – Dev Module sind im Repository – auf staging/live: composer install --no-dev entfernt dev Module ● Umstellung von Projekten ohne modman Original-Repository als Magento Core Repository verwenden nach und nach migrieren. ● Abhängigkeit von externen Libraries in Magento vendor wird eigentlich nicht versioniert und nicht deployed Ausnahmen in vendor/.gitignore und Deploy-Skripts auf Build Server pflegen 

Themen für’s nächste Mal? • Frontend mit integernet/boilerplate • Vagrant • Jenkins Build Pipeline 

Kontakt Web: www.schmengler-se.de / www.integer-net.de Twitter: @fschmengler / @integer_net Email: [email protected]