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 | 17 up | 18 up |
^^^ Additional posts ^^^
zorg.ch
#47302 by @ 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 @ 10.09.2004 17:31 - nach oben -
Lokal wäre viel schneller.
zorg.ch
#47309 by @ 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 @ 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 @ 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 @ 10.09.2004 18:34 - nach oben -
Jedes zweite Samba-Release hat ja wieder nen Security-Critical Bug.
zorg.ch
#47358 by @ 10.09.2004 18:37 - nach oben -
isch doch glich. openssh hatte das auch lange, trotzdem wurde es weiter eingesetzt. apache hatte ja mal auch so ne phase..
liegts nicht einfach eher dran dass sich hald einige leute mal ein stück code für n source code auditing vornehmen und es dann hald mails auf bugtraq hagelt?
zorg.ch
#47361 by @ 10.09.2004 18:40 - nach oben -
Jo.. Aber es suckt. Software updaten heisst arbeit, und ich bin Faul :)
zorg.ch
#47366 by @ 10.09.2004 18:57 - nach oben -
Wo hast du was über samba 4 gelesen?
zorg.ch
#47365 by @ 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 @ 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. ;)
zorg.ch
#47371 by @ 10.09.2004 19:10 - nach oben -
aha. aber dann gleich so generalisierende sprueche rauslassen. die haemmer gern.
zorg.ch
#47386 by @ 10.09.2004 19:36 - nach oben -
Jo.

Ich darf das, weil ich Gott bin.
zorg.ch
#47315 by @ 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 :)