Virtualisierte PHP Entwicklungssysteme

[etherius]

Hi Leute,

gleich mal vorab: Irgendwie passt der Thread imho nirgends wirklich zu 100% rein, aber ich dachte mir in dem Forum hier kommen zum Thema die meisten Antworten :-)

Ich frage mich, ob das Konzept, das ich aktuell zwecks meiner Entwicklungssysteme nutze nun wirklich das Beste ist, oder ob es sinnvollere (und vielleicht sogar performantere und einfachere) Möglichkeiten gibt.

Für meine Entwicklungssysteme setze ich aktuell auf ein Debian Squeeze LAMP-Setup in einer Virtuellen Maschine (aktuell VirtualBox, vorher VMWare, tut aber ja eigentlich nichts zur Sache welche Software denk ich).

Die Projektsourcen liegen aus dem SVN ausgecheckt auf dem Hostsystem (Win7) und werden per Shared-Folder in die VM gemounted.

Das System an sich ist recht simpel denke ich. Allerdings ist es auf diese Art und Weise recht kompliziert mit unterschiedlichen Projekten zu arbeiten. Besonders wenn man Staging-Umgebungen mit mehreren Maschinen (Stichwort Varnish Reverse-Proxy oder DB-Replikation) braucht bzw. testen muss, gerät ein durchschnittliches VM-Setup schnell an seine Grenzen.

Arbeitet man man an mehreren Projekten gleichzeitig, wird das Ganze mit den vielen VMs meiner Meinung nach auch sehr schnell unübersichtlich.

Meine Frage: Sehr ihr irgendeine Möglichkeit das oben genannte Setup zu vereinfachen und/oder zu verbessern ohne gleich die gesamte Entwicklungshardware auszutauschen und auf nen dicken Server und Thinclients umzusteigen?

Bin momentan eigentlich für alle Vorschläge offen :-)

gruß

Eth

[flashpixx]

Wir müssten hier etwas die Begrifflichkeiten definieren, denn "Staging" bedeutet im Sinne der Versionskontrolle, dass kein zentrales Repository existiert und jeder Entwickler sich sein lokales Stage selbst zusammenstellt. Da mit SVN arbeitest widerspricht das irgendwie dieser Philosophie, da SVN eben rein zentral organisiertes System ist. Ich würde dann wirklich Git nehmen, denn Git unterstützt eine verteilte Architektur.

Zweitens wäre in meinen Augen wichtig zu definieren, wann man innerhalb der Entwicklung einen neuen Milestone erreicht, d.h. aber für die Organisation des Codes würde dann zu diesem Zeitpunkt ein "Maintainer" den aktuellen Stand als neuen Milestone kennzeichnen und ggf auf ein zentrales Repository bringen, d.h. aber dass in diesem Repository immer der letzte gültige "Releasestand" enthalten ist.

Das wäre jedenfalls mal ein Grobkonzept mit dem man arbeiten kann. Durch Git können einzelne Entwickler / -gruppen auch eigene Entwicklungszweige generieren und diese ggf. später wieder dem zentralen Zweig hinzufügen. Für das Testing der Entwicklung muss man dann eben aus dem Repository nur die entsprechenden Zweige extrahieren. Wenn man auch aktuelle Entwicklungen testen will, muss man sofern man nicht Zugriff auf alle Entwickler hat, auch noch ein Entwickler-Repository pflegen. Das Testen kann dann letztendlich im Grunde mit einem System geschehen, da man aus dem Repository eben die einzelnen Zweige extrahiert und dann direkt testet (sofern keine tiefgreifenen Systemkomponenten betroffen sind, sollte das ohne weiteres auf einem System möglich sein).

[etherius]

Danke flashpixx für deine Antwort. Die Problematik liegt aktuell bei mir weniger auf der Verwaltung der Sourcen, sondern auf den lokalen Entwicklungssystemen für unsere Entwickler.

Unser Systemkern/Standardzeug liegt selbstverständlich in einem zentral verwalteten SVN Repository. Leider sind wir noch ein gutes Stück davon entfernt unser Repository so zu managen wie "ich das gern hätte", aber auf gutem Weg dahin :-)

Was das vielleicht nicht ganz korrekte Wort "Staging" hier angeht, versuche ich mal die Problematik etwas genauer zu schildern.

