Versionskontrolle für die Modulentwicklung

Ich frage mich, ob es in Bezug auf die Versionskontrolle gute Konventionen gibt, ein Modul zu entwickeln, das Sie sowohl in einer einzelnen Magento-Instanz verwenden als auch als Community-Modul veröffentlichen möchten.

Zunächst habe ich versucht, das Modul mit modman außerhalb meines Magento-Hauptinstanz-Repositorys zu verwalten. Dies war jedoch auf mehreren Ebenen problematisch. Ein einziges Repository, das Sie problemlos in verschiedenen Umgebungen installieren oder in der Produktion zurücksetzen können, ist äußerst nützlich, und ich würde sogar sagen, dass es ein notwendiger Bestandteil meines Workflows geworden ist.

Derzeit entwickle ich es in meinem Site-Repository und plane, es bald in ein separates Repository zu unterteilen. An diesem Punkt werde ich wahrscheinlich Folgendes tun:

• Bauen Sie in meiner lokalen Umgebung mit modman innerhalb eines einzelnen Modul-Repositorys
• Kopieren Sie die Änderungen in das Site-Repository, wenn Sie bereit sind, Code bereitzustellen

Hoffen, dass es einen besseren Weg gibt?

Wir haben ein paar Module, in denen wir dies getan haben und was wir im Wesentlichen getan haben, ist:

• Richten Sie ein Git-Repo für das Modul ein.
• Stellen Sie dieses Modul in der Codebasis der Produktionsstätte bereit und schreiben Sie alles fest, einschließlich:
  • von modman erstellte softlinks
  • Das .modman-Verzeichnis, in dem sich das geklonte Modul-Repository befindet
• Verwenden Sie modman, um es in anderen Versionen und / oder Entwicklungsumgebungen zum Entwickeln und Testen "bereitzustellen".

Auf diese Weise erhalten Sie die Flexibilität, die Sie für die Modulentwicklung benötigen, und können den Code auch auf der Single-Site-Codebasis versionieren. Wenn Sie Änderungen am Modul in der Single-Site-Codebasis vornehmen, können Sie diese direkt in das Modul-Repository zurückschreiben das repo befindet sich dort im .modman verzeichnis.

UPDATE: Als ich das ursprünglich schrieb, habe ich in meiner Antwort nicht berücksichtigt, dass Git nicht zulässt, dass (Unter-) Module in ein Repository geschrieben werden. In diesem Fall muss etwas näher darauf eingegangen werden, dass "alles festgeschrieben wird"!

Übrigens, weil ich das öfter mit modman gemacht habe, um in Git-Repos enthaltene Module in einer von SVN untergebrachten Produktionscodebasis bereitzustellen… und Subversion keine Skrupel hat, die verhindern, dass der gesamte Git-Baum an das VCS übergeben wird.

Also los…

1. Wenn Sie SVN verwenden, um den Code der Produktionsstätte zu speichern, sollten Sie keine Probleme haben, da Subversion (praktisch) kein Konzept für Submodule hat. Es wird nichts ausmachen.

2. Wenn Sie Git für den Code der Produktionssite verwenden, müssen Sie Submodule verwenden, um "alles" in das Code-Repository der Site zu übertragen. Nachdem Sie mit modman so etwas geklont haben:

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   Sie möchten es auch als Untermodul hinzufügen:

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   Sobald Sie dies getan haben, sollten Sie in der Lage sein, das .modman-Verzeichnis und die .gitmodules-Datei zum Index hinzuzufügen und festzuschreiben.

   Nachdem Sie das Repository geklont haben, das diese über Modman installierten Module verwendet, initialisieren Sie einfach die Submodule und aktualisieren Sie:

   git submodule init
   git submodule update
   

PS: Ich benutze Git jetzt in Vollzeit für alle neuen Projekte. Hoffentlich passiert dieses Versehen nicht noch einmal. Tut mir leid, Leute. ;)

