Entwickeln mit Composer (Developing / Deployment)

Hallo zusammen,
ich habe angefangen mit Composer Contao-Erweiterungen zu entwickeln. Die Vorteile der automatisierten Updateverteilung und die Abhängigkeitsauflösung von Composer sind wirklich genial.
Der Arbeitsablauf beim Entwickeln und Debuggen ist bei mir aber aktuell wohl nicht so ideal. Um nicht das Rad neu erfinden zu müssen, suchte ich im Forum nach Erfahrungen/Tipps/Vorschlägen für einen darauf optimierten Arbeitsablauf/Entwicklungsaufbau. Habe aber nichts gefunden. Vielleicht habe ich nicht am richtigen Ort gesucht. Hat mir jemand einen Tip, wo sowas zu finden sein könnte?

Dann schon einmal vielen Dank an dieser Stelle!

++++++++++++++++++++++++++++++

Ansonsten wäre ich sehr froh, wenn ich vielleicht dem einen oder der anderen "virtuell" über die Schultern schauen könnte.

Stand der Dinge:
-------------------
Durch Composer bin ich erst richtig mit Git in Kontakt gekommen.
Ich entwickle mit phpStorm und habe dafür für die einzelne Extension ein Projekt angelegt, dafür GIT als VCS aktiviert und mit dem Repo auf Github/Bitbucket verbunden. Diese Original-Extension-Daten liegen jeweils in einem eigenen Verzeichnis ausserhalb des aktuellen Webprojekts und auch ausserhalb des Apache-Verzeichnisses. Mache ich Änderungen an der Extension, commite und pushe ich diese und bei einer grösseren Bereinigung setzte ich ein Tag für eine höhere Version.
Soweit ist alles total angenehm. Auch das Updaten für die Live-Version klappt 1a.

Wenn ich entwickle/debugge, habe ich dafür einen lokalen Apache laufen. Die Extensions wird als »Source« im Composer aktualisiert und durch die links von /TL_ROOT/composer/vendor -> /TL_ROOT/system/modules/ strukturell vereinfacht.
Zudem nutze ich in phpStorm die Möglichkeit über »VCS->Import into Versions Control -> Share project ...«, um ein Projekt über Bitbucket zu verwalten. Dafür muss diese Extension in ein eigenes Projekt gepackt sein.

Mein Problem aktuell:
------------------------
Der Ablauf gegenüber früher ist schon einmal wesentlich sauberer, da jetzt nicht mehr Hardlinks von den Original-Projekt-Daten zu den jeweiligen Entwicklungs-Web-Verzeichnissen zeigen. Nur der jeweilige Aufwand für eine Veränderung ist doch wesentlich grösser.

Wahrscheinlich habe ich aber einen grundsätzlichen Denkfehler. Es gibt garantiert eine wesentlich einfachere Lösung als die, die ich seit einigen Tagen anwende. Aktuell entwickle/debugge ich in einem eigenen phpStorm-Projekt, in dem sich die Daten des Webprojekts in einer Entwicklerversion befindet und alle Extensions eingebunden sind.

Bei einer Änderung muss ich zur Zeit:
1. mir die veränderten Extensions merken
2. diese aus dem Apacheverzeichnis ins Original-Projekt-verzeichnis kopieren
3. wie gewohnt commiten und pushen und bei Bedarf einen neuen Tag setzten
4. die Extension aus dem vendor Verzeichnis löschen (weil sonst eine Meldung "nicht commitete Veränderung bei den Daten" kommt)
5. die Paket-Aktualisierung anstossen


Schon bevor und auch während ich hier diese Punkte auflistete, dachte ich, die Lösung ist eigentlich simpel und irgendwie liegt sie greifbar da. Nur leider verknoten sich die Gedanken. Die eine Lösung wird durch die andere verhindert und umgekehrt.

Wahrscheinlich müsste ich die GIT-Versionierung einfach im Entwickler-Webserver-Verzeichnis nutzen. Aber irgendwie scheint mir das nicht so wirklich ideal. Zudem muss eben für das Share project ein eigenes phpStorm Projekt-Verzeichnis definiert sein.
Wie macht ihr das? Hat mir jemand einen Knotenlöser?