Wir gehen von einem stabilen Systemkern unseres (vielleicht auch leider :-)) sehr flexiblen Systems aus.

Das System wird in einer bestimmten Konfiguration für Kunde A installiert. Der kunde bekommt kundenspezifische Anpassungen, die wir aber mangels lokaler Testsysteme (wie in meinem ersten Post geschildert) nur auf einem zentralen System beim Kunden selbst (Staging Server) entwickeln können. Das Ganze ist natürlich wenig problematisch (wenn auch unschön), wenn man nur alleine am System schraubt. Ist man aber mit mehreren Leuten am werkeln, wäre ein lokales Testsystem deutlich sinnvoller.

Hat man nur Kunde A, wäre es noch realistisch, ein entsprechendes Lokales Testsystem aufzusetzen, hat man aber mehrere Kunden, die möglicherweise auch noch unterschiedliche Systemkern-Versionen einsetzen (fehlender Update&Wartungsvertrag, keine Freigabe für Updates seitens des Kunden), wird das Ganze schon problematisch :-)

Ich weiß, das hört sich alles extrem kompliziert an. Ist es auch, darum frag ich ja ob jemand Ideen hat

[flashpixx]

Okay, das ist schon etwas anderes. Aber im Grunde war mein Hinweis auf Git schon richtig.

Also Du hast Deinen Source zu irgendeinem Stand (Release), nun passt machst Du kundenspezifische Anpassungen, das entspricht in der Gitterminologie einem Branching, da Du für den Kunden aus dem aktuellen Stand einen eigenen Zweig entwickelst. Im worst-case hast Du eben für jeden Kunden einen Zweig. Wenn Du nun feststellst Du willst kundenspezifische Anpassungen in den Hauptzweig mit übernehmen, dann machst Du ein merging.

Um das ganze nun zu testen, musst Du eben eine VM haben, die eben das Rechnersystem des Kunden nachbildet, also im worst-case auch für jeden Kunden ein System, aber dadurch, dass Du Git benutzt, kannst Du die Sourcen immer aus dem Repository passend ziehen, d.h. Deine VMs müssen nicht den Code halten. Natürlich solltest Du Dir auch überlegen wie Du die Zweige handelst, spontan würde ich sagen, dass ich zwei Git Repository baue, auf einem wird der Hauptzweig abgelegt und auf einem anderen die kundenspezifischen Anpassungen. Du kannst das natürlich alles in ein Repository packen, aber das müsstest Du durchdenken.

Der Kunde selbst kann via Git (und den entsprechenden Rechten) eben seinen Zweig aus dem zentralen Repository auschecken bzw. Änderungen, die vor Ort gemacht werden, gelangen dann automatisch in den Zweig des Kunden. Die Entwickler bestimmen halt selbst wo bzw mit was die lokal arbeiten, da Git lokal auch ein eigenes Repository pflegt.

Soweit das ganze von der Codeorganisation, denn ein SVN ist bei so etwas durchaus etwas unhandlich. Wenn Du nun eben den Hauptzweig updatest, dann musst Du ja ggf Änderungen von dort in den Zweige der Kunden übertragen, bei SVN wird das schon etwas schwierig.

Ich würde was die Testumgebungen angeht einmal schauen, wie differenziert Du das überhaupt brauchst, für Webentwicklungen brauchst Du pro Kunde ja keine eigene VM, es würde da ja reichen einen zentralen Webserver mit diversen Virtuellen Hosts anzulegen und einen zentralen DB Server. Da Du auf dem Testsystem für jeden Kunden einen eigenen VHost hast, brauchst Du dort nur den entsprechenden Zweig aus dem Repository abzulegen. Wenn doch einmal der Fall eintreten sollte, dass man etwas isoliert testen muss, dann zieht man sich eben lokal / zentral schnell eine VM hoch bzw. Du könntest ja diverse VMs mit unterschiedlichem Softwarestand erzeugen, so dass ich als Entwickler nur die VM anwerfen muss und dort eben den entsprechenden Zweig auschecke.

[etherius]

Hmm, ich hab es fast befürchtet, dass das mit unserer SVN Architektur schwierig wird ... leider steht aber die Einführung von Git bei uns aktuell nicht mal zur Debatte, schon alleine aufgrund der Akzeptanz von Git als relativ neue (und teilweise sogar noch unbekannte) Technologie bei unseren Kunden.

