www.lowcodeapp.de - Beschleunigung der digitalen Transformation mit Open Source Low-Code Development.

TYPO3 Development mit Composer

Composer ist ein Package-Manager für PHP. Im Prinzip soll mit diesem Werkzeug der Rollout von Softwareversionen vereinfacht werden. So können durch die in Composer vorhandenen Abhängigkeitsmechanismen sehr einfach GIT-Repositories in speziellen Versionen/Tags oder ein spezieller Branch in Abhängigkeit von Anderen eingebundenen Libraries ausgecheckt werden. Dies vereinfacht das Package-Management und das Deployment von Software erheblich.


Composer ist ein Package-Manager für PHP. Im Prinzip soll mit diesem Werkzeug der Rollout von Softwareversionen vereinfacht werden. So können durch die in Composer vorhandenen Abhängigkeitsmechanismen sehr einfach GIT-Repositories in speziellen Versionen/Tags oder ein spezieller Branch in Abhängigkeit von Anderen eingebundenen Libraries ausgecheckt werden. Dies vereinfacht das Package-Management und das Deployment von Software erheblich.

Eine damit einhergehende Veränderung ist, dass der Composer den Sourcecode im besten Fall aus speziell gepackten Packages holt. Diese Packages müssen vorher über einen Packagist bereitgestellt werden. Für komplett öffentlichen Code erledigt dies packagist.org. Bei den TYPO3 Sourcen und Extensions aus dem TER liefert composer.typo3.org die Daten für Composer. Sollten Packages nicht über einen Composer-Repository zur Verfügung stehen, so können alternativ auch einzelne VSC-Repositories eingebunden werden.

Composer

Composer ist ein in PHP geschriebener Package Manager.
Dieser kann unter Unix-Systemen mit Hilfe einer Downloadanleitung von getcomposer.org bezogen werden. Unter Windows sollte am besten die Datei composer.phar lokal als composer (ohne Dateiendung) in einem Verzeichnis abgelegt werden, welches sich in der PATH-Variable befindet und global aufrufen lässt.
Anschließend sollte sich auf der Kommandozeile composer --version anzeigen lassen.

Initiale Konfiguration

Damit die Packages nicht als ZIP gepackt heruntergeladen, sondern direkt als Repository ausgecheckt werden, muss die preferred Option gesetzt werden. Vor allem bei Windows- Systemen und dem TYPO3 Package ist dies notwendig, da sonst die Installation des ZIPs durch zu lange Dateipfade nicht funktionieren wird.

preferred-source setzen
composer config --global preferred-install source

Bei etwas langsameren Internetverbindungen und großen Packages wie TYPO3 kann es unter Umständen zu einem Timeout und Abbruch der Installation kommen. In diesem Fall muss der Timeout für den Composer erhöht werden werden.

process-timeout setzen
composer config --global process-timeout 5000

Webroot anlegen

Ein neues Projekt-Webroot kann recht einfach mit dem Composer und dem DMK TYPO3 Composer Webroot Project erzeugt werden.

composer create-project dmk/typo3-composer-webroot my-webroot dev-typo3-87

Prinzipiell ist es aber auch möglich in einem leeren Ordner eine neue composer.json - Datei zu erstellen. Diese sollte in etwa so aussehen wie im DMK TYPO3 Composer Webroot Project. Im Rootverzeichnis des Projekts kann nun ein composer install ausgeführt werden. Damit werden TYPO3 und die angegebenen Extensions installiert. Abschließend müssen die Strukturen (fileadmin, typo3temp, etc.) manuell erfasst werden, falls diese nicht durch den TYPO3 Installer für das Projekt passen.

Extension anlegen

In jeder zu verwendenden Extension muss eine composer.json liegen.

Requires

Wie Extensions über Composer installiert werden, ist unter DMK TYPO3 Composer Webroot Project - Add Extensions beschrieben.

Entwicklungsumgebung anlegen

Muss das Projekt von einem weiteren Entwickler installiert werden, dann wird es wie üblich aus dem SCM ausgecheckt. Im Anschluss daran sollte ein composer update ausgeführt werden. Bei einer Aktualisierung gilt das Gleiche: Nach dem git pull muss lediglich composer update aufgerufen werden. Der Workflow hier hängt natürlich vom Gesamtkontext ab. Generell sollte ein composer update nicht ohne die Angabe der zu aktualisierenden Packages gestartet werden.

WICHTIG: Bei Projekten wie Magento wird Composer Symlinks anlegen wollen. In diesem Fall muss der aktuelle Nutzer entsprechende Berechtigungen haben, Symlinks zu erzeugen. Auf Windows geht das nur, wenn die Berechtigung für Standardbenutzer vergeben wird. Bei Administratoren muss Composer in einer Powershell oder in einer Kommandozeile mit Adminrechten gestartet werden.

TYPO3 oder Extensions aktualisieren

