Mehrere Versionen vom Zend Framework parallel nutzen
Viele kennen sicherlich das Problem. Wenn man einmal mit dem Zend Framework in einem Projekt gearbeitet hat, möchte man dies auch gerne in anderen Projekten nutzen. Meistens beginnt es dann damit, dass man die Library Dateien ins neue Projektverzeichnis kopiert. Nach und nach wächst der Pool an Projekten, welche das Zend Framework nutzen. Und irgendwann kommt man an den Punkt, wo eines der Projekte ein neues Zend Framework Release nutzen möchte oder muss. Danach wird ein anderes Projekt auf eine neue Version portiert und ehe man sich versieht, hat man 23 Projekte zu pflegen, die 5 verschiedene Zend Framework Releases verwenden. Und es ist zudem einfach nicht die Zeit da (oder sie wird vom Kunden nicht bezahlt), alle Projekte immer auf dem selben Release aktuell zu halten.
Für dieses Problem halte ich die Installationen der Zend Framework Dateien immer getrennt von den eigentlichen Projekten. Ich arbeite mit Ubuntu Linux und da ist dies sehr einfach zu handhaben. Dafür halte ich ein Verzeichnis vor, in dem alle Releases, die verwendet werden, installiert werden. Dieses Verzeichnis lautet bei mir z.B. /home/devhost/ZendFramework und enthält folgende Verzeichnisse:
- /home/devhost/ZendFramework/ZendFramework-1.7.4
- library
- /home/devhost/ZendFramework/ZendFramework-1.8.4PL1
- bin
- library
- /home/devhost/ZendFramework/ZendFramework-1.9.5
- bin
- library
Um Zend_Tool nutzen zu können (soweit es in dem Release schon vorhanden ist), wird für jedes Release ein eigener symbolischer Link erstellt. Würde ich nur die neueste Version von Zend_Tool nutzen, könnte dies in älteren Projekten zu Problemen führen, weil Zend_Tool Komponenten nutzen könnte, die in dieser alten Version noch nicht existierten. Das Problem, der Bugs bei Zend_Tool in den verschiedenen Versionen, nehme ich dabei in Kauf:
-
sudo ln -s /home/devhost/ZendFramework/ZendFramework-1.9.5/bin/zf.sh /usr/bin/zf-1-9-5
-
sudo ln -s /home/devhost/ZendFramework/ZendFramework-1.8.4Pl1/bin/zf.sh /usr/bin/zf-1-8-4
Ob dies erfolgreich war, lässt sich durch folgende Aufrufe testen. Dabei sollte die Hilfe von Zend_Tool mit Angabe der Versionsnummer ausgegeben werden.
-
zf-1-8-4
-
zf-1-9-5
Um ein neues Projekt zu erstellen, rufe ich zuerst Zend_Tool für die entsprechende Zend Framework Version auf und erstelle damit ein neues Projekt. Danach wechsele ich in das neue Projektverzeichnis und erstelle einen symbolischen Link zur Library der gewünschten Zend Framework Version.
-
zf-1-9-5 create project /home/devhost/Test_Ralf
-
sudo ln -s /home/devhost/ZendFramework/ZendFramework-1.9.5/library/Zend/ /home/devhost/Test_Ralf/library/Zend
Danach existiert unter /home/devhost/Test_Ralf/library/ das Verzeichnis /Zend, das auf /home/devhost/ZendFramework/ZendFramework-1.9.5/library/Zend/ verweist. Nun kann ich ganz normal mit den Zend Framework Dateien arbeiten. Bei späteren Updates, muss ich dann darauf achten, dass ich die richtige Version von Zend_Tool verwende, bzw. das nach dem Anlegen von Controllern und Views keine Probleme auftauchen. Alternativ könnte ich auch symbolische Links im Projektverzeichnis zu den jeweiligen Versionen von Zend_Tool erstellen, dann muss ich da später nicht mehr daran denken.
Der Vorteil bei dieser Vorgehensweise ist, dass ich bei einem neuen Zend Framework Release mal eben schnell den symbolischen Link umbiege, meine Unit-Tests durchlaufen lasse und bei größeren Problemen wieder einfach auf die vorher genutzte Version zurück schalten kann.
Bin für Kommentare, Verbesserungsvorschläge und Hinweise, dass dies alles viel besser geht, sehr dankbar. :-)
Dieser Beitrag wurde geschrieben
am Donnerstag, 29.10.2009, um 08:55 und wurde abgelegt unter Tipps & Tricks |
.
Du kannst alle Antworten für diesen Beitrag über den RSS 2.0 Feed verfolgen.
Du kannst eine Antwort schreiben oder einen Trackback von deiner Site setzen.
Donnerstag, 29.10.2009, um 10:37
Ich persönlich würde die Symlinks nicht in /usr/bin sondern in /usr/local/bin anlegen. Das hat hauptsächlich zwei Gründe:
1.) es entspricht dem Filesystem Hierarchy Standard (FHS)
2.) auf meinen Linux-Systeme ist /usr/local i.d.R. eine eigene Partition die dann auch eine komplette Neuinstallation überlebt
Donnerstag, 29.10.2009, um 10:38
Hallo Ralf,
eine andere Idee (schwört mir bisher nur im Kopf herum) wäre vielleicht auch die, dass man den php_include_path auf das entsprechende Verzeichnis setzt: set_include_path(ZF_1_9_5_PATH);
Damit könnte man innerhalb des Projektes diesen Switch vornehmen, ohne tatsächlich auf die Konsole zu müssen. Was könnten dabei für Nachteile entstehen? Hat das mal wer ausprobiert?
Wir versuchen demnächst diesen Ansatz bei demobereich.de irgendwie umzusetzen, damit unsere Kunden ein ZF-Projekt verwalten und weiterentwickeln können und dort über den PHP-Script-Weg diesen Wechsel vornehmen können.
Ansonsten sehr hilfreicher Artikel, wir verwalten mittlerweile auch Projekte mit in Summe 3 verschiedenen ZF-Versionen...und auch da kann man nicht einfach eine Aktualisierung auf eine einheitliche Version treiben. Ganz schlimm. So wird es wohl vielen Systemhäusern gehen.
Donnerstag, 29.10.2009, um 13:32
@Robert: Wo soll die Konstante herkommen? Was ist, wenn ich PHP in ein Verzeichnis einsperre? Ralfs Lösung hat den Vorteil, dass man mittels eines Build-Servers recht einfach Builds für den Live Betrieb erstellen kann. Bei deiner wird es schon schwieriger!
Donnerstag, 29.10.2009, um 13:45
@Dennis: Die Konstant war nur eine Abkürzung, um die Schreibarbeit zu ersparen. Sie wäre vorab in PHP so definiert worden: define('ZF_1_9_5_PATH', '/home/devhost/ZendFramework/ZendFramework-1.9.5');
Aber das mit dem "einsperren" ist natürlich richtig. Wir haben auch so eine "eingesperrte" Variante. Aber wie kann ich dann ohne Symlinks den gleichen Ansatz umsetzen? Hat da irgendwer eine Idee?
Donnerstag, 29.10.2009, um 21:47
@Robert Für die eingesperrten Variante könnte man das entsprechende Verzeichnis mit 'mount --bind' innerhalb des open_basedir verfügbar machen.
Freitag, 30.10.2009, um 08:50
@Roy: Vielen Dank für den Tipp. Ich werde das mal an unsere Entwicklung weiterleiten. Vielleicht löst das unsere Herausforderung und wir können unseren Kunden ab demnächst alle ZendFramework Versionen und weitere Frameworks von Haus aus anbieten.