Testumgebungen: Joa, als Test/Staging-System im Sinne von Einsatz von Staging Systemen | PHP hates me - Der PHP Blog wär es sicherlich denkbar, da auf ne zentralisierte Lösung abseits vom Kundencluster zurückzugreifen.

Die Problematik liegt eher in der Entwicklung als im eigentlichen Testing auf Test- oder Stagingservern. Aktuell entwickeln die Kollegen mit mehreren Leuten gleichzeitig per FTP auf dem Testserver. Das geht natürlich ständig in die Hose :-(

Ich hatte gehofft, dass es irgendwie eine Lösung gibt, um den ganzen lokalen VM Kram rum zu kommen. Usere Hardware in der Projektabteilung ist leider nicht so der Bringer, und ne komplette Installation mit LAMP+Varnish in der VM kombiniert mit ner IDE und nem Browser lässt sich mit 2GB RAM eher schlecht umsetzen auf den Workstations. Ich will die Kollegen aber trotzdem irgendwo von dem FTP Zeug weg kriegen ...

[flashpixx]

Hmm, ich hab es fast befürchtet, dass das mit unserer SVN Architektur schwierig wird ... leider steht aber die Einführung von Git bei uns aktuell nicht mal zur Debatte, schon alleine aufgrund der Akzeptanz von Git als relativ neue (und teilweise sogar noch unbekannte) Technologie bei unseren Kunden.

Git auch eine SVN Schnittstelle: git-svn(1)

Die Problematik liegt eher in der Entwicklung als im eigentlichen Testing auf Test- oder Stagingservern. Aktuell entwickeln die Kollegen mit mehreren Leuten gleichzeitig per FTP auf dem Testserver. Das geht natürlich ständig in die Hose :-(

Warum FTP !? Das ist unverschlüsselt und ich habe keinen Zugriff auf dein Rep.

Ich hatte gehofft, dass es irgendwie eine Lösung gibt, um den ganzen lokalen VM Kram rum zu kommen. Usere Hardware in der Projektabteilung ist leider nicht so der Bringer, und ne komplette Installation mit LAMP+Varnish in der VM kombiniert mit ner IDE und nem Browser lässt sich mit 2GB RAM eher schlecht umsetzen auf den Workstations. Ich will die Kollegen aber trotzdem irgendwo von dem FTP Zeug weg kriegen ...

Nein Du hast mein Posting nicht richtig gelesen: Jeder Entwickler hat lokal seine IDE und greift lokal auf sein Git Repository zu. In sein lokales kann er comitten, einen Revert machen usw. Erst wenn er meint, dass er die Arbeit abgeschlossen hat, pushed er sein lokales Rep in das "globale". Umgekehrt pulled er die Änderungen der anderen Entwickler in sein lokales. Er kann damit lokal eigene Zweige erzeugen und so unabhängig von den anderen Sachen testen / entwickeln.

Erst wenn eben ein neuer Stand erzeugt wird, müssen alle Entwickler ihre Änderungen in das globale Rep pushen, dieses wird dann auf einem Testsystem ausgecheckt und liegt dort ebenfalls lokal. Wenn jetzt während dem Testfehler auftauchen, dann committet man diese Änderungen in das lokale Rep auf dem Testsystem, ist man mit dem Test fertig, pushed man es wieder in das globale und erzeugt so den endgültigen Release Stand.

Die Verwaltung der Testsysteme muss man dann zentral machen und eben entsprechend pflegen. Wenn man eben Kunden hat, die in den Entwicklungszyklus eingebunden sind, dann können diese eben bei einem neuen Release sich eine Vorabversion aus dem Git Rep auschecken und auf ihrem Realsystem testen, wobei sie eben mit der entsprechenden Berechtigungen auch Änderungen erst in ihr lokales Rep committen und dann ggf in das Entwicklungsrep pushen.

Du musst im Entwicklunsprozess bitte immer hier (auch in der Diskussion) unterscheiden: Testing und Entwicklung. Das Staging bezieht sich nur auf die Tests, aber Änderungen, die bei Tests auffallen müssen auch rückwirkend in die Entwicklung eingehen, d.h. aber Deine Entwicklungswerkzeuge müssen einen solchen Prozess unterstützen. Da Du eben noch individuelle Anpassungen pro Kunde haben kannst, musst Du eben ein Tool einsetzten, was eben solche nicht-linearen Entwicklungszyklen unterstützt.

Natürlich gehört zu dem Einsatz eines solchen Systems entsprechende Akzeptanz auf allen Seiten. Das ist aber kein technisches, sondern menschliches Problem. Wenn Du Deinen Entwicklungsprozess optimieren willst, so dass eben möglichst viele Probleme ausgeschlossen / verbessert werden, dann müssen sich alle an einen Tisch setzen und darüber sprechen. SVN wird bei diesem Prozess nicht funktionieren, weil Du im schlimmsten Fall eine nicht-lineare Entwicklung hast und das kann SVN eben nicht. Und sorry, aber für Git gibt es Konsolentool und auch GUIs, je nach IDE wird Git direkt bzw mit entsprechenden Plugins unterstützt, so dass hier sicherlich nicht das Argument bezüglich schlechter Usability zählt. Außerdem wird der Linux Kernel mit Hilfe von Git entwickelt, so dass ich da fachlich sicherlich kein Argument finden kann, warum das nicht funktionieren sollte.

[etherius]

Warum FTP !? Das ist unverschlüsselt und ich habe keinen Zugriff auf dein Rep.

Das ist glaub ich eher so ne "Weil halt!" Einstellung bei den Kollegen. Die Jungs kriegt man nicht mal dazu verschlüsselte Verbindungen zu verwenden, keine Ahnung was das soll. Unser SVN läuft inzwischen ausschließlich verschlüsselt.

Da der Editor hier leider gerade meinen mühsam zusammen geschriebenen Post gefressen hat, fass ich mich jetzt beim 2. mal etwas kürzer -.-

Nein Du hast mein Posting nicht richtig gelesen: Jeder Entwickler hat lokal seine IDE und greift lokal auf sein Git Repository zu. In sein lokales kann er comitten, einen Revert machen usw. Erst wenn er meint, dass er die Arbeit abgeschlossen hat, pushed er sein lokales Rep in das "globale". Umgekehrt pulled er die Änderungen der anderen Entwickler in sein lokales. Er kann damit lokal eigene Zweige erzeugen und so unabhängig von den anderen Sachen testen / entwickeln.

Doch, hab das schon verstanden mit dem lokalen Repository und der IDE. Aber ich muss ja während des Entwicklungsprozesses einer bestimmten Komponente diese ja trotzdem lokal testen, oder funktioniert dein Code immer sofort? :-)

Aber als Fazit: Die von dir beschriebenen Workflows wird es bei uns denke ich in den nächsten Jahren in der Form nicht geben, dafür sind die vorhandenen Strukturen viel zu fest gefahren. Es hat 2 Jahre gedauert bis es mal ein SVN Repository gab nach der ersten Idee. Und das gibts auch hauptsächlich weil ich mich da in meiner Freizeit noch mit rein gehängt habe dass das läuft.

[flashpixx]

Doch, hab das schon verstanden mit dem lokalen Repository und der IDE. Aber ich muss ja während des Entwicklungsprozesses einer bestimmten Komponente diese ja trotzdem lokal testen, oder funktioniert dein Code immer sofort? :-)

