Entwickeln unter einer VM

[hoika]

Hallo,
ich arbeite seit Jahren nur noch mit VM's.

- Update einer Komponente oder neue Version einer Komponente bloß mal ausprobieren
VM kopieren
Komponente updaten
beten
starten

Klappt -> OK, klappt nicht, Backup zurück
Solange die VM auf einer SSD liegt, habe ich keine Performance-Probleme.

Und ein Backup einer lauffähige Entwickler-Kiste zu haben, finde ich schon wichtig.

- High-DPI/ large Fonts Entwicklung
Entwickler-VM mit Delphi bei 100%
zweite VM ohne Delphi mit z.B. 200%. Die VM läuft auf dem 2. Monitor.
per Batch-Datei wird die Version in die large Fonts-VM kopiert

- verschiedene Betriebssysteme testen
XP-VM, Vista-VM, Win8-VM, Win1703, Win1019 usw.
Dafür brauche ich doch keinen separaten Rechner, eine jeweilige Windows-Lizenz reicht

Das alles noch mit einem anständigen VCS verbunden, macht die Entwicklungsarbeit doch etwas weniger stressig.

[Heimlich]

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

[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❓

[Uwe Raabe]

Zitat von Der schöne Günther:

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

VM ≠ Viele Menschen

[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.

[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.