Symfony 4 und Flex: Erkenntnisse beim Migrieren auf die neue Struktur

Jedes Symfony Projekt wird früher oder später auf die neue Symfony Flex Struktur angepasst werden. Hier sind einige meiner Erkenntnisse dazu. Als Symfony Entwickler findet man schnell die Dokumentation zum Upgrade auf Flex. Diese ist jedoch sehr allgemein und geht nicht auf diverse Details ein.

Vor der Änderung gab es eine Datei im Symfony Projekt, welche die komplette Konfiguration geladen hat. So konnte man die Konfiguration nur aufteilen, indem man weitere Dateien importierte. Dies lässt sich prinzipiell auch mit der neuen Struktur so umsetzen, ist aber eigentlich nicht der gewünschte Weg. Stattdessen sollte die Konfiguration für die einzelnen Bundles aufgeteilt werden. Meine Vorgehensweise dazu war:

• Bundles über Symfony Flex neu installieren, wodurch die Standardkonfiguration dieser erstellt wird und zwar gleich mit dem dafür vorgesehenen Namen.
• Danach habe ich diese mit den Werten der ursprünglichen Konfiguration angepasst.

Die Services der Applikation werden wie gehabt über eine Datei definiert, sie muss nur entsprechend verschoben werden. Für Bundles werden diese äquivalent zur Konfiguration verwaltet.

Für Routen gibt es jetzt einen eigenen Ordner, wo man diese auf mehrere Dateien sinnvoll aufteilen kann.

Für variable Werte sollte man in Symfony Flex anstatt wie bisher mit Parametern zu arbeiten, diese über Umgebungsvariablen bereitstellen. Symfony stellt eine Komponente bereit, mit der man diese über eine .env Datei für die Applikation setzen kann. Die Grundidee dazu ist, in der Entwicklung damit zu arbeiten, um die Werte einfach ändern zu können und auf Produktivsystemen tatsächlich die Umgebungsvariablen zu setzen.
Darum haben wir uns im Team dazu entschlossen auch am Produktivsystem mit der .env Datei zu arbeiten:

• Sie ist von unserer Seite aus einfacher wartbar 
• Alle Variablen sind an einer Stelle zu finden 
• Sie befindet sich direkt im Ordner der Applikation 
• Man muss nicht erst herausfinden, wo diese am entsprechenden System gesetzt werden

Zusätzlich kann eine Beispiel-Datei im Git hinzugefügt werden, diese muss dan nur kopiert und entsprechend angepasst werden. Mit dieser Datei wird dann auch gesetzt, um welche Applikations-Umgebung es sich handelt. Das hat zur Folge, dass auch die Symfony Console die richtige Applikations-Umgebung verwendet, ohne dies extra angeben zu müssen.

Um Variablen bei Unit-Tests bereitstellen zu können, werden diese standardmäßig direkt in der Konfigurationsdatei für die Tests angegeben. Diese Variablen müssen dann allerdings an unterschiedlichen Stellen warten und wenn man hier dann auch die Symfony Console ausführen muss, fehlen Parameter.

Stattdessen haben wir hierfür eine eigene .env Datei für Testzwecke ins Git gegeben, welche über ein kleines PHP Skript über die Konfiguraitondatei für Tests geladen wird – ähnlich wie in der Symfony Console. Wenn man hierfür auch eine Unterscheidung zwischen einer Distribution-Datei und einer lokalen Version macht, kann man diese Werte je nach System einfach anpassen.

Mit Symfony 4.2 ändert sich die Verwaltung der Variablen über .env Dateien minimal, da auch neue Funktionen hinzukommen. Unter anderem werden die Variablen dann automatisch bei Unit Tests berücksichtigt und eigene Variablen pro Umgebung können direkt definiert odert überschrieben werden. Außerdem ändert sich die Namensstruktur ein wenig. Näheres hierzu finden Sie hier.

Das AppBundle wurde entfernt, womit jetzt alle Klassen direkt im src liegen und als Namespace wird standardmäßig App und für Tests App\Tests verwendet. Für dieses Umbenennen nimmt man am besten die Funktion der IDE her. Man muss dies auch im composer.json noch die autoload Konfiguration entsprechend anpassen. Wenn die Applikation eine gute Test-Coverage hat, lässt sich danach einfach feststellen, ob das Umbenennen Probleme verursacht hat oder nicht.

Die zu ladenden Bundles werden jetzt nicht mehr direkt im Applikations-Kernel definiert. Es gibt jetzt eine Konfigurationsdatei, wo angegeben wird für welche Umgebungen ein Bundle geladen wird.

Nachdem es in der neuen Struktur kein AppBundle mehr gibt, wird dies jetzt direkt im Kernel definiert.

Aufgrund des fehlenden AppBundles, werden Custom Mappings für Doctrine Entities nicht mehr wie gehabt automatisch ausgelesen, sondern entsprechend dieser Anleitung definiert.

Für Templates gibt es jetzt einen eigenen Ordner. Templates von verwendeten Bundles kann man auch direkt darüber überschreiben, siehe Dokumentation. Es kann jedoch sein, dass dies bei manchen der existierenden Bundles noch nicht funktioniert. Der Grund ist, dass diese dann die Templates über eine eigene Logik laden, welche die neuen Ordner noch nicht richtig berücksichtigt. Das sollte aber mit Updates behoben werden.

Ich finde die Änderungen gut, da sie für mehr Übersichtlichkeit sorgen. Ja, es war auch vorher schon möglich die Konfiguration mehrfach aufzuteilen, aber jetzt ist dies einfacher und standardmäßig bei neu installierten Bundles der Fall. Es ist jedoch mit etwas Aufwand verbunden die Struktur bei einem existierenden Projekt entsprechend anzupassen. Bei einem neuen Projekt sollte man natürlich gleich mit der neuen Struktur starten.