Es gibt nahezu kein Projekt welches nur auf einem einzigen System entwicklet und betrieben wird. Heutzutage sind die Server- und Entwicklungsumgebungen so unterschiedlich, das es kaum möglich ist, eine einzige Konfiguration für alle System zu verwenden. Hinzu kommt, dass nicht nur unterschiedliche Umgebungen sondern auch verschiedenste Debugging-, Logging- oder Monitoring-Systeme aktiviert bzw. gehandhabt werden müssen.

Dieses Durcheinander an unterschiedlichsten Umgebungen sollte jedoch nicht im Programmcode behandelt werden, sondern ist Konfigurationsarbeit. Es ist immer einfacher eine Einstellung zu ändern, als bestehenden Source-Code durchforsten zu müssen um die Konfiguration zu bearbeiten.

Symfony 2 bringt hier von Haus aus schon ein gut aufgeteiltes Konfigurationssystem, welches wir uns genauer ansehen werden und dies für größere Projekte adaptieren.

Die Basis: dev/prod/test-Systemumgebungen

Die Konfigurationen in Symfony werden in Produktion (“prod”), Development (“dev”) und Test (“test”) aufgeteilt.
In der Produktionsumgebung z.B. werden alle Fehler ausschließlich in eine Log-Datei geschrieben und dem User wird nur eine generische Fehlermeldung angezeigt.

Man ist jedoch hier nicht nur auf die drei Umgebungen angewiesen, sondern kann auch seine eigenen Umgebungen erstellen. Doch dazu später mehr.

Welche Umgebung aufgerufen wird, steuert die php-Datei im web/ Ordner des Symfony Projekts. Standardmäßig sind app_dev.php und app.php die Einstiegspunkte der Anwendung.

Ruft man die URL des Projektes ohne Verwendung von app_dev.php auf, wird standardmäßig (auf einem apache Server mit aktiviertem mod_rewrite) die app.php aufgerufen. Die app_dev.php lässt sich desweiteren nur lokal erreichen.

Konfigurationsarbeit: Verschiedene Systeme sinnvoll konfigurieren

Im Folgenden werden drei Systeme verwendet:

  1. Entwickler System: MySQL, Apache, Windows 7 (app_dev.php)
  2. Stage System: MySQL, Apache, Ubuntu (app.php)
  3. Live System: MSSQL, IIS, Windows Server (app_iis.php)

Es wird vorrausgesetzt das alle passenden Extensions (z.B. pdo_sqlsrv für Windows, etc.) bereits vorkonfiguriert sind und mit Doctrine und Symfony funktionieren.

Vererbung von YAML Konfigurationsdateien

Durch das einbinden von Konfigurationen in einer YAML Datei kann man sich bei der Konfiguration auf das überschreiben bestehender Parameter beschränken ohne hier Code/Parameter duplizieren zu müssen.

In unserem Beispiel ist dies besonders eindrucksvoll, wenn man sich hier die /app/config/parameters.yml ansieht. Da standardmäßig in Symfony für jede Umgebung eine eigene Config anhand des Umgebungsnamens (config_{umgebung}.yml) gezogen wird, entstehen folgende Konfigurationen:

  1. Entwickler System: config_dev.yml
  2. Stage System: config_prod.yml
  3. Live System: config_iis.yml

Richtig konfiguriert resultieren daraus folgende Systeme:

1. Entwickler System
config_dev.yml:

imports:
    - { resource: config.yml }
	- { resource: parameters.dev.yml }
# Umgebungsabhängige Einstellung wie z.B. debugging etc
framework:
	...

parameters.dev.yml:

parameters:
	database_user: dev
    database_password: test123

2. Stage System
config_prod.yml:

imports:
    - { resource: config.yml }
	- { resource: parameters.prod.yml }
# Umgebungsabhängige Einstellung wie z.B. debugging etc
framework:
	...

parameters.prod.yml:

parameters:
	database_user: prod
    database_password: u4zb3jrfb
	secret: "srzkljsdr6mzjW_m6WJK_%mrjz"

3. LIVE System
config_iis.yml:

imports:
    - { resource: config.yml }
	- { resource: parameters.iis.yml }
# Umgebungsabhängige Einstellung wie z.B. debugging etc
framework:
	...

parameters.iis.yml:

parameters:
	database_driver: pdo_sqlsrv
	database_user: iis
    database_password: "678e4p68ldcgh,dtu,"
	secret: "dgv35inhjsrthnmawasabk5n4juhwk4-6jmnrt5jkmn4-5j"

Durch die Überlagerung der Parameter können die Konfigurationen einfach eingebunden werden und überschreiben nur bestimmte Werte (bspw. database_name, database_user oder database_driver).
Im Beispielprojekt konnten wir durch nur eine Änderung eines Parameters die Datenbank wechseln.

Datenbankmanagement per Doctrine

Dank Doctrine muss nicht speziell auf eine DB Struktur programmiert werden. Zwar hat Doctrine (und ORM im Allgemeinen) seine Tücken bei großangelegten Projekten, kann aber durch seine Objekt orientierte Programmierung schnell punkten. Deshalb sollte hier unbedingt auf den Einsatzzweck geachtet werden! Großprojekte mit mehreren Hunderttausenden oder gar Millionen Datensätzen sind eher ungeeignet für Doctrine.

Die DB Struktur sollte hier komplett von Doctrine übernommen werden. Nachbearbeitungen oder Änderungen sollten nur über die Doctrine Entitäten durchgeführt werden. Phpmyadmin ist hier der schlechteste Weg!

Konfigurationen in Controllern auslesen

Parameter oder Konfigurationen sollten immer in die parameters.yml oder config.yml ausgelagert werden. Hart codierte Werte in PHP Klassen lassen sich schwerer ändern, als Parameter in einer Konfiguration.

Parameter aus den Konfigurationen können im Controller folgendermaßen ausgelesen werden:

$param = $this->container->getParameter('test.parameter1');

Wichtig zu beachten ist hierbei die Möglichkeit der Vererbung! Sprich: standardmäßig in parameters.yml definierte Werte lassen sich durch das einbinden darauffolgender Konfigurationen wieder überschreiben!

Fazit
Symfony liefert mit der intelligenten Verwendung von umgebungsabhängigen Konfigurationen ein einfaches System um Server richtig und nachvollziehbar zu konfigurieren.