Ich habe im Moment Entwicklungen in PHP und C++. Ich habe auf meinem lokalen System die Libs liegen, gegen die ich linke (das ganze mit Hilfe von Scons, damit es cross-plattform ist). Bei PHP habe ich einen lokale Apache, mySQL und PHP laufen. Sofern die Daten einen Stand erreicht haben, wo ich sie dann Teste, gehen sie in mein Entwicklungsrep und ich checke sie dann auf dem Testsystem aus und teste dann (wobei ich auf das Testsystem via SSH zugreife). Änderungen am Code werden somit immer auf meinem lokalen System gemacht.

Die von dir beschriebenen Workflows wird es bei uns denke ich in den nächsten Jahren in der Form nicht geben, dafür sind die vorhandenen Strukturen viel zu fest gefahren. Es hat 2 Jahre gedauert bis es mal ein SVN Repository gab nach der ersten Idee. Und das gibts auch hauptsächlich weil ich mich da in meiner Freizeit noch mit rein gehängt habe dass das läuft.

Naja da wäre mein Vorschlag, damit Du Dich schon mal damit auseinander setzen kannst, dass Du einfach das SVN Rep in ein Git Rep spiegelst. Soweit ich das im Kopf habe, kann man mit Git-Svn beide Reps synchron halten (schau aber da bitte noch einmal genau nach). Evtl wäre es ja sinnvoll, wenn das mit der Synchronisierung klappt, dass Du eben erst einige Entwickler von Git überzeugst und so eben Stück für Stück den Prozess migrierst.