Würde mich sehr darüber freuen.
Martin

Hallo zusammen,
leider bisher keine Tips. Vielleicht ist es ja um zu viele Ecken gedacht.

Trotzdem habe ich mir eine eigene Lösung ausgeknobelt, die alle Vorteile

- verschiedene phpStorm Projekte mit Git-Versionierung in phpStorm Projekt
- Zugriff auf alle Projekte über ein Projekt ohne Git-Vorteile zu verlieren
- Anbindung an verschiedene Repositories (Github/Bitbucket)
- Einfachster Ablauf von Debugging/Developing, wenn System einmal eingerichtet
- Saubere Commits für jede Extension getrennt
- Verwaltung über Packagist oder Satis

vereint. Ich schreibe sie hier einfach rein, falls auch jemand anders die selben "Probleme" haben sollte. Vielleicht schreibt ja auch der eine oder die andere Ihre Vorgehensweise.

Voraussetzung:
Contao mit Composer (ER3)
Repositories ohne Auto-Aktualisierungs-Hook oder mit Satis gebündelt

Ich habe für mich eine gangbare Lösung für Projekte (Extension) in Projekt (lokaler Webserver mit den versch. Extensions):
Zur Lösung:
1. lokales Projekt in Directory ausserhalb von Webserver mit Github oder Bitbucket synchronisieren (pushen). In jedem Projektordner für jede Extension ist eine eigene Versions-Kontrolle über ein .git Ordner eingefügt.
2. Über das Contao-Backend und dessen Packet-Management (PM) die Extensions hinzufügen.

(über UI oder composer.json Wichtig: statt »dist« auf »source« setzten, damit symlinks in den TL_ROOT/system/modules Ordner vom TL_ROOT/composer/vendor Ordner gemacht werden, und dev-master für die Paket-Wahl )

Nun ist auf dem lokalen Webserver die jeweilige Extension-Version die auf GH/BB hinterlegt ist

3. Nun über ein symlink (auf meinem OS X System hat dies nicht funktioniert (Fehlermeldung), da das PM die Vendor-Ordner und Dateien dann eben nicht mehr als Ordner/Dateien erkennt. Daher benutzte ich Hardlink's.

Diese sind in OS X von Haus sicherheitshalber unterbunden. Unter https://github.com/selkhateeb/hardlink gibt es aber eine sehr praktikable Lösung für Hardlinks unter OS X.

Danach steht einem Aktualisieren von den Paketen über PM nichts mehr im Wege (wenn die eigenen Extension-Repo's keinen Auto-Aktualisierungs-Hook in Services gesetzt bekommen haben oder über ein statisches Satis-Repository verwaltet werden). So funktioniert die Versionierung mit GIT für jedes Extension-Projekt innerhalb des Website-Projekts auf dem lokalen Server.
Alle commit und push's /pull's werden mit dem richtigen Repo ausgetauscht. Und auf dem lokalen Debugging-System läuft immer die aktuelle Version der aktuellen.
Sollen Live-Server mit einer neuen Version der Extension versorgt, muss nur noch eine Version ge'tag't werden und das Packagist oder Satis zur Aktualisierung aufgefordert werden.

Ist Packagist oder das Satis-Repo aktualisiert, wirft PM beim nächsten Aktualisieren einen Fehler.
Am Einfachsten ist es die symlinks/hardlinks aus dem vendor Verzeichnis zu löschen, bevor eine Aktualisierung angeworfen wird. Dann wird auch der lokale Debugging-Webserver wieder mit den neusten Versionen versorgt. Diese danach wieder mit Hardlinks überschreiben.

Womöglich suche ich viel zu weit an unnötig komplizierten Orten.
Wenn jemand anders einen völlig anderen und vor allem einfacheren Ablauf kennt, würde ich mich sehr darüber freuen.
Grüße Martin
Anhang 13706