Entwickeln unter einer VM

[Uwe Raabe]

Ich arbeite neben meinen eigenen Projekten mit verschiedenen Kunden, die zum Teil unterschiedliche Systemumgebungen voraussetzen und teilweise auch bestimmte Dinge für das Entwicklungssystem vorschreiben. Daher gibt es für jeden Kunden (mindestens) eine eigene VM. Das hat auch den Vorteil, daß nicht plötzlich durch die Anpassung (z.B. neue Library) für den eigenen Kunden irgendwelche Probleme mit den anderen Kunden auslöst. Und wenn ich dann irgendwann mal wieder beim Kunden vor Ort bin, kopiere ich mir die passende VM einfach auf meinen Laptop und habe sicher alles dabei was ich brauche.

Neben den Kunden-VMs gibt es noch spezielle VMs für den Build-Server und die verschiedene Agents, diverse DB-Server VMs (MSSQL, Interbase, Firebird, ...) die ich gar nicht alle auf meinem Host sehen will und die sich häufig auch gar nicht gut miteinander vertragen. Die müssen auch nicht alle immer gleichzeitig laufen.

Wenn ich dann mal wieder meinen Rechner erneuern muss, brauche ich auch nicht wieder alles neu zu installieren, sondern kann mit einem frischen Windows weitermachen.

[Uwe Raabe]

Zitat von Heimlich:

Wie wird das ganze bei einem Team von 5 Entwicklern realisiert?

Was hat das mit VMs zu tun?

[Der schöne Günther]

Vielleicht dachte er, alle müssen sich die VM teilen❓

[mschaefer]

Die Entwicklungsumgebung ist bei mir der geringere Anreiz. Bei Webprojekten mit verschiedenen Datenbanken und Rest-Services streiten sich die Installationen um die Ports. Also virtuelle Maschinen für verschiedene Szenarien zu haben, finde ich hilfreich. Die Quelltexte liegen bei mir übrigens immer auf dem Hostrechner.

Grüße in die Runde

Martin

[himitsu]

Ein "saubere" VM zum Testen kann auch nie schaden, eventuell sogar Mehrere in verschiedenen Sprachen und OS-Versionen.
z.B. falls man vergessen hat gewisse DLLs ins Setup aufzunehmen, die zwar auf dem Entwicklungsrechner vorhanden sind, aber später bei den Endanwendern nicht.
Hier ist es noch viel prakticher mit Snapshots alles schnell auf einen definierten Stand zurückzusetzen.

Die alten VM+DelphiVersionen kannst dir auch aufheben und kannst dann deinen Code (Komponentenentwicklung) auch in anderen Delphis testen, ohne dein Hauptsystem mit vielen Delphis zuzumüllen.
Und jetzt bei der Installation eines neuen Delphis passiert es nicht, dass dir die alte Installation kapput geht. Somit kannst schnell zurück, wenn das Neue doch nicht so funktioniert.

PS: Selbst wenn du nur in einem Windows arbeiten willst, dann könntest du immernoch ein Minimal-Linux als Host nehmen und darin dann dein eines Windows laufen lassen, mit dem du immer arbeitest.
Hast dann somit fast die volle Rechenleistung und RAM zur Verfügung und kannst dennoch ganz schnell (vielleicht sogar regelmäßig automatisch) Snapshots machen.

Zitat:

Wie wird das ganze bei einem Team von 5 Entwicklern realisiert?

Da hast du doch noch einen Vorteil.
Einer richtet es ein und alle können sich dann eine fertige Kopie besorgen.
und während die Einrichtung läuft, kann nichts Anderes kaputt gehn.

PS: Gemeinsam auf einem Server via RDP zu arbeiten kann manchmal Probleme bereiten, wenn Einer was kaputt macht.
Da wäre dann die VM gut, wo dann jeder bei sich oder gemeinsam auf dem Server (jeder in seiner VM) arbeitet.
Ich hab hier gerade 128 GB RAM und 16 Kerne (32 Threads) ... da merkst es kaum, wenn da mehrere VMs aktiv sind.

[dummzeuch]

Ein Problem bei (zu)vielen VMs, das mir immer auf den Keks ging: Man muss für jede getrennt das Betriebssystem aktualisieren, und das frisst Zeit ohne Ende.

Wie macht Ihr das? Gar nicht aktualisieren? Aber ist das durch die Zwangsupdates von Windows 10 ja eigentlich keine Option mehr.

[Uwe Raabe]

Zitat von Der schöne Günther:

Vielleicht dachte er, alle müssen sich die VM teilen❓

VM ≠ Viele Menschen

[himitsu]

Zitat von dummzeuch:

Ein Problem bei (zu)vielen VMs, das mir immer auf den Keks ging: ...

Ich weiß nicht mehr wie und wo das war, aber ich glaube es gab irgendwo eine "besserere" Vererbung für VM. (glaube sowas mal gesehen/gehört zu haben)
* Eine VM erstellen und dort Windows installieren
* die VM ableiten und dort ein Programm drauf (oder mehrere Kopieen für die Entwickler)
* und die Systemupdates in der Basis-VM einspielen, welche dann in die Ableitungen durchgereicht werden

[Uwe Raabe]

Zitat von dummzeuch:

Ein Problem bei (zu)vielen VMs, das mir immer auf den Keks ging: Man muss für jede getrennt das Betriebssystem aktualisieren, und das frisst Zeit ohne Ende.

Bei Windows 10 läuft das ja weitestgehend automatisch. Wenn die VM eh ungenutzt rumsteht, kann sie sich ja auch updaten.

Die Updates von VMware Workstation und anschließend der VMware Tools in jeder VM sind da schon manchmal nervig. Andererseits kann ich gut verstehen, wenn so OS-nahe Software bei einem OS-Update auch aktualisiert werden muss.

Ich finde aber, die Vorteile überwiegen.

[Der schöne Günther]

Eben, Updates passieren irgendwie im Hintergrund, davon bekommt man ja nichts mit. Und wenn es einen absolut stört deaktiviert man halt für eine Woche jegliche Updates oder deaktiviert das Internet an der VM.