[etherius]

Ich habe im Moment Entwicklungen in PHP und C++. Ich habe auf meinem lokalen System die Libs liegen, gegen die ich linke (das ganze mit Hilfe von Scons, damit es cross-plattform ist). Bei PHP habe ich einen lokale Apache, mySQL und PHP laufen. Sofern die Daten einen Stand erreicht haben, wo ich sie dann Teste, gehen sie in mein Entwicklungsrep und ich checke sie dann auf dem Testsystem aus und teste dann (wobei ich auf das Testsystem via SSH zugreife). Änderungen am Code werden somit immer auf meinem lokalen System gemacht.

Das macht Sinn. Da unser System aber Linux als Betriebssystem voraussetzt, lässt sich das nicht einfach mit einemp WAMP-Konstrukt abdecken, sondern muss wieder in einer Virtuellen Maschine arbeiten. Wir arbeiten halt auf Windows :-)

Naja da wäre mein Vorschlag, damit Du Dich schon mal damit auseinander setzen kannst, dass Du einfach das SVN Rep in ein Git Rep spiegelst. Soweit ich das im Kopf habe, kann man mit Git-Svn beide Reps synchron halten (schau aber da bitte noch einmal genau nach). Evtl wäre es ja sinnvoll, wenn das mit der Synchronisierung klappt, dass Du eben erst einige Entwickler von Git überzeugst und so eben Stück für Stück den Prozess migrierst.

Das wär ne Idee. Jetzt muss ich nur noch unseren Hoster davon überzeugen, mir das entsprechend einzurechnen, an der Stelle sind Managed-Server doch eher doof :-) Danke aber auf jeden Fall für den Vorschlag, ich schau mir das mal an.

[flashpixx]

Das macht Sinn. Da unser System aber Linux als Betriebssystem voraussetzt, lässt sich das nicht einfach mit einemp WAMP-Konstrukt abdecken, sondern muss wieder in einer Virtuellen Maschine arbeiten. Wir arbeiten halt auf Windows :-)

Wieso? Per Putty kann ich auf einen Linux Host via SSH von Windows verbinden. Sofern auf dem Linux eine GUI läuft kann man sich auch via X11 oder VNC remote auf die GUI verbinden. Wenn der Linux Host in einem VMware System läuft, existiert direkt ein bowserbasierter Player, bei Virtualbox nimmt man RDP. Du hast dann eben n Testsysteme virtualisiert (natürlich entsprechende Hardware vorausgesetzt auf dem die VMs laufen). Aber wenn Du eh nur Webanwendungen testest, dann braucht man nicht viel auf dem Linux Host, lediglich Apache, mySQL und PHP (ich würde mir da ein Gentoo aufsetzen und minimal installieren. Den Portage einmal zentral auf einem Server lagern und alle System mit DistCC ausstatten, damit man schneller kompilieren kann). Das Aufrufen der Webanwendung kann ich dann von meinem lokalen Rechner aus. Natürlich muss die VM von meinem lokalen PC erreichbar sein (also richtiges Netz) und wenn externe Mitarbeiter mitarbeiten sollen, dann baut man eben ein VPN auf. Git Rep sind natürlich auch im LAN verfügbar.

Das wär ne Idee. Jetzt muss ich nur noch unseren Hoster davon überzeugen, mir das entsprechend einzurechnen, an der Stelle sind Managed-Server doch eher doof :-) Danke aber auf jeden Fall für den Vorschlag, ich schau mir das mal an.

