Magento 1: Verbesserung meines Modulentwicklungs-Workflows (Modman, Komponist, Git)

Dies ist etwas, woran ich schon seit einiger Zeit denke, aber ich kann nicht die richtige Methode finden, um es zu tun.

Im Grunde arbeite ich mit 6 verschiedenen Websites, auf denen Magento CE 1.9.2+ ausgeführt wird

Auf diesen Websites verwende ich eine Reihe von Erweiterungen, die ich und das Team, mit dem ich zusammenarbeite, entwickelt haben (hier sprechen wir über 50 Erweiterungen), und der Code für diese Erweiterungen ist in Bitbucket gespeichert. Also bin ich nicht die einzige Person, die diese Erweiterungen verwaltet, wir arbeiten mit 3 Leuten daran.

Im Moment, wenn ich ein Feature hinzufügen / einen Fehler für eine dieser Erweiterungen beheben möchte, ist hier mein Workflow:

• Installieren Sie die letzte Version der Erweiterung über Modman auf einer der Websites
• Beheben Sie den Fehler / fügen Sie ein Feature / einen Test hinzu
• Kopieren Sie die Änderungen manuell in einen lokalen Ordner, der alle meine Erweiterungen enthält
• Commit und Push via GIT von diesem Erweiterungsordner zu Bitbucket (1 Bitbucket-Repo pro Modul)
• Dann kann die neue Version des Moduls über Modman installiert werden

Wichtiger Hinweis: Ich verwende hier Modman mit Hardcopy, kein Symlink.

Mein größtes Problem wurde fett hervorgehoben: Ich möchte diesen Schritt überspringen können, da er eine große Ursache für Probleme darstellt (einige Dateien werden manchmal vergessen, falsches Kopieren / Einfügen, erfordert menschliches Handeln).

Wie kann ich also meinen Workflow verbessern, um diesen manuellen Schritt des Kopierens / Einfügens loszuwerden? Ich bin offen für Vorschläge hier.

Ich gehe sehr oft wie folgt vor, was ziemlich rahmenunabhängig ist.

1. Schauen Sie sich das Modul an, an dem Sie arbeiten möchten /path/to/my/module
2. Erstellen Sie eine Verzweigung für Ihre Arbeit (Verzweigung vom entsprechenden Tag usw.).
3. Übernehmen Sie die Arbeit für diesen Zweig (nicht pushen).

4. Definieren Sie in Ihrem Projekt ein lokales Repository für Ihre lokale Kopie des Moduls. Auf diese Weise kann Ihr Projekt nicht überarbeitete Änderungen aus Ihrem LFS übernehmen.

   {
       "repositories": [
       {
           "type": "path",
           "url": "/path/to/my/module"
       }
   ],

5. Sie können dann für Composer Ihren speziellen Entwicklungszweig festlegen (sofern Ihre Projekte dies minimum-stabilityzulassen).

   composer require namespace/module dev-branch-name-here

6. Sie verpflichten sich /path/to/my/module, composer update namespace/moduleim Projekt zu installieren und zu testen.

7. Wenn Sie fertig sind, drücken Sie Ihre Commits und drücken Sie nach oben.

Ich finde, dieser Ansatz funktioniert gut für M1-Module, die https://github.com/Cotya/magento-composer-installer verwenden , da die symbolisierte Installation manchmal mühsam sein kann und Sie stören kann, wenn Sie neue Verzeichnisse oder Pfade hinzufügen, die zuvor nicht symbolisiert waren von modman.

Links, die Sie interessieren könnten

• https://lornajane.net/posts/2014/use-a-github-branch-as-a-composer-dependency
• https://lornajane.net/posts/2015/relying-on-a-dev-master-dependency-in-composer
• https://getcomposer.org/doc/05-repositories.md#path

Debuggen

1. Verwenden Sie composer require namespace/module dev-branch-name-here -vvv, um die Zweige anzuzeigen , die Sie lokal verwenden können.

2. Überprüfen Sie noch einmal, ob in dem Projekt minimum-stability, devin dem Sie das Modul installieren, die Einstellung "" festgelegt wurde .

3. Your requirements could not be resolved to an installable set

Gefunden durch Lesen von Patrick Schwisows Kommentar hier .

Wenn andere Pakete Anforderungen an das zu ändernde Paket haben, erfüllt Ihr Entwicklungszweig diese Anforderungen möglicherweise nicht (was zur Folge hat, dass "Ihre Anforderungen nicht in eine installierbare Gruppe von Paketen aufgelöst werden konnten"). Um dies zu beheben, können Sie einen Inline-Alias ​​erstellen, der allen anderen Paketen als bestimmte Version angezeigt wird.

Kurz gesagt, Sie können Ihr aktualisieren composer.json, um es während der Entwicklung auf eine bestimmte Version zu zwingen.

"namespace/module": "dev-branch-name-here as 1.2.3"

Ich benutze hier Modman mit Hardcopy, kein Symlink.

Da ist dein Problem. Wenn Sie dieses Setup für Ihre Shop-Bereitstellungen nicht ändern können, sollten Sie in Betracht ziehen, gemeinsam genutzte Erweiterungen in einer separaten Instanz zu bearbeiten, in der Sie Modman mit Symlinks verwenden.

Ich verwende Composer mit dem AOE-Composer-Installationsprogramm , um die Erweiterungs-Repositorys direkt zu klonen, .modmanaber die Installation von Git-Modulen mit Modman funktioniert vermutlich auch. In beiden Fällen können Sie direkt im Git-Repository des Moduls arbeiten.

Meine Idee hier für Sie ist es, selbst für Magento1 mit Composer zu arbeiten. Wenn Sie einen eigenen Packagisten hatten , der jetzt, da aws und google cloud installiert sind , nicht allzu schwer zu verwalten ist, können Sie auch einen öffentlichen Packagisten verwenden. Sie hätten "einfachen" Zugriff auf neuere Versionen in Ihren Magento1-Shops.

Dies bedeutet, dass Sie bei Erscheinen einer neueren Version composer updateden Kopiervorgang für Sie automatisieren können.

Werfen Sie einen Blick auf https://github.com/Cotya/magento-composer-installer für Magento1 über Komponisten.

Mit diesem Ansatz können Sie auch direkt am Git-Repository unter dem Vendor-Ordner arbeiten, wenn Sie das Repository zum Kopieren festgelegt haben, .gitund so die Änderungen ohne separate Kaufabwicklung auf ihre Repos zurückschieben. Beachten Sie jedoch, dass Sie hier vorsichtig sein müssen und sicherstellen müssen, dass Sie wissen, in welchem ​​Zweig Sie sich befinden. Andernfalls können Sie Ihren Code entfernen (dies einige Male).