"Projektserver" - welche Hardware

[dermoritz]

Hallo

neben der Diskussion welche Tools für ein Javaprojekt die besten sind (http://www.java-forum.org/ides-tool...ware-erfahrung-open-source-sw-uprodukten.html, http://www.java-forum.org/ides-tools/116461-such-java-project-tool-stack.html) kommt die Frage in mir auf, auf welcher Maschine all? das laufen soll.

Der Einfachheit halber hätte ich gesagt eine Maschine(nicht virtualisiert) für CI und PM Software (SVN und Repository Management(Nexus) ist wahrscheinlich woanders). Wär das OK?
Nur auf welcher Hardware. Es ist ein GWT Projekt - von denen man hört, dass sie sehr lange Kompilierzeiten haben. Also was ist im Moment guter "Serverkram"? (die aktuellen core I gibts noch nicht für Server oder?)
2 oder 4 Kerne? 8GB ram?!

 

[maki]

Hardware ist ganz einfach: Je mehr/schneller, umso besser.

Der Einfachheit halber hätte ich gesagt eine Maschine(nicht virtualisiert) für CI und PM Software (SVN und Repository Management(Nexus) ist wahrscheinlich woanders). Wär das OK?

Der Einfachheit halber würde ich vorschlagen: Macht es virtualisiert
Denn falls die Hardware nicht reicht oder gar ausfällt, ist der Aufwand nicht groß das zu korrigieren.

Es ist ein GWT Projekt - von denen man hört, dass sie sehr lange Kompilierzeiten haben.

Nun ja, das ist schon richtig, allerdings heisst das nicht, dass jeder Entwickler auch darunter leiden muss.
Die Anzahl der Permutation sollte für jeden Entwickler auf ein erträgliches Mass reduziert werden, d.h. normalerweise reicht es, JavaScript für eine Browserversion in einer Sprache zu kompilieren. Natürlich nur für den Entwickler, nicht für das gesamte Projekt.

 

[dermoritz]

Danke,

"Macht es virtualisiert"
Das würde bedeuten, dass man von vornherein CI und PM trennt? Oder wie ist das gemeint?

"Nun ja, das ist schon richtig, allerdings heisst das nicht, dass jeder Entwickler auch darunter leiden muss.
Die Anzahl der Permutation sollte für jeden Entwickler auf ein erträgliches Mass reduziert werden, d.h. normalerweise reicht es, JavaScript für eine Browserversion in einer Sprache zu kompilieren. Natürlich nur für den Entwickler, nicht für das gesamte Projekt. "

Das hab ich auch nicht richtig verstanden. Aber das liegt an meinem Nichtwissen über den ganzen Kram: Ich hatte gedacht, das der CI server die Hauptcompilearbeit macht und die einzelnen Entwickler hauptsächlich im hosted Mode arbeiten. Der CI Server kompiliert und deployed das Kompilat irgendwo hin - wo man dann Ui-Tests oder Tests höherer Ebenen (über Integrationstest) macht (ob automatisch oder nicht).
Aber wie gesagt das beruht nicht auf Erfahrung sondern nur auf "wünsch-dir-was-Vorstellungen".

Edit: zu HW-Frage - wären 4 core i Kerne zu viele? (Ich hab im Moment keinen Durchblick, was halbwegs aktuelle Server HW ist.)

 

[maki]

Wenn ihr ein autom. Buildsystem verwendet (und ich hoffe wirklich ihr verwendet einen autom. Build), wird der Java trotzdem noch zu JavaScript kompiliert.
Ein autom. Buildsystem führt auch die Integrationstests automatisch aus.

Der Entwickler sollte zumindest von dem committen den kompletten Build (inkl. Tests) ausführen, wie in deinem anderen Thread bereits erwähnt: Wenn falscher Code ins SCM committed wurde, steht erstmal (fast) alles, ein Fehler beim bauen ist ein Riesenproblem darf darf nicht zur Norm werden, jeder Entwickler muss Veranwortung dass so was nicht passiert. Der CI Server ist das eher sowas wie die letzte Instanz die sagt "Ihr habt Mist gebaut", nicht die erste.
Eine Ausnahme könnten höchstens langsame Integrationstests sein.

Solltest dich imho in GWT einlesen, am besten in die aktuelle Version (2.3), "hosted Mode" gibt es da nicht mehr, heisst jetzt anders

Sehe keinen besonderen Grund PM und CI zu trennen, ausser den üblichen Gründen, ein PM sollte nicht viele Ressourcen brauchen.

Edit: zu HW-Frage - wären 4 core i Kerne zu viele? (Ich hab im Moment keinen Durchblick, was halbwegs aktuelle Server HW ist.)

Wie gesagt, es gibt imho keine Server die "zu schnell" arbeiten.

 

[dermoritz]

Mit "autom. Buildsystem" meinst du Maven? Also soweit ich bemerkt hab ist im "hosted mode"(wie auch immer der jetzt heißt) Maven und das kompilieren außen vor. Also so oft kompiliert man nicht lokal (strg-s und F5 im Browser reicht für 90% der lokalen Entwicklung?!).

die meiste Kompiliererei findest aber bei den Entwicklern (vorm commit) statt - das wolltest du sagen oder?(ggf. mit weniger Permutationen) Aus dem Bauch heraus hätte ich gesagt nicht viel mehr als einmal am Tag?!

Beim CI-Kompilieren/Test geht es mir bei der Serverbeschaffung auch nicht um den normalen Use-Case (ein Lauf pro Nacht). Ich hatte vielmehr an sehr kritische Projektphasen gedacht, bei denen eventuell eben auch mal Mist commited wird - aber dafür mehrmals am Tag (und dann CI angeschmissen wird). In diesen Phasen wäre es gut wenn das nicht ewig dauern würde.

"Sehe keinen besonderen Grund PM und CI zu trennen"
Dann verstehe ich nicht den Hinweis mit Virtualisierung.(ich hatte das so verstanden: wenn beides auf einem System ist, und es sich als zu langsam herausstellt müsste man es ggf. trennen. wenn man beides vorher virtualisiert hat müsste man nur eine VM umziehen für die Trennung)

 

[maki]

Mit "autom. Buildsystem" meinst du Maven? Also soweit ich bemerkt hab ist im "hosted mode"(wie auch immer der jetzt heißt) Maven und das kompilieren außen vor. Also so oft kompiliert man nicht lokal (strg-s und F5 im Browser reicht für 90% der lokalen Entwicklung?!).
/quote]
Maven, Ant, etc. pp.

