Der beste Weg, um TYPO3-Projekte zu verwalten

TYPO3 Aufbau

Eine anständige Versionsverwaltung von Quellcode ist meiner Meinung nach einer der Grundpfeiler, um funktionalen und vor allem fehlerfreien Code zu schreiben. Vor allem im Team mit mehreren Entwicklern und Projektmanagern.
Aber wie baut man auf Dateiebene ein komplettes TYPO3-Projekt auf? Wie verwaltet man Extensions aus dem TER? Wie bindet man Eigenentwicklungen ein? In den letzten Jahren habe ich für meine Projekte einen entsprechenden Aufbau und Ablauf entwickelt, den ich gerade auf den Prüfstand stelle, um ihn zu verbessern. Verbessern kann man ja immer.

Das gesamte Projekt basiert auf composer und bindet nicht nur die TYPO3-Sourcen, sondern auch alle per TYPO3 Extension Repository Composer Repository erreichbaren Extensions ein. Der Code, der dadurch eingebunden wird, wird per gitignore aus dem Projekt-git ausgeschlossen, Erweiterungen, die nicht per composer installiert werden können, landen aber dann doch in der Versionsverwaltung. Damit alle Entwickler mit dem gleichen Versionsstand arbeiten.

Nur was ist mit den Erweiterungen, die man selber entwickelt und die nicht im TER landen? Man könnte sie natürlich auch per composer und einer eigenen Repository-Verlinkung integrieren. Jede Erweiterung wird in einem separaten git versioniert und in der composer.json lassen sich eigene Repositories verlinken und per require einklinken. Nur heißt das auch, dass man Entwicklungen in den Extensions nicht in diesem Projekt vornehmen kann. Von daher finde ich das zwar den eigentlich konsequenten Weg, der aber so nicht praktikabel umgesetzt werden kann. Man müsste nach Änderungen die Änderungen per composer einladen, um die „Auswirkungen“ im Projekt zu sehen und zu testen. Mühsam und zeitaufwendig.

Ich bin dazu übergegangen, die Erweiterungen per Symlink unterhalb von web/typo3conf/ext einzubinden. Der Code liegt außerhalb des Projekt-Verzeichnisbaums in seiner eigenen git-Struktur. Entwickelt wird dann in einer separaten IDE-Instanz. So sind Änderungen in der Erweiterung sofort im eigentlichen TYPO3-Projekt sichtbar, die Repositories aber voneinander getrennt.

Nur bin ich mir nicht mehr so sicher, dass es der beste Weg ist, ein komplettes Projekt zu verwalten. Und ihr so?

7 Kommentare

  1. Hallo Stephan,

    es geht also um nicht-öffentliche Eigenentwicklungen – jetzt habe ich das verstanden :)
    Entweder du packst eine solche Extension mit in dein Haupt-Repository (sinnvoll wenn nur in dem Projekt verwendet) oder du erstellt ein eigenes, privates Repository für solche Extensions. Letzteres hat den Vorteil, dass du diese Extension auch für andere Projekte einsetzen kannst.
    Private Repositorys kannst du auch über Composer ansprechen und beim Deployment auschecken (oftmals muss dazu ein Deployment PubKey hinterlegt werden).
    Ein Einbinden über Git Submodule wäre zwar möglich, ist aber ein sprichtwörtlicher „Pain in the ass“.
    Eine Lösung mit Symlinks sehe ich nicht bzw. wiederspricht etwas dem „Composer-Gedanken“.

    Viele Grüße, Alex

    1. git submodule ist einfach nur grausam umgesetzt. Beim ersten Merge-Konflikt ist man quasi aufgeschmissen. :-)

      Ich würde ja wie oben schon beschrieben, gerne meine privaten Repos per composer einbinden. Aber diese Extensions sind ja im Projektverlauf selber „in Entwicklung“. Wenn ich sie per composer einbinde, kann ich aber nicht direkt entwickeln, da ja die git-Struktur nicht mitgenommen wird, oder?

      Beispiel: Es gibt Änderungen in der Template-Extension. Wenn ich die Extension per composer integriere: wo werden die Änderungen integriert? Doch nicht im Projekt selber, sondern im git der Template-Extension. Diese muss ich dann pushen und im Projekt dann per „composer update“ einladen. Und das ist ja mehr als umständlich. Oder habe ich was übersehen?

  2. So läuft ein vernünftiges Deployment :)
    Einer oder mehrere Entwickler arbeiten gegen ein oder mehrere Repositories. Entweder wird bei einem Push in ein Repo automatisch deployed oder es muss von Hand angeschmissen werden.
    Aber selbst wenn du von Hand einmal „composer update“ eingeben musst, halte ich den Aufwand für überschaubar. Zumal du vermutlich erst mal lokal entwickelst und wenn du fertig bist, deine Änderungen pusht.

    1. Ja, das wäre ja auch meine bevorzugte Lösung. Ich entwickle halt nur gerne etwas „direkter“ im Projekt, dass bei mir lokal liegt. Für die Entwicklung in der Template-Extension müsste ich mir ja dann quasi noch ein eigenes TYPO3 aufziehen, dort dann das Template entwickeln, pushen und im eigentlichen Entwicklungsprojekt per composer updaten, testen und von dort dann ins Abnahme-/Test-System beim Kunden deployen.
      Mal schauen. Werde in der Woche mal meinen Prozess anpassen. Und dann von allen anderen Entwicklern gelyncht werden. :-D

  3. Ja, so ein Workflow wird in vielen Agenturen genutzt. Lokal hat man eine komplette Kopie der Installation auf dem Server und dort schraubt man an der Extension bis man einen Stand hat. Danach werden die Commits gepusht und eventuell ein neuer Tag erstellt.
    Auf dem Server kannst du dann direkt (oder indirekt über Jenkins oder ähnliche Tools) ein „composer update“ machen, dass dir dann die neueste Version holt und TYPO3 entsprechend zusammenbaut.
    Der Vorteil: Du kannst lokal schrauben und kaputt machen aber die Online-Version ist davon nicht betroffen. :)

    1. So ähnlich ist der Workflow ja schon, nur würde ich jetzt gerne das eigentliche Projekt noch von den Extensions korrekt trennen.
      Wie gesagt: ich probiere mal rum und blogge dann mal das Ergebnis.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.