Hallo Shopware-Community,
wir haben in den letzten Monaten mehrere Shopware-Systeme deployt und sind dabei unseren Deployment-Prozess zu optimieren.
Mit dem vorgeschlagenen Weg geänderte Dateien einfach via FTP hochzuladen sind wir nicht wirklich zufrieden
(http://community.shopware.com/Shop-Transfer-Live-System-Testumgebung_detail_1309.html#Kopieren_der_Testumgebung_in_das_Live-System).
Bisher machen wir es aber tatsächlich so, dass wir die Source-Files in den Webroot des Live-Servers laden und anschließend Symlinks zu Ordnern und Dateien setzen, die aus dem CVS kommen. Insbesondere ist das bei eigenentwickelten Plugins und Kundentemplates der Fall aber auch bei der config.php und der .htaccess.
- XyzPlugin -> …/…/…/…/…/…/…/shopware-assets/engine/Shopware/Plugins/Local/Frontend/XyzPlugin
- CustomTemplate -> …/…/…/…/shopware-assets/themes/Frontend/CustomTemplate
Beim Go-Live stellen wir nach intensivem testen unter einer Subdomain die Hauptdomain um und passen die URL in der s_core_shops an.
Unsere Fragen zu den Shopware Deployment Best Practices via VCS sind folgende:
1.) Empfiehlt es sich die Shopware-Sources in zentralem Ordner außerhalb der Webroot abzulegen und diese zu symlinken? Wenn ja, welche Ordner sollten wie verlinkt werden? Wie sollten Symlinks zu (eigenentwickelten) Plugins und Templates gesetzt werden, ohne dass es hier zu Überschneidungen mit den Shopware-Sources kommt?
2.) Wäre dann ein Source-Update über einfaches Umstellen des Symlinks möglich? Oder müssen tatsächlich alle Shopware-Dateien im Webroot liegen?
3.) Ist ein Source-Update ohne Wartungsseite und ohne Ausfallzeiten möglich? Wenn ja, wie kann es (für eine Professional Editon mit nur einer Lizenz) realisiert werden?
Vielen Dank für eure Anregungen!
Mit den besten Grüßen
Andreas
Warum so umständlich?
Dafür gibt es Git.
Bzgl. Punkt 3) Zero Downtine Deployment wäre hier das Stichwort. Wenn du nicht alles selbst konfigurieren & programmieren möchtest, könntest du bspw. Envoyer im Zusammenspiel mit Git bzw. Github / Gitlab / Bitbucket nutzen. Allerdings müsste man sich dann noch eine Lösung für das einspielen der Datenbank einfallen lassen.
Hallo Shopwareianer,
vielen Dank für deine Antwort.
Anstelle von Git nutzen wir SVN als Versionsverwaltung aus welchem wir den entwickelten Quellcode auschecken. Damit dieser nicht mit den Sources von Shopware vermischt wird und wir nicht den kompletten Shopware-Quellcode versionieren müssen, setzen wir Symlinks auf die verschiedenen Ordner. Eben Plugin- oder Template-Ordner.
Aus Sicherheitsgründen ist es eine gebräuchliche Empfehlung bei anderen Software-Projekten, die Sources nicht unbedingt im Document root abzulegen. (Bspw. bei TYPO3: https://docs.typo3.org/typo3cms/InstallationGuide/QuickInstall/GetAndUnpack/Index.html)
Die Frage ist, ob das für Shopware so nicht zu trifft?
Danke für den Tip mit Envoyer. Bisher ist unsere Strategie für ein solches “Zero Downtime Deployment” immer die gewesen, dass wir auf einer Subdomain die letzten Anpassungen vornehmen und mit dem Kunden abstimmen und anschließend einfach diese Subdomain auf www. umstellen. Das geht ebenfalls sehr schnell und reduziert die Anzahl an Tools. Für einen Go-Live funktioniert das auch immer sehr gut. Die Frage ist jedoch wie man ein Update bei im Produktivbetrieb macht, ohne dass es hier zu nennenswerten Ausfällen kommt? Kopie des Produktivshops erstellen auf einer Subdomain, Update durchführen wie hier beschrieben: http://community.shopware.com/Shopware-aktualisieren-updaten_detail_1878.html#Schritt_1:_Entpacken_und_hochladen_2 und anschließend wieder auf www umstellen?
Beste Grüße
Andreas
Wir nutzen hier Git für die Entwicklung wollen aber natürlich kein Compose und co auf der Liveumgebung haben. Der buildprozess findet also mit deployer (https://deployer.org/) in GitLab CI (https://about.gitlab.com/features/gitlab-ci-cd/) in einem Docker-Container statt (wir haben einen Server als GitLab CI Runner und as Docker-Image in einer eigenen GitLab-Docker Registry). Das Ergebnis des builds landet dann per rsync direkt auf dem Zielsystem.
Deployer bietet wie Capistrano die möglichkeit mehrere Releases voruzuhalten. Wir haben also nicht nur Zero-Downtime-Deployment sondern auch eine schnelle Rollback-Möglichkeit. Für die verschiedenen Branches im Git ist das Verhalten unterschiedlich. Commits in „preview“ werden automatisch gebaut und auf das Previewsystem deployed. Commits in „live“ werden nur dann deployed wenn die GitLab-Pipeline manuell angestoßen wird.
Was noch nicht so richtig schön funktioniert ist das automatisierte Deployment von Konfiguration (z.b. geänderte Versandkostenregeln) da sind Magento2 und Drupal 8 mit Commerce2 einfach schon weiter im Configuration Management, das es ermöglicht Config in Files zu „dumpen“ und auf andere Systeme zu übernehmen.