Please, release me…

Neulich standen wir bei einem größeren PHP Projekt, das auf dem Zend-Framework basiert, vor der Aufgabe, die Systeme so einzurichten, daß eine flexible Releaseplanung möglich wurde. Die übliche Trennung in Live, Staging und Developmentsystem und das SVN Repository reichten nicht mehr aus, weil die Anforderungen gestiegen waren.

Die oberste Priorität bei dem Projekt ist Stabilität. Gleichzeitig hagelt es aber ununterbrochen Sonderwünsche von verschiedenen Fachabteilungen. Der einfache entwickeln-testen-livestellen Workflow genügt so nicht. Was ist also zu tun?

Wir entschieden uns, das Projekt grundsätzlich in einen Entwicklungszweig (devel) und einen stabilen Produktionszweig (stable) zu teilen. Dementsprechend gibt es für den Stable-Branch die übliche Devel-Staging-Live Umgebung. In diesem Zweig werden ausschlißelich Bugfixes gepflegt, während Funktionsänderungen und Ergänzungen ausschließlich in dem Devel-Zweig vorgenommen werden, in dem jeder Entwickler einen eigenen Arbeitsbereich hat.

Das ist zwar schon besser, löst aber noch nicht die Problematik mit den Anforderungen der Fachabteilungen, die häufig nicht auf ein neues Major Release warten wollen oder können. Also haben wir die bisherige Applikation in Fachanwendungen und gemeinsam genutzte Basisfunktionen geteilt. Nun stellte sich die Frage, wie man das bei einer Zend FW-basierten Anwendung macht und wie die Versionsverwaltung dafür aussehen kann. Schließlich liegen alle Controller in einem Verzeichnis, alle Models in einem Verzeichnis und alle Views ebenfalls in einem Verzeichnis.

Refactoring
Die Lösung ist, alle Controller einer Fachanwendung in ein eigenes Unterverzeichnis zu packen und dasselbe mit den Models und den Views zu tun. Dementsprechend ändert sich selbstverständlich die Benamung von Dateien, Klassen und URLs. Ein fiktives Beispiel:

Der Controller ‚Abrechnung‚ gehört zur Fachanwendung ‚Bestellungen‘. Nun lag also bisher im Verzeichnis ‚application/controllers/‚ die Datei ‚AbrechnungController.php‚ mit der Klasse ‚AbrechnungController‚. Die URL lautete dementsprechend ‚http://servername/abrechnung/‚.

Nach dem Umbau liegt die Datei ‚AbrechnungController.php‚ in dem Verzeichnis ‚application/controllers/Bestellungen‚ und die Klasse heißt nunmehr ‚Bestellungen_AbrechnungController‚. Die URL ist daher nun ‚http://servername/bestellungen_abrechnung/‚.

Versionskontrolle
Da nun die einzelnen Applikationteile getrennt sind, können sie jeweils in separate Subversion Repositories gepflegt werden. Genauer gesagt, gibt es weiterhin nur eines, das aber wie folgt eingerichtet wird: Im Repository gibt es für jeden Applikationsteil (Basis und Fachanwendungen) ein eigenes Unterverzeichnis. Innerhalb dieses Unterverzeichnisses folgt die üblich Einteilung in ‚trunk‘ (Hauptzweig), ‚branches‘ (Release) und ‚tags‘. Das sieht dann ungefähr so aus:

repos/
    base/
        branches/
        tags/
        trunk/
    bestellungen/
        branches/
        tags/
        trunk/
    rechnungswesen/
        branches/
        tags/
        trunk/

Ein Release ist nun ein Branch von ‚base‘ in das bestimmte Releases der jeweiligen Fachaanwendungen per svn:external eingebunden wird. Es ist also bspw. möglich, eine Version 1.2 mit ‚Bestellungen 0.7‘ und ‚Rechnungswesen 1.4‘ zusammenzustellen.

In den nächsten Wochen wird sich zeigen, ob die Praxis hält, was wir uns in der Theorie so schön ausgedacht haben.