Um eine Aktualisierung einer Extension durchführen zu können, muss in der composer.json zunächst die Version angepasst werden, wenn diese fest und nicht relativ als “*” oder “>1.6” angegeben ist.
Als nächstes wird beispielsweise composer update typo3-ter/* aufgerufen, um alle Extensions aus dem TER zu aktualisieren. Mit composer update typo3/cms würde sich nur das TYPO3 CMS aktualisieren.
Während des Update-Prozesses werden die Module aktualisiert und Versionsnummern oder Commit Hashes in der composer.lock festgesetzt. Dies ist notwendig, da auf der Produktivumgebung später lediglich der Befehl composer install ausgeführt wird, welcher nur die in der lock-Datei hinterlegten Versionen einspielt. In der composer.json stehen also die grundlegenden Abhängigkeiten der Pakete und im composer.lock File die zum Release verwendeten Versionen.
Im letzten Schritt müssen die composer.json und composer.lock committet werden.

Development

In der composer.json ist aktuell die Option "minimum-stability" : "dev" gesetzt. Diese Option bewirkt, dass bestimmte Packages in einer Entwicklungs-Version bezogen werden.
Dies ist beispielsweise bei unseren hausinternen Extensions der Fall, die in der composer.json anstatt einer Version mit "dmk/mksearch" : "*" angegeben wurden. Diese Extensions werden dann direkt im Branch "master" ausgecheckt und enthalten immer den letzten Commit.
Damit kann recht einfach in den Extensions entwickelt werden. Änderungen können direkt ins Repo der Extension gepusht werden. Jeder Entwickler wird so direkt über die aktuellen Änderungen informiert.
Die Angabe von Versionsnummern ist bei Packages zu beachten, die in einem bestimmten Release-Zweig benötigt werden. Die Angabe beim TYPO3 Core von "typo3/core" : "~6.2" würde so beispielsweise bewirken, dass nicht das letzte TYPO3 Release, sondern die aktuelle Version 6.2-dev ausgecheckt wird. Um dies zu vermeiden, muss das Package mit dem Stable Alias gekennzeichnet werden: "typo3/core" : "~6.2@stable". So wird immer das letzte Release aus dem 6.2- Zweig verwendet.
Eine direkte Versionsangabe zu einem Package bleibt hingegen unangetastet. Bei "typo3-ter/be-secure-pw" : "6.2.0" würde immer die Version 6.2.0 installiert werden, egal welche stability-Einstellung gesetzt wurde.

Wartungsmodus

Die index.php wird nun immer als Symlink angelegt und kann dadurch nicht verändert werden. Der Wartungsmodus muss daher über die .htaccess gesteuert werden. Sobald die Datei MAINTENANCE_MODE im DocRoot liegt, wird nicht mehr TYPO3 sondern die Wartungsseite ausgegeben. Für bestimmte IP’s kann dies natürlich unterbunden werden.

### WARTUNGSMODUS VIA .htaccess
RewriteCond %{DOCUMENT_ROOT}/MAINTENANCE_MODE -f
### statische Dateien weiter ausliefern
RewriteCond%{REQUEST_FILENAME}
!(\.css|\.js|\.png|\.jp?g|\.gif|\.ico|\.txt|\.pdf|\.xml).*$
### Hier weitere IPs eintragen, die keinen Wartungsmodus sehen
RewriteCond %{REMOTE_ADDR} !^XXX.XXX.XXX.XXX
RewriteCond %{REQUEST_URI} !^/unavailable/
RewriteRule ^(.*) /unavailable/ [QSA,NC,L]

Deployment

Grundsätzlich wird das Webroot-Repository immer mit den auszurollenden Daten in der composer.lock festgesetzt und dazu ein Tag erstellt.
 
Dafür wird ein Composer Update mit no-dev- und stability- Optionen ausgeführt.

composer update --prefer-source --no-dev -o --prefer-stable

Hierbei werden alle Packages in einer stabilen Version installiert. Alle Extensions, welche beispielsweise mittels "dmk/mksearch" : "*" eingebunden wurden, werden in einer stabilen Version gesucht. Deshalb muss vor jedem Deployment jede interne Extension versioniert und getaggt werden.

Auf der Zielumgebung muss mit git fetch --tags zunächst der aktuelle Stand geholt werden. Anschließend wird die entsprechende Version mit git checkout [TAG] && composer install ausgerollt. Anschließend werden alle weiteren Deployment-Prozesse gestartet (Datenbankmigration, Cache aufbauen, etc.)

Wie dieser Beitrag zeigt, dient Composer als ein Packagemanager dazu, den Rollout von Softwareversionen erheblich zu vereinfachen und ihn so zu beschleunigen. Damit ist der Packagemanager ein wichtiges und effektives Tool bei der Softwareentwicklung, insbesondere bei der Arbeit mit TYPO3-Projekten.