Wieso musst Du das auf einem Managed-Server laufen lassen? Du willst es doch eh nur testweise machen, ein SVN hast Du, d.h. Du kannst Dir lokal einen alten Rechner mit einem Linux + Apache aufsetzen und darunter dann das Git laufen lassen und gegen das SVN synchronisieren.

Sorry, aber ich sehe da beim besten Willen überhaupt keine Probleme. Ich gehe davon aus, dass im System entsprechende Benutzerrollen & zentrale Authentifizierungsmechanismen existieren, so dass ich die Reps nur dort anhängen und dann für das Rep die Zugriffsrechte konfigurieren muss. Die VMs bindet man eben analog ein bei Linux würde das via PAM geschehen. Die einzige Arbeit die besteht, eben einmal zu evaluieren welche VMs mit welchen Softwareständen man braucht, ggf den Virtualisierungsserver kaufen & installieren, dann die VMs installieren und das Git Rep aufzusetzen. Bei den VMs würde ich eben ein System wie Gentoo verwenden, weil ich über den Portagetree bestimmte Pakete in der entsprechenden Version blockieren kann, so dass eben genau die Libs installiere, die in der passenden Version benötigt werden (es sollte auch mit anderen Distributionen möglich sein).

Man muss dann nur eben eine Struktur sich ausdenken, wie die einzelnen Entwickler Zugriff auf die Testsysteme erhalten, d.h. falls zwei Entwickler parallel auf dem gleichen Testsystem arbeiten, sie sich nicht gegenseitig die Daten zerstören, aber hier kann man ggf VMs clonen und über eine entsprechende Nachricht beim Login auf der VM eine Warnung erzeugen (z.b. mit who kann man das in der /etc/profile oder /etc/bashrc verankern). Ich würde das Webroot Directory bzw Datadir des DB Server entsprechend irgendwo ablegen, wo jeder dann schreiben kann und ggf per Cron einmal am Tag die Daten entfernen / aufräumen, damit die VMs nicht überlaufen.

Wenn Du ein Entwicklungsgitrep hast, wo nur die Entwickler Zugriff haben, dann kannst Du beim Logout bzw Login auf den VMs sogar automatisch den Stand des Entwickler updaten / einpflegen. Ggf kannst Du die kundenbezogenen Sourcen über Tags bzw Annotated Tags zuordnen. Tags wären z.B. die Release Stände, die Annotated Tags z.B. die Kundennummer / Name. Da die VM ja kundenspezifisch ist, könntest Du anhand der VM und des eingeloggten Entwicklers die passenden Daten für den Kunden über die Annotated Tags bestimmen und auschecken. Wenn der Entwickler sich ausloggt, werden die Daten eben von der VM in das Entwicklunsrep gepushed.

Wenn dann ein Releasestand (kundenspezifisch) erzeugt wird, dann muss aus dem Entwicklerrep eben anhand der Tags die Daten ermittelt werden und ggf dann auf den Release Server gepushed werden (auf den Release Server sollten dann nicht alle Schreibzugriff haben).

Also so würde ich das auch umsetzen, denn ich habe einmal das Rep für die Entwickler, wo jeder seine tägliche Arbeit einchecken kann (das man auch zentral an ein Backup hängen sollte). Die Testsysteme bleiben konsistent und laufen nicht voll, weil man hier immer nur die Daten liegen hat, die man für das Testen braucht. Ein zentrales Rep steht zur Verfügung, auf dem dann die Releases entstehen. Man würde eben bei einem neuen Release die Daten aus dem Entwicklersystem nehmen und z.B. als Prereleasestand kennzeichnen. Mit diesem Stand geht man dann in eine definierte Testumgebung und testet. Treten Fehler auf, werden nur diese Fehler in dem Prelease behoben. Die normale Entwicklung ist davon nicht betroffen und läuft weiter. Ist die Testphase abgeschlossen erzeugt man aus dem Prelease den Release und mergt diesen in die Entwicklung

[etherius]

Sorry, bin bisher leider nicht zum Antworten gekommen. Hab das Ganze mal mit den Kollegen bei uns im Entwicklungsteam durchgesprochen, wir überlegen uns da möglichst zeitnah mal ein entsprechendes Konzept wie wir einige von deinen Ratschlägen umsetzen können. Danke dir auf jeden Fall für deine Tipps :-)

[flashpixx]

Ich drück mal die Daumen