die meiste Kompiliererei findest aber bei den Entwicklern (vorm commit) statt - das wolltest du sagen oder?(ggf. mit weniger Permutationen) Aus dem Bauch heraus hätte ich gesagt nicht viel mehr als einmal am Tag?!/quote]
Kommt darauf an, wennd er Entwickler 4 mal am tag committed, wäre jedesmal vorher ein build durchzuführen.

Beim CI-Kompilieren/Test geht es mir bei der Serverbeschaffung auch nicht um den normalen Use-Case (ein Lauf pro Nacht). Ich hatte vielmehr an sehr kritische Projektphasen gedacht, bei denen eventuell eben auch mal Mist commited wird - aber dafür mehrmals am Tag (und dann CI angeschmissen wird). In diesen Phasen wäre es gut wenn das nicht ewig dauern würde.

Ein build Pro nacht (nightly build) ist kein normaler UseCase.
Normal wäre es für einen CI Server, bei jedem commit ins Repo einen build zu machen (Continous Integration), immer!
Ohne commit braucht man auch keinen neuen build zu machen, ist ja identisch zum letzten

Dann verstehe ich nicht den Hinweis mit Virtualisierung.(ich hatte das so verstanden: wenn beides auf einem System ist, und es sich als zu langsam herausstellt müsste man es ggf. trennen. wenn man beides vorher virtualisiert hat müsste man nur eine VM umziehen für die Trennung)

Sieh es mal so: Ihr braucht statt einem DualCore mit 2,6 GHz einen QuadCore mit 3 GHz.
Der Umzug eienr VM ist viel einfacher als der eines HW Servers.

 

[muckelzwerg]

Wenn ihr das Ganze in einer VM laufen lasst, könnt ihr es jederzeit "einpacken und mitnehmen".
Jetzt kannst Du Dir selbst ausrechnen welche Vorteile das bietet. Servermigration beinhaltet dann frische Hardware, ein frisch installiertes OS, einmal die Virtualisierungssoftware und dann schiebt ihr die VM einfach rüber.
Keine Serversoftware installieren und einrichten, keine Versionskonflikte etc.
Ausßerdem kannst Du mit VMs prima Backups machen. Festplattenspeicher kostet fast nichts. Wenn ihr nicht gerade extrem große Datenmengen habt, kannst Du regelmäßig das komplette Image der VM speichern.
Es ist ein ziemlich gutes Gefühl, wenn mit einem Update oder einer neuen Version plötzlich nichts mehr geht und man in ein paar Minuten auf "Gestern" umschalten kann.
Du kannst dann auch gleich einen zweiten Rechner anwerfen, dort eine Kopie laufen lassen und die Probleme beheben.
Je nach dem, welche Virtualisierung ihr verwendet, ist der Aufwand bei einer Neuinstallation sehr gering.
Und auf mehrere Rechner verteilen kann man die VMs dann auch noch.

 

[dermoritz]

Ok - ich glaub ich habs geschnallt.
Man installiert den Server als VM Host und lässt zunächst nur eine VM laufen mit allem was man braucht?!

 

[muckelzwerg]

Lies und arbeite Dich da mal lieber ein bisschen ein. Es gibt verschiedene Virtualisierungsmodelle. So enterprise wie Du bei dem Toolstack geklungen hast, solltest Du in die Virtualisierung ruhig etwas mehr Aufwand investieren.
Bist Du für das ALLES zuständig? Gibts dafür keinen Admin?

 

[dermoritz]

ne ich bin eben nicht für alles zuständig. ich lasse einen server beschaffen und wünsche mir eine "standardinstallation". ich würde dann irgendein virtualisierungsprogramm draufhaun und ein bissl rumvirtualisieren .
theoretisch könnte ich auch einen "virtualisierungsserver" beschaffen - aber die sind glaub schweineteuer und riesig.

 

[Noctarius]

Ich würde einen Bare-Metal Hypervisor empfehlen. Den ESXi von VMware gibt es auch kostenlos und sollte für die ersten Schritte in der Virtualisierung locker reichen. Braucht man später Features wie Failover oder ähnliches kann man einfach upgraden und die VM migrieren.

PS: Bare-Metal bedeutet, du hast kein vollständiges Betriebssystem drunter, sondern nur das Mini-System vom Hypervisor selber. Diese sind hoch optimiert und bieten insgesamt mehr freie Resourcen für VMs.

 

[dermoritz]

wie gesagt, dass kann ich mir wahrscheinlich nicht aussuchen. Ich hab keine Ahnung wie unsere VM-Server laufen. Und das Ding was ich bestelle ist ein "normaler" Server.

 

[FArt]

wie gesagt, dass kann ich mir wahrscheinlich nicht aussuchen. Ich hab keine Ahnung wie unsere VM-Server laufen. Und das Ding was ich bestelle ist ein "normaler" Server.

Wir haben nur unnormale Server im Einsatz. Die perfromen hervorragend, kann ich nur emfehlen.