Neulich standen wir bei einem gr\u00f6\u00dferen PHP Projekt, das auf dem Zend-Framework basiert, vor der Aufgabe, die Systeme so einzurichten, da\u00df eine flexible Releaseplanung m\u00f6glich wurde. Die \u00fcbliche Trennung in Live, Staging und Developmentsystem und das SVN Repository reichten nicht mehr aus, weil die Anforderungen gestiegen waren.<\/p>\n
Die oberste Priorit\u00e4t bei dem Projekt ist Stabilit\u00e4t. Gleichzeitig hagelt es aber ununterbrochen Sonderw\u00fcnsche von verschiedenen Fachabteilungen. Der einfache entwickeln-testen-livestellen Workflow gen\u00fcgt so nicht. Was ist also zu tun?<\/p>\n
Wir entschieden uns, das Projekt grunds\u00e4tzlich in einen Entwicklungszweig (devel) und einen stabilen Produktionszweig (stable) zu teilen. Dementsprechend gibt es f\u00fcr den Stable-Branch die \u00fcbliche Devel-Staging-Live Umgebung. In diesem Zweig werden ausschli\u00dfelich Bugfixes gepflegt, w\u00e4hrend Funktions\u00e4nderungen und Erg\u00e4nzungen ausschlie\u00dflich in dem Devel-Zweig vorgenommen werden, in dem jeder Entwickler einen eigenen Arbeitsbereich hat.<\/p>\n
Das ist zwar schon besser, l\u00f6st aber noch nicht die Problematik mit den Anforderungen der Fachabteilungen, die h\u00e4ufig nicht auf ein neues Major Release warten wollen oder k\u00f6nnen. 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\u00fcr aussehen kann. Schlie\u00dflich liegen alle Controller in einem Verzeichnis, alle Models in einem Verzeichnis und alle Views ebenfalls in einem Verzeichnis.<\/p>\n
Refactoring<\/strong> Der Controller ‚Abrechnung<\/em>‚ geh\u00f6rt zur Fachanwendung ‚Bestellungen‘. Nun lag also bisher im Verzeichnis ‚application\/controllers\/<\/i>‚ die Datei ‚AbrechnungController.php<\/i>‚ mit der Klasse ‚AbrechnungController<\/i>‚. Die URL lautete dementsprechend ‚http:\/\/servername\/abrechnung\/<\/i>‚.<\/p>\n Nach dem Umbau liegt die Datei ‚AbrechnungController.php<\/i>‚ in dem Verzeichnis ‚application\/controllers\/Bestellungen<\/i>‚ und die Klasse hei\u00dft nunmehr ‚Bestellungen_AbrechnungController<\/i>‚. Die URL ist daher nun ‚http:\/\/servername\/bestellungen_abrechnung\/<\/i>‚.<\/p>\n Versionskontrolle<\/strong> 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\u00f6glich, eine Version 1.2 mit ‚Bestellungen 0.7‘ und ‚Rechnungswesen 1.4‘ zusammenzustellen.<\/p>\n In den n\u00e4chsten Wochen wird sich zeigen, ob die Praxis h\u00e4lt, was wir uns in der Theorie so sch\u00f6n ausgedacht haben.<\/p>\n","protected":false},"excerpt":{"rendered":" Neulich standen wir bei einem gr\u00f6\u00dferen PHP Projekt, das auf dem Zend-Framework basiert, vor der Aufgabe, die Systeme so einzurichten, da\u00df eine flexible Releaseplanung m\u00f6glich wurde. Die \u00fcbliche Trennung in Live, Staging und Developmentsystem und das SVN Repository reichten nicht mehr aus, weil die Anforderungen gestiegen waren. Die oberste Priorit\u00e4t bei dem Projekt ist Stabilit\u00e4t. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9,11],"tags":[],"class_list":["post-553","post","type-post","status-publish","format-standard","hentry","category-development","category-onlinedienste"],"_links":{"self":[{"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=\/wp\/v2\/posts\/553","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=553"}],"version-history":[{"count":0,"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=\/wp\/v2\/posts\/553\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ollmetzer.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nDie L\u00f6sung ist, alle Controller einer Fachanwendung in ein eigenes Unterverzeichnis zu packen und dasselbe mit den Models und den Views zu tun. Dementsprechend \u00e4ndert sich selbstverst\u00e4ndlich die Benamung von Dateien, Klassen und URLs. Ein fiktives Beispiel:<\/p>\n
\nDa nun die einzelnen Applikationteile getrennt sind, k\u00f6nnen 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\u00fcr jeden Applikationsteil (Basis und Fachanwendungen) ein eigenes Unterverzeichnis. Innerhalb dieses Unterverzeichnisses folgt die \u00fcblich Einteilung in ‚trunk‘ (Hauptzweig), ‚branches‘ (Release) und ‚tags‘. Das sieht dann ungef\u00e4hr so aus:<\/p>\nrepos\/\r\n base\/\r\n branches\/\r\n tags\/\r\n trunk\/\r\n bestellungen\/\r\n branches\/\r\n tags\/\r\n trunk\/\r\n rechnungswesen\/\r\n branches\/\r\n tags\/\r\n trunk\/<\/pre>\n