zorg Testumgebung

Um die Zorgsche-Downtime bei Programmierarbeiten zu verkleinern soll eine Testumgebung eingerichtet werden.

Möglichkeiten

Ich denke wir haben folgend Möglichkeiten
Mit dem Umsetzen der besten Lösung werde ich warten bis wir einen eigenen Server haben

Version Beschreibung Coder Server Vorteil Nachteil
SVN mit WC pro dev SVN auf dem Server. Der Coder testet die Version zuhause und lädt sie rauf wens io ist svn client
web+mysql
svn server Coder stehen sich nicht im weg Ne Menge software fuer den Entwickler
Doppelzorg unter test.zorg ist eine kopie von zorg, an der die Entwickler arbeiten FTP Client Cronjob zum kopieren, zweite db Einfach zu realisieren Coder können sich auf die Füsse stehen
CVS Prod ist WC Es gibt keine Testumgebung. Aber wir haben die Möglichkeit ne alte Version zu laden, wenn jemand was kaputt gemacht hat. CVS client CVS server Einfach zu realisieren Bei jeder kleinsten Änderung das File im CVS einchecken.
SVN mit Test und Prod WC Aenderungen werden auf dem Test WC gemacht. Falls alles funktioniert wird das ganze mit SVN auf Prod gemergt. Nichts SVN Client und Server Keine Software bei den Devs noetig Alle arbeiten muessen unter den Entwicklern koordiniert sein, Comittet werden kann nur mit einem CLI Client.

Im allgemeinen geben sich CVS und SVN von Benutzerseite her relativ wenig. Die Technik hinter CVS ist veraltet, wird kaum mehr aktiv weiterentwickelt, und ist deswegen nicht unbedingt die Ideale Wahl. In den obigen Beispielen laesst sich SVN/CVS fuer alle Szenarios verwenden.

Comments

1 up | 2 up | 3 up | 4 up | 5 up | 6 up | 7 up | 8 up | 9 up | 10 up | 11 up | 12 up | 13 up | 14 up | 15 up | 16 up |
^^^ Additional posts ^^^
zorg.ch
#47288 by @ 10.09.2004 17:24 - nach oben -
Lokal einen Webserver mit PHP und Mysql zu haben ist doch keine Riesensache...
zorg.ch
#47295 by @ 10.09.2004 17:26 - nach oben -
bin positiv überrascht das von dir zu hören. es vergrössert wohl einfach den aufwand um eine zorgcode workstation aufzusetzen, was dann u.u. verhindert dass zukünftige oder jetzige zorg coder auch noch am pc vom mami oder im geschäft am zorgcoden sind. ausserdem müsstest ihr wohl für 100% zuverlässigkeit schauen dass eure php und mysql versionen schon in sync sind ;)
zorg.ch
#47301 by @ 10.09.2004 17:28 - nach oben -
Da koennt man sicher was basteln das ein Shellscript from-scratch dir den ganzen Spass sinnvoll auf dem Server aufsetzt. Schliesslich kann man Notfalls auch mit vim/emacs und nem CLI SCMMS client arbeiten.
zorg.ch
#47306 by @ 10.09.2004 17:30 - nach oben -
Naja... eine kleine Version unterschiedlich haben vom PHP oder MySql wäre nicht so schlimm..
zorg.ch
#47311 by @ 10.09.2004 17:31 - nach oben -
Solange die Versionen nicht *NEUER* sind duerften die Probleme wohl kleienr Sinn. Sobald das Zeugs auf den Clients aber neuer ist kanns Probleme geben.
zorg.ch
#47310 by @ 10.09.2004 17:31 - nach oben -
Da seh ich auch ein svn Problem. Was machen Leute die neben der WS zuhause auch noch einen Laptop haben und/oder am Arbeitsplatz einen PC.
Die können nur an einem Ort arbeiten.
zorg.ch
#47317 by @ 10.09.2004 17:34 - nach oben -
also ich finds schon ein bisschen mühsam, wenn ich überall ein identisches testsystem haben muss. das problem sehe ich auch nicht in der version der software, sondern viel mehr in der config. ich arbeite auch auf mehreren pc's an zorg. und ich hab definitiv keine lust, das überall zu installieren und zu konfigurieren.
zorg.ch
#47319 by @ 10.09.2004 17:35 - nach oben -
Seb scho, jo...
zorg.ch
#47321 by @ 10.09.2004 17:36 - nach oben -
Weder PHP noch MySQL kann man von der Konfiguration her gross konfigurieren.

Apache eigentlich schon, aber wa man da konfigurieren kann ist nicht wirklich relevant fuer Zorg.

Das einzige worauf man achten muss sind die verschiedenen PHP Extensions.
zorg.ch
#47324 by @ 10.09.2004 17:44 - nach oben -
auch wenn man nicht viel konfigurieren muss. man muss es trotzdem tun, und vor allem muss man es sauber tun. denn wenn das test-system vom produktivsystem abweicht ist's für n arsch. das problem ist auch, wenn mal ne einstellung ändert.

an die extension hab ich noch gar nicht gedacht, das muss man natürlich auch noch beachten.
zorg.ch
#47332 by @ 10.09.2004 17:51 - nach oben -
PHP hat ein default ini file. Da kannst du praktisch nix einstellen (Errorhandling, Extension-Defaults vorgeben, und wohl das wichtigste: register_globals)

Das einzig relevante was man da Einstellen kann ist das genannte register_globals, aber die V3 wurde ja IIRC so geschrieben das sie das neue Zeugs benutzt $_GET['foo'], also ist das nicht wirklich ein Problem.

Bei mysql kannst du vorallem cache-groessen festlegen, und welche DB Backends verfuegbar sind. Ersteres ist rein Performance-Relevant. Letzteres ist nicht wild, denn man wird wohl per default MyISAM verwenden, und wenn man z.B. auf InnoDB umsteigen will wird man wissen was man tut :)

Die Extensions sind halt ein Problem. Dort muss man halt wirklich erstmal schauen, was fuer die gewollte Funktion benoetigt wird.
zorg.ch
#47353 by @ 10.09.2004 18:26 - nach oben -
Ich glaub das würde gar keinen grossen Aufwand geben - Weber, du hattest doch mal lokal das Zeug am laufen und so - was meinst du dazu?
zorg.ch
#47354 by @ 10.09.2004 18:29 - nach oben -
Gibts fuer Windows das ganze nicht als Rundum-Sorglos-Riesen-MSI?
zorg.ch
#47360 by @ 10.09.2004 18:39 - nach oben -
Ich glaub das gibts sogar. (Falls es tut *g*)
zorg.ch
#47364 by @ 10.09.2004 18:55 - nach oben -
Das gibts, wird von xampp Projekt unterhalten.
zorg.ch
#47367 by @ 10.09.2004 18:59 - nach oben -


So mancher wird schon die Erfahrung gemacht haben: Ein Apache-Webserver installiert sich nicht so leicht. Noch schwieriger wird es, wenn weitere Pakete wie MySQL, PHP oder Perl dazukommen.



Herzig. Ich glaub das ist so ziemlich die Benutzerfreundlichste Unix-Software. Es gibt da Dinge die viel viel viel schlimmer sind ;)
zorg.ch
#47380 by @ 10.09.2004 19:25 - nach oben -
Das sind Windows Nutzer, die müssen das glauben.
Hast du schon mal bei Windows irgendwas grösseres ohne GU konfiguriert?
Additional posts
zorg.ch
#47292 by @ 10.09.2004 17:25 - nach oben -
Jo, ich glaub ich hab ihn diesmal verstanden. Das geht so nicht wirklich schoen. Braeuche auf dem Server pro Developer ne Testumgebung. Und Committen und so ginge nur via CLI auf dem Server.
zorg.ch
#47297 by @ 10.09.2004 17:27 - nach oben -
Wenn Biko der aller aller einzigste ist, der das so haben will. Dann könnte er die Testumgebung (der zweite Vorschlag) als Umgebung nutzen. Mergen müsste er dan halt per Kommandozeile. Aber es git schliesslich nirgend den Fünfer und das Weggli.
zorg.ch
#47312 by @ 10.09.2004 17:32 - nach oben -
ich will es nicht unbedingt so haben. ich wollte nur die möglichkeit in betracht ziehen, und prüfen ob das möglich und sinnvoll wäre.
zorg.ch
#47314 by @ 10.09.2004 17:33 - nach oben -
Ist umstaendlicher fuer den Developer (was ich momentan grad ueber lang und breit zu erklaeren versuche).
zorg.ch
#47316 by @ 10.09.2004 17:34 - nach oben -
Weshalb versuchst du das zu erklähren, das steht ja schon im Template.
zorg.ch
#47318 by @ 10.09.2004 17:35 - nach oben -
Weils anscheinend nicht ruebergekommen ist? :)
zorg.ch
#47323 by @ 10.09.2004 17:38 - nach oben -
ja, das hab ich kapiert. danke für die erklärungen.

(das hier war keine erneute frage, sondern ich hab deep erklärt, worums mir ging)
zorg.ch
#47303 by @ 10.09.2004 17:29 - nach oben -
danke meid, das meinte ich. endlich mal jemand, der verstanden hat, was ich gemeint habe. (hab mich wohl zu unklar ausgedrückt)