Es scheint, dass die derzeitige Konvention Unterstützung bieten soll für:

• Komponist - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Github Repo

In Bezug auf die Verzeichnisstruktur ist dies ein absolutes Minimum, und das Modul wird vorzugsweise im Community-Code-Pool installiert.

Eine empfohlene Verzeichnisstruktur mit einem Minimum wäre:

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

Optional / Mitbringsel:

• Github-Landingpage mit einer Beschreibung, einigen Screenshots und einigen Features mit Aufzählungszeichen.
• Ein Link zu einem installierten Demo-Store wäre auch schön
• Ein Screencast / Zwei-Minuten-Überblick über Ihr Produkt

Edit: Ich könnte falsch verstanden haben.

Durch die Verwendung einer Kombination aus Modman / Gitignore wird Ihr Modul von Ihrer Testumgebung isoliert. Mit der obigen Ordnerstruktur können Sie explizit zulassen, dass nur die Dateien Ihres Moduls für Ihr Repo festgeschrieben / installiert werden. In diesem Fall ist Davids Antwort zutreffender. Die Unterstützung von Modman für dev / deploy scheint der Konsens zu sein.

Auch wenn ich es noch nicht selbst ausprobiert habe, würde ich empfehlen, dafür Composer zu verwenden.

Versionierung einschließlich Abhängigkeiten

Indem Sie die composer.lockDatei im Repository behalten , können Sie die Versionen aller Module korrigieren und jederzeit eine bestimmte Version (einen Zweig, ein Tag oder eine ältere Version) mithilfe Ihres VCS ( git checkout, svn ..) und anschließend wiederherstellen composer.phar install.

Nachteile

Ein Problem, das auftritt, besteht darin, dass Ihre Bereitstellung leicht von mehreren Quellen (z. B. GitHub) abhängen kann, die mehrere Fehlerquellen verursachen.

Wir brauchen also einen Cache oder Proxy, der diese Module speichert, damit wir sie immer bereitstellen können.

Satis scheint in der Lage zu sein, diesen Zweck zu erfüllen (siehe https://github.com/researchgate/broker ) und meine Frage /programming//q/16211671/288568

Kalen,

Vielleicht habe ich Ihren Workflow nicht ganz richtig verstanden, aber es klang, als würden Sie sich lokal in einem Magento-Repo entwickeln und sich dann in ein Modman-Repo trennen. Bearbeiten Sie einfach die Datei ./modman/modulesname/CONTENTS in Ihrer IDE und senden Sie den Code unabhängig in demselben Workflow, den Sie für die Entwicklung verwenden, an das Modul-Repository. Sie können modman für die Bereitstellung in der Produktion verwenden, Sie können mit dem einzelnen Repository im Ordner .modman / modulesname / von cli aus interagieren oder Ihrer IDE eine Versionsquelle hinzufügen, obwohl Sie .basedir wirklich verwenden, um die mit Ihrem Repository verknüpften Pfade von Ihrem Repository fernzuhalten Webroot wird besser spielen.

Es gibt auch ein wirklich nettes Feature von Modman, das viele Leute nicht zu benutzen scheinen. Das Bash-Skript interpretiert eine .basedir-Datei im .modman-Repository. Wenn die Datei nicht existiert, wendet Modman die Symlink-Regeln in der Modman-Datei auf die gleiche Ebene an wie der .modman-Ordner Der Inhalt beschreibt einen Unterordner, der die oberste Ebene Ihres Magento-Codes vom .modman-Pfad aus darstellt. Mit anderen Worten, Sie können alle Magento-Basisversionen in Ordnern wie 'BaseMagento1.9.1.0' ausführen (und ich auch). 'BaseMagento1.14.2.0' und Modman initialisieren den Ordner, der diese enthält. Fügen Sie eine .basedir-Datei in den .modman-Pfad ein, und Sie können den Inhalt problemlos ändern. Dies funktioniert gut zum Testen von Versionen.