Zorg Testumgebung

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 | tpl 135

^^^ Additional posts ^^^

zorg.ch #47242 by lukas @ 10.09.2004 16:57 - nach oben -
??? Erzaehl das mal in deutlich ;) Am besten mit Screenshots, farbigen Pfeilen, und Links zu der Doku.

zorg.ch #47280 by [z]biko @ 10.09.2004 17:20 - nach oben -
nein, so einen aufwand mach ich deswegen nicht. aber ich erklärs dir in worten: ich hab im zend auf der linken seite eine box, wo ich das ganze filesystem von zorg via ftp sehe. ich kann von da aus direkt ein file öffnen und wieder auf dem server speichern. ich muss es nicht erst downloaden, lokal speichern und wieder uploaden. und das will ich auch mit einem cvs nicht anders haben.

zorg.ch #47282 by Klaudermann T. Spargelzack @ 10.09.2004 17:22 - nach oben -
also biko will dass er die files die auf dem server in der TESTUMGEBUNG liegen im zend bearbeiten kann, und wenns ok von der TESTUMGEBUNG AUF DEM SERVER zur PRODUKTIVUMGEBUNG rüberschieben, per svn. das dürft evtl schwierig werden. hab ich dich richtig verstanden domi?

zorg.ch #47288 by milamber @ 10.09.2004 17:24 - nach oben -
Lokal einen Webserver mit PHP und Mysql zu haben ist doch keine Riesensache...

zorg.ch #47295 by Klaudermann T. Spargelzack @ 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 lukas @ 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 milamber @ 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 lukas @ 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 [z]tschuder @ 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 [z]biko @ 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 milamber @ 10.09.2004 17:35 - nach oben -
Seb scho, jo...

zorg.ch #47321 by lukas @ 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 [z]biko @ 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 lukas @ 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 milamber @ 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 lukas @ 10.09.2004 18:29 - nach oben -
Gibts fuer Windows das ganze nicht als Rundum-Sorglos-Riesen-MSI?

Additional posts

zorg.ch #47292 by lukas @ 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 [z]tschuder @ 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 [z]biko @ 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 lukas @ 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 [z]tschuder @ 10.09.2004 17:34 - nach oben -
Weshalb versuchst du das zu erklähren, das steht ja schon im Template.

zorg.ch #47318 by lukas @ 10.09.2004 17:35 - nach oben -
Weils anscheinend nicht ruebergekommen ist? :)

zorg.ch #47323 by [z]biko @ 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 [z]biko @ 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)

zorg.ch #47287 by lukas @ 10.09.2004 17:24 - nach oben -
Geht so nicht. Da musst du umdenken ;) Du kannst entweder: Weiterhin via SFTP auf den Server zugreifen. das WC dort haben. Du musst mit dem CLI Client arbeiten wenn du was commiten willst. Das musst du fuer Merges ins Produktivsystem aber sowieso immer. ODER Du arbeitest und entwickelst an einem lokalen WC, mit lokalem Apache/mysqld/etc. pp. Dann hast du einen lokalen grafischen SVN Client. Auf der linken Seite siehst du nur das lokale Filesystem. Merges ins Produktivsystem geht aber auch hier nur mit CLI Client.

zorg.ch #47290 by [z]tschuder @ 10.09.2004 17:25 - nach oben -
Du musst die Files nicht jedesmal rauf und runetrladen. Lokal hast du eine Version mit der du Arbeitest, wenn die Arbeiten abgeschlossen sind, veranlasst du Zend/Eclipse/RapidSVN dein Zeuts (Branch nennt sich das glaub) mit dem Zorgserver abzugleichen.

zorg.ch #47294 by lukas @ 10.09.2004 17:26 - nach oben -
Ich glaub er kann sich mit der lokalen Testumgebung nicht so recht anfreunden. An der kommt man aber nur schwer Vorbei, wenn man nicht mit dem CLI Clienten arbeiten will.

zorg.ch #47299 by Klaudermann T. Spargelzack @ 10.09.2004 17:28 - nach oben -
hm, doch das cli problem könnte man THEORETHISCH umgehen indem man die testumgebung lokal mounten könnte (sprich: smb oder so), ist dann zwar wüst weil commit heisst dann per smb oder so vom server holen, dann per svn auf server prügeln ;) aber ich sag nur. Windows kann doch auch ftp "shares" "mounten". "glaubs".

zorg.ch #47302 by lukas @ 10.09.2004 17:29 - nach oben -
Jo, mit SMB Shares wuerds tun. Es ist aber nicht nur ein bisschen haesslich.

zorg.ch #47308 by milamber @ 10.09.2004 17:31 - nach oben -
Lokal wäre viel schneller.

zorg.ch #47309 by Klaudermann T. Spargelzack @ 10.09.2004 17:31 - nach oben -
eigentlich nur weil smb/cifs nicht wirklich als protokoll angesehen wird das man gerne übers inet einsetzt. wieso eigentlich nicht? speed, security?

zorg.ch #47313 by lukas @ 10.09.2004 17:32 - nach oben -
Geschwindigkeit. Ausserdem mag ich Samba nicht. Liegt nicht an SMB selbst, sondern an der Implementation auf der Unix-Seite.

zorg.ch #47355 by Klaudermann T. Spargelzack @ 10.09.2004 18:32 - nach oben -
jo. obwohl das was ich über samba 4 gelesen hab nach was schmackhaftem aussieht ;) wird wohl gleichzeitig wie duke nukem forever rauskommen. (und pirmin)

zorg.ch #47357 by lukas @ 10.09.2004 18:34 - nach oben -
Jedes zweite Samba-Release hat ja wieder nen Security-Critical Bug.

Additional posts

zorg.ch #47366 by [z]tschuder @ 10.09.2004 18:57 - nach oben -
Wo hast du was über samba 4 gelesen?

Additional posts

zorg.ch #47365 by [z]bert @ 10.09.2004 18:56 - nach oben -
erzaehl mehr. ich habe eher das gefuehl, dass meistens das win die probleme macht und der samba schoen tut...

zorg.ch #47368 by lukas @ 10.09.2004 19:02 - nach oben -
Meine letzten Erfahrungen beziehen sich auf 2.2x Releases, vorallem im Zusammenspiel mit LDAP. Das wurde ja massiv verbessert. Aktuelle Erfahrungen hab ich keine mehr. ;)

Additional posts

zorg.ch #47315 by [z]tschuder @ 10.09.2004 17:33 - nach oben -
Da smb/cifs von MS sind wirds wohl die Security sein. Glatt ist ja das cifs comon internet file system heisst :)

zorg.ch #47304 by [z]tschuder @ 10.09.2004 17:29 - nach oben -
Ich hab auch noch nicht die freude an einer Lokalen Testumgebung. Aber wens Zorg wirklich weiter bringt, dann könnte ich mich damit abfinden.

zorg.ch #47249 by milamber @ 10.09.2004 16:59 - nach oben -
Mit CVS o.ä. kannst du genau gleich arbeiten, einfach lokal. Und wenn du alles angepasst hast, gehst du rasch alles auf einmal einchecken.

zorg.ch #47264 by [z]tschuder @ 10.09.2004 17:12 - nach oben -
hast du ja, solange du entwickelst und testest. Wenn dann alles prima läuft, schieebst du die ganze Sache mit svn (oder cvs) wieder auf den server.

zorg.ch #47269 by [z]biko @ 10.09.2004 17:16 - nach oben -
ich will aber nicht lokal, sondern auf dem server testen. also muss ich jede kleinste änderung uploaden.

zorg.ch #47273 by lukas @ 10.09.2004 17:18 - nach oben -
Dann brauchst du wohl deine eigene Entwicklungsumgebung auf dem Server.

zorg.ch #47278 by [z]tschuder @ 10.09.2004 17:19 - nach oben -
Jetzt steht doch da EXTRA, dass man wenn man SVN einsetzen will, einen webserver und einen mysqld auf dem Client braucht. Wenn du das nicht willst, dann bist du gegen die SVN Version.

zorg.ch #47281 by lukas @ 10.09.2004 17:20 - nach oben -
Dasselbe Problem hast du bei CVS auch. Die Systeme sind von der Funktionalitaet insofern identisch. Aber eben, du kannst auch alles auf dem Server entwickeln, du musst dann einfach minimum fuers SCMMS einen CLI Clienten benutzen.

zorg.ch #47296 by [z]biko @ 10.09.2004 17:26 - nach oben -
jetzt hab ich doch EXTRA gefragt, ob es sinn machen würde, das cvs oder svn mit dem testserver einzusetzen. oder ob wir evtl. nur eine versionskontrolle machen wollen. diese frage hat noch niemand klar verneint. also gehe ich davon aus, dass auch beim einsatz von cvs/svn ein testserver noch möglich wäre.

zorg.ch #47300 by [z]tschuder @ 10.09.2004 17:28 - nach oben -
Sagen wirs es so. Es macht wenig sin eine Versionskontrolle einzusetzen, wenn trotzdem alle an den gleichen Sorucen arbeiten.

zorg.ch #47307 by lukas @ 10.09.2004 17:30 - nach oben -
Es geht schon, erfordert einfach verdammt viel Disziplin. Ich hab das bei Administration von Maschinen so, das /etc/ ein SVN Repo ist. Darf dann natuerlich nur einer gleichzeitig dran rumfummeln.