it-swarm.dev

Gedanken zur Entwicklung mit virtuellen Maschinen

Ich werde als Entwicklungsleiter für ein Startup arbeiten und ich habe vorgeschlagen, dass wir VMs für die Entwicklung verwenden. Ich spreche nicht davon, dass jeder Entwickler einen Desktop mit VMs zum Testen/Entwickeln hat, sondern ein Server-Rack, in dem alle VMs verwaltet werden und die Entwickler von einem microPC (ChromeOS irgendjemand?) Lokal oder sogar remote von zu Hause aus arbeiten Computer.

Für mich sind die Vorteile die Tatsache, dass es extrem skalierbar, auf lange Sicht billiger, einfacher zu verwalten ist und dass wir die Hardware optimal nutzen. Was die Nachteile angeht, kann ich mir keine anderen Showstopper vorstellen, als dass wir jemanden brauchen, der das Setup einrichtet/wartet.

Ich hatte gehofft, dass einige von Ihnen an Ihrem Arbeitsplatz ein ähnliches Setup haben und sich mit Ihren Meinungen abfinden könnten. Vielen Dank.

51
J_A_X

Was hoffen Sie als Bruchteil des Entwicklungsbudgets einzusparen? Mir scheint, Sie machen sich Sorgen um ein Epsilon. Die Kosten für Maschinen für Entwickler betragen weniger als 5% der Gesamtkosten, um einen Entwickler im Personal zu halten. Daher ist die einzige wichtige Frage: "Spart es Entwicklern Zeit?" Es könnte sein, wenn sie keine Zeit damit verbringen müssen, Entwicklungssoftware zu installieren und zu aktualisieren. Oder es kann Zeit kosten, wenn das Netzwerk ausfällt oder der Server ausfällt oder höchstwahrscheinlich die Reaktionsfähigkeit im Internet am wenigsten fehlt. Die moderne Entwicklung hängt von der Interaktion von Tastendruck zu Tastendruck mit einer IDE oder zumindest einem sehr intelligenten Editor ab. Eine Verzögerung dieser Interaktion um einige zehn Millisekunden zerstört die Entwicklerproduktivität. Entwickler müssen auch diese neue Arbeitsweise erlernen. Wenn dies pro Entwickler nur einen Tag dauert, haben Sie bereits mehr Arbeit aufgewendet als die Kosten eines neuen Desktops.

Dies sind keine Einwände gegen VMs, sondern potenzielle Einwände gegen die Remoteentwicklung.

96
kevin cline

Ich denke, du bist penny-weise und Pfund-dumm.

Erstens sind die Maschinenkosten trivial im Vergleich zu den Kosten eines Entwicklers. Sie sollten daran arbeiten, die Produktivität zu maximieren und nicht die Maschinenkosten zu minimieren.

Zweitens ist die Latenz (nicht die Bandbreite) der Schlüssel zu vielen Programmieraufgaben - insbesondere zur Textbearbeitung. Für jeden Dollar/Pfund/Euro, den Sie für Ihre Entwickler an Maschinen sparen, geben Sie mindestens zehn für Netzwerk-Upgrades aus, um auch nur einen Anschein von Produktivität zu erhalten - und selbst dann wären sie wahrscheinlich produktiver, wenn Sie durch die Lieferung sparen würden sie mit Pentium III haben Sie irgendwo in einem Müllcontainer gefunden.

Ich denke auch, dass es einen erheblichen Vorteil hat, wenn Ihre Entwickler eine Umgebung verwenden, die mindestens der vom Endbenutzer erwarteten Umgebung entspricht. Unabhängig von offiziellen Leistungszielen in einer Spezifikation und dergleichen basieren die meisten Programmierer ziemlich stark darauf, wie sich der Code beim Testen "anfühlt". Wenn sie eine völlig andere Umgebung als die des Endbenutzers verwenden, verschwenden sie wahrscheinlich Zeit mit Kleinigkeiten, während sie wichtige Probleme völlig übersehen.

So attraktiv eine homogene Umgebung unter dem Gesichtspunkt der Unterstützung und dergleichen klingt, sollten Sie generell so viel Abwechslung wie möglich in den Maschinen der Entwickler fördern. Entwickler benötigen ohnehin selten viel Unterstützung. Wenn Sie sofort wissen, wann Code mit einem anderen Grafikchip, einer anderen CPU, einem anderen Netzwerkadapter usw. ausfällt, zahlt sich die minimale Investition mehr als aus.

Fazit: Wenn Sie Code schreiben, der (zumindest in erster Linie) verwendet in einer virtualisierten Serverumgebung sein soll, müssen Sie diesen nur für Ihre Entwickler bereitstellen. Wenn Sie es trotzdem zum Testen tun, ist es kann (aber nicht unbedingt) auch für die Entwicklung sinnvoll. Wenn Sie ohnehin einen stark überspezifizierten Server und ein Netzwerk benötigen (oder zumindest haben), ist es möglicherweise sinnvoll, dies zu nutzen, indem Sie das verwenden, was Sie bereits zur Verfügung haben.

Unter den meisten typischen Umständen scheint es mir jedoch, dass dies wahrscheinlich mehr Probleme mit sich bringt, als es löst.

58
Jerry Coffin

Das war eine meiner Ideen in der Vergangenheit: einen Hochleistungsserver mit der gesamten erforderlichen Software und eine Reihe von Desktop-PCs mit geringer Leistung, die nur für die Verbindung mit dem Server über Remotedesktop verwendet werden.

Die Vorteile wären:

  • Das solide Backup. Einige Entwickler möchten ihre Desktop-Computer möglicherweise nicht regelmäßig sichern, sodass eine zentrale Lösung zuverlässiger wäre.
  • Die Möglichkeit für jeden Entwickler, von überall aus zu arbeiten. Damit meine ich auch, von jedem PC im Unternehmen aus zu arbeiten. Nehmen wir am Morgen an, der Entwickler möchte stille Arbeitsbedingungen. Er geht in sein eigenes Zimmer und arbeitet dort. Dann möchte er ein paar Programme programmieren oder in einem sozialeren Umfeld arbeiten. Er fährt einfach seinen Desktop-PC herunter, geht in einen anderen Raum, in dem sich zehn Computer befinden, und stellt von dort aus eine Verbindung her. Nein "Ich muss alle meine Apps erneut laden".

Nun, es gibt einige ernsthafte Probleme damit, die mich denken lassen, dass ich das Ding in den nächsten Jahren niemals benutzen werde.

  • Spezifität von Remote-Lösungen. Was ist mit der Fernarbeit mit mehreren Computerbildschirmen gleichzeitig? Ich meine, ist es einfach? Ist es offensichtlich? Sind Verknüpfungen, die ich täglich verwende, aktiviert, wenn ich in der Ferne arbeite? Ich bin mir nicht sicher. Was passiert, wenn ich Strg + Umschalt + Esc drücke, um die Liste der aktuell ausgeführten Programme anzuzeigen? Oh ja, es funktioniert nicht, also muss ich mich jetzt daran erinnern, es anders gemacht zu haben.

  • Leistungseinbruch. Ich bin mir nicht sicher, ob es überhaupt keinen Leistungsabfall geben wird. Und denken Sie daran, ein Programmierer, der einen langsamen Computer verwendet, ist ein unglücklicher Programmierer. Und das Unternehmen, das seine Programmierer mit den schlechten Bedingungen unzufrieden macht, wird niemals qualitativ hochwertige Software produzieren.

  • Höhere Auswirkungen einer Katastrophe. Hosten Sie die Lösung auf einem redundanten Server? Haben Sie ein redundantes Netzwerk in Ihrem Unternehmen? Angenommen, der Router fällt aus und ist nicht redundant. Dies bedeutet, dass alle Entwickler jetzt nicht mehr arbeiten können. Überhaupt. Weil sie keine lokal installierte Software haben. Weil sie nicht einmal Quellcode haben: Er befindet sich auf dem Server. Also hört jeder auf und Sie zahlen all diese Leute pro Stunde, nur um zu warten, bis der Router ersetzt wird.

  • Hardwarekosten. Wie viel kostet es, wenn es sich um einen einzigen Server handelt? Wenn Sie beispielsweise zwanzig Entwickler haben, würden 64 GB RAM auf dem Server) ausreichen? Nicht so sicher. Würde eine Quad-Core-Lösung mit zwei CPUs ausreichen? Auch hier habe ich einige Zweifel. Woran denken Sie sonst? Eine Art Cloud? Oder haben Sie eine skalierbare Lösung, die auf mehreren Servern funktioniert? Sind Sie bereit, die Kosten für Windows Server (wenn Sie Windows verwenden) pro Computer zu bezahlen?

  • Stromkosten. Wenn Sie vollständig remote arbeiten, bedeutet dies, dass Sie fast die gleiche Menge an Strom auf der Serverseite ausgeben, als ob Sie lokal arbeiten würden, zuzüglich der Menge an Energie, die vom lokalen Computer und vom Netzwerk verschwendet wird.

  • Lizenzen. Ich bin mir nicht sicher, ob ich es als Vorteil oder Problem ansehen muss, aber ich denke, dass die Kosten für die Softwarelizenzierung in diesem Fall viel höher sein werden.

Denken Sie auch hier an alle Kosten für Verwaltung, Support, Bereitstellung und Wartung. Mit einer benutzerdefinierten Lösung wie dieser kann es leicht riesig werden, wenn man nicht berücksichtigt, dass jedes Mal, wenn etwas fehlschlägt, jeder Entwickler herumläuft und darauf wartet, seine Arbeit fortsetzen zu können.

19

Wir verwenden Amazon ec2-Instanzen auf Abruf als Entwicklermaschinen. Das hat nichts mit Kosten zu tun. Wir haben einen "Pool von Entwicklern", die an mehreren Projekten arbeiten, und wir müssen in der Lage sein, schnell zwischen Projekten zu wechseln.

Im Allgemeinen spart der VM die anfängliche Einrichtungszeit. Langfristig verschwendet er jedoch Zeit aufgrund von Produktivitätsverlusten. Die Kosten sind keine Achse, da die Entwicklerkosten viel höher sind als die Maschinenkosten.

Zu den Produktivitätskosten gehören - Zeitaufwand für das Starten eines VM-Images (mehrere Minuten)), schlechte Reaktionsfähigkeit und Ressourcen-/Speicherbeschränkungen. Diese sind anfangs nicht viel, werden jedoch mit der Zeit ärgerlich.

Bei einem unserer Projekte haben wir den Code überarbeitet, um die Ersteinrichtung zu vereinfachen und "Code herunterzuladen und Maven auszuführen". Mit dieser Änderung war es für einen neuen Entwickler einfach, mit der Arbeit an dem Projekt zu beginnen - und jetzt verwendet niemand das Amazon VM Image. Wir möchten dies auch für andere Projekte emulieren, aber Bis dahin haben wir unsere ec2-Bilder.

18

Seien Sie hier sehr vorsichtig. Ich wurde kürzlich bei einem Kunden eingesetzt, bei dem jeder in der IT-Abteilung seine VM im Wesentlichen aus demselben Grund hatte - damit er niedrigere PCs auf dem Schreibtisch haben und dann per Fernzugriff in die VM einsteigen und dies tun kann ihre normale Arbeit.

Die Erfahrung dort war nicht schön. Mindestens einmal pro Woche liefen wir aus verschiedenen Gründen extrem langsam. Im Allgemeinen konnten wir feststellen, wann jemand im Team eine Reihe prozessorintensiver SSIS-Pakete ausführte. Sie haben schließlich einige von uns auf verschiedene Server verlegt, was einigen geholfen hat, aber die Leistung war nie richtig.

Ich denke, wenn Sie es tun werden - tun Sie Ihre Sorgfalt in Bezug auf die Serverleistung, Ihre Verarbeitungsanforderungen, die Anzahl der Maschinen, die Sie bedienen werden usw. Es könnte Ihnen etwas Geld sparen, aber wenn es nicht richtig implementiert wird, kann es VIELE verursachen von Kopfschmerzen.

Bitte beachten Sie: Dies ist KEINE Flamme der VM - Architektur - nur eine Warnung für Leute, die sich damit befassen - stellen Sie sicher, dass Sie Ihre Enten vor der Implementierung in einer Reihe haben.

14
Catchops

Die Entwicklung auf virtuellen Maschinen kann recht gut funktionieren, aber nur, wenn sie richtig gemacht wird:

  • Nur weil Sie mit VMs einen einzigen Computer für Ihr gesamtes Team haben können und nicht einen pro Entwickler, bedeutet dies nicht, dass dies eine gute Idee ist
  • Für einen Neustart sollte kein Support-Ticket mit einer Reaktionszeit von 24 Stunden geöffnet werden
  • Entwicklungs-VMs sollten sich nicht in einem Rechenzentrum befinden, das 5000 Meilen von den Entwicklern entfernt ist.
  • VMs können zwar von Entwicklern verwaltet und daher nicht unterstützt werden, dies bedeutet jedoch nicht, dass sie nicht auf Netzwerkdienste wie die Quellcodeverwaltung zugreifen können sollten.
  • Die Remotedesktopverbindung sollte Standard sein, nicht ein benutzerdefiniertes "Hochsicherheits" -Applet, das Anführungszeichen in Umlaute konvertiert.
  • Das Abrufen eines neuen VM) oder das Wiederherstellen eines vorhandenen sollte Minuten und nicht Wochen dauern

Ich habe all diese Probleme gesehen und arbeite nicht besonders gerne damit. Ich habe jedoch auch ein VM Setup zu Hause, das ich nach Wahl verwende. Dieses läuft schneller als eine lokale Installation und ermöglicht Dinge wie separate Umgebungen für verschiedene Projekte und schnelle Neuerstellungen, wenn eine Umgebung instabil wird.

12
Tom Clarkson

Ich arbeite mit VMs, empfehle es jedoch nicht für Ihr Hauptprojekt.

Der Grund, warum ich VMs für die Entwicklung verwende, ist, dass ich ältere Projekte (z. B. VB6, .NET 1.1 usw.) unterstützen muss und meinen Hauptcomputer nicht durch die Installation von VS2003/2005/vb6/usw. verschmutzen möchte ... Es klappt in Ordnung, aber hier und da gibt es zeitweise Probleme.

Darüber hinaus ist die Interaktion langsamer, das Starten/Herunterfahren von VMs dauert eine Weile, sie haben keine nativen UI-Effekte (wie Aero in Win7) usw.

Was auch immer Sie an Geld sparen, das Sie verschwenden und mehr durch den Aufwand, den Sie Ihrem Team auferlegen werden. Außerdem, wie hier erwähnt, keine Unterstützung für mehrere Bildschirme. Ich brauche mindestens 3 Bildschirme, um so produktiv wie möglich zu sein.

9
AngryHacker

Die wichtigste Regel bei der Entwicklung ist, Ihre Entwickler bei Laune zu halten. Sie werden feststellen, dass dies mit Remote-VMs nahezu unmöglich ist. Die Unterstützung für mehrere Monitore ist unvollständig, Netzwerkverzögerungen und Ausfälle sind problematisch und die Kosteneinsparungen sind im Allgemeinen minimal.

Arbeiten Sie sicher an VMs, aber berücksichtigen Sie auch lokale VMs und machen Sie den physischen Computer zu einem lächerlich schnellen Tier.

Ich telearbeite zu 100% und zwischen meinem persönlichen ISP und dem VPN - trotz hoher Zuverlässigkeit - haben sie genug Fehler, die mich verrückt machen würden, wenn ich nicht im Offline-Modus arbeiten könnte.

Im Allgemeinen drehe ich einfach eine Vielzahl von VirtualBox-Bildern hoch und arbeite daraus. Das Kopieren einiger hundert MB über das Kabel ist nicht zu zeitintensiv, wenn Sie auch lokal ein neues benötigen.

8
Jordan

Mein Team hat erfolgreich eine "Slow PC/Fast VM Server" -Konfiguration "implementiert. Für ein Team von 20 Entwicklern hatten wir einen 8-Prozessor mit 256 GB RAM Server verbunden) über Glasfaser zu einem sehr schnellen SAN. Es war teuer, aber billiger, als jedem Entwickler eine Workstation mit ähnlicher Leistung zu geben. Für ein kleines Team (4 Entwickler) bin ich mir nicht sicher, ob Skaleneffekte eintreten und Ihnen tatsächlich etwas sparen würden.

5

VMs für die Entwicklung sind einen Blick wert, aber die finanziellen Kosten sind der falsche Grund.

Dies wurde kurz in Marc Holmes ' Expert .NET Delivery mit NAnt & CruiseControl.net behandelt - kurz das Argument für die Entwicklung auf einem VM ist, dass es jeden Aspekt der Arbeit davon abhält, von der speziellen Konfiguration des Entwicklers abhängig zu werden. Sie nuken Ihre VM zu Beginn jedes Projekts, und es sei denn, Sie benötigen tatsächlich eine bestimmte Werkzeug, es tritt nicht ständig herum. Dies minimiert die Wahrscheinlichkeit, dass Änderungen, die Sie vornehmen, auf einer anderen Maschine als Ihrer brechen. Entwickler könnten weinen, wenn sie ihr Spielzeug wegnehmen - aber letztendlich ist das Vertrauen in Werkzeuge eine Schwäche und alles, was Sie können In einer sauberen Umgebung nicht intuitiv zu tun, ist ein Geruch.

Beachten Sie, dass ich den oben dargestellten Argumenten nicht unbedingt glaube . Ich verstehe sie und stimme bis zu einem gewissen Grad mit ihnen überein, aber ich mache sie aus Gründen der Argumentation, um Diskussionen zu generieren.

5
Tom W

Mögliche Nachteile

  • Wenn der VM Host ausfällt ... bist du alle abgespritzt. Wenn du jemals ein Team von 20 Leuten hattest, schreie "GAH! Host antwortet nicht!" ? "im Einklang ... es macht keinen Spaß.
  • Wenn Sie Schnappschüsse zulassen ... verbrauchen diese schnell Ressourcen. 20 Personen * 10-20 Schnappschüsse sorgen für viel Festplattenspeicher (oder zumindest genug, um Probleme zu verursachen).
  • Wenn Sie erneut Probleme mit der Ressourcennutzung auf dem Host haben, tritt bei jeder der Schmerz auf.

IME, es ist eine gute Lösung und es funktioniert, aber Sie benötigen eine anständige Hardware auf dem Host und wenn schlimme Dinge passieren, passieren sie jedem.

4
Steven Evers

Dies ist eines der wichtigsten Kriterien des Joel-Tests nicht.

Ich stelle sicher, dass alle meine Entwickler mindestens einen i3 oder besseren Laptop oder Desktop mit so viel RAM wie möglich) haben.

Ich strebe 8 GB an.

Dies macht sie produktiver und sie können Virtual Box tatsächlich auf ihren lokalen Computern zum Entwickeln und Testen ausführen, anstatt auf teuren Servern zu warten. Sie können ihre Virtual Box als Schnappschuss installieren, verrückte Dinge installieren und verschiedene Browser und Installationsprogramme sowie alles testen und in Sekunden zu einer bekanntermaßen guten Konfiguration zurückkehren, ohne sich an die "IT" -Dienste wenden zu müssen.

Entwickler benötigen die schnellsten Maschinen im Unternehmen mit den meisten RAM und Root-Berechtigungen auf ihren lokalen Maschinen. Ende der Geschichte.

4
user7519

Ich habe zuvor an VMs für die Entwicklung gearbeitet, sowohl an lokalen VMs (die auf dem lokalen PC ausgeführt werden) als auch an Remote-VMs. Die lokalen waren viel schöner zu arbeiten als die entfernten.

Remote-VMs, mit denen wir über RDP eine Verbindung hergestellt haben, hatten zwischen jedem Tastendruck und jeder Aktion eine geringe Verzögerung. Es ist möglich, sich unter solchen Bedingungen für kurze Zeit zu entwickeln, aber Tag für Tag wurde es sehr frustrierend.

Ich habe mich glücklich unter einem lokalen VM auf VMWare entwickelt), weil ich Flash Builder auf einem Linux-Computer ausführen musste, und war ziemlich zufrieden damit, solange es genügend Speicher hatte - es war ziemlich brauchbar.

4
prunge

Wir machen das für unsere Remote-Maschinen und es funktioniert ziemlich gut. Meistens arbeiten wir von zu Hause aus (normalerweise nur für Notfälle hier und da), daher verwenden wir nur Netbooks mit relativ niedrigem Preis, die auf unseren schnellen Desktop-Computern im Büro entfernt sind. Sie sind definitiv immer noch langsamer (wahrscheinlich mehr als alles andere durch das Netzwerk begrenzt), arbeiten aber ab und zu für kurze Aufgaben. Dies wäre jedoch für ein Vollzeitarbeitspferd wirklich nicht akzeptabel, da VM häufig eine Verzögerung verursachen kann, die selbst mit der besten Hardware, IMHO, etwas ablenkt.

3

Bei meinem letzten Job haben wir genau das gemacht:

Wir haben einen Windows Terminal Server verwendet, auf dem jeder Entwickler ein Konto hatte. Die Entwickler hatten noch normale PCs (weil sie bereits dort waren), aber auf den PCs wurde nur der RDP-Client ausgeführt.

Wir haben Java Entwicklung, also die verwendete Software wo Java Compiler + IDE (meistens Eclipse)) plus Webbrowser, DB-Abfragetools, Versionskontrollclient und gelegentlich Office-SW (in unserem Fall OpenOffice.org).

Wir hatten keine wirklichen Probleme und die Leistung war recht anständig.

Das einzige wirkliche Problem war, dass Sie wirklich darauf achten müssen, andere in bestimmten Situationen nicht zu stören, da Sie ein System gemeinsam nutzen. Wenn IT-Vorgänge große Dateikopien erstellen oder Sicherungen auf dem Server ausführen mussten, wurde die Leistung für alle beeinträchtigt. Als wir dies identifizierten und lösten (durch Kopieren mit niedriger Priorität oder über Nacht), lief alles gut.

Die Einschränkung lautet also: Bewerten Sie die Leistung so schnell wie möglich und planen Sie Ihre Hardware und deren Verwendung entsprechend.

2
sleske

TL; DR : Ich habe es bei mehreren Jobs gemacht und bevorzuge es jetzt.

Kosten sind der falsche Grund, sich darauf zu konzentrieren. Hier sind einige bessere.

Gründe

  • Plattformkonsistenz in den verschiedenen Umgebungen (Entwicklung, Test und Produktion).
    • Warum: Es beseitigt vollständig einen Fehlervektor, Fehler aufgrund von Plattformunterschieden in verschiedenen Umgebungen.
  • Ermöglicht, dass Systemänderungen wie Upgrades zuerst in Entwicklungs-VMs durchgeführt, überprüft, zum Testen aufgerollt, überprüft und in die Produktion übernommen werden. alles viel einfacher mit Entwicklung (und Test) vms.
    • Warum: Kontrolle. Ich kann einen Snapshot erstellen, einen Rollback durchführen, die Deltas identifizieren, die Änderung auf einem Server vornehmen und einen Erfolg verbreiten, indem ich einfach die VM usw. Dupliziere.
  • Manchmal sind die Systeme, gegen die Sie entwickeln, nur in einem gesicherten Netzwerk verfügbar. Alternativ hat der Server, auf dem Ihre Software ausgeführt wird, möglicherweise nur eingeschränkten Zugriff oder andere Netzwerkeigenschaften.
    • Warum: Die Entwicklung VM kann sich auf dem VLAN befinden, das Zugriff auf das gesperrte System oder den gesperrten Dienst hat. Alternativ wenn Der Entwicklungsserver hat denselben eingeschränkten Zugriff wie der Test- und Produktionsserver. Es besteht nie die Frage, ob versehentlich eine Anforderung für ein Netzwerkmerkmal oder ein Zugriff codiert wird, der nicht verfügbar ist.

Herausforderungen

Die größte Herausforderung ist die Remote-Entwicklung, insbesondere wenn Sie ein Gateway oder einen Jump-Server verwenden müssen. Dies macht es schwierig, insbesondere wenn die Entwickler nicht gut gerundet sind (sie verfügen über Systemtechnik-, Netzwerk- usw. Kenntnisse).

Es gibt viele Variationen der Fernentwicklung, aber sie beschränken sich normalerweise auf zwei Hauptunterschiede.

  • Führen Sie Ihre Entwicklungstools in der Remote-Umgebung aus und verwenden Sie Protokolle wie RDP-Clients, Remote-X11-Clients usw.
  • Führen Sie Ihre Entwicklungstools lokal aus und verwenden Sie Protokolle, um sie transparent zu synchronisieren oder auf dem Remote-Server auszuführen. Verwenden Sie häufig ssh als Transportschicht.

Werkzeuge

Es gibt Tools, die bei der Remote-Entwicklung helfen, und IDEs, die dies erleichtern. Sie müssen untersuchen, inwieweit es für die Remoteentwicklung geeignet ist. Viele sind nicht ohne die Ausführung auf demselben Server, auf dem der Code entwickelt wird. Es gibt jedoch andere Tools.

  • Secure Shell : Die meisten erfolgreichen Remoteentwicklungs-Setups verwenden ssh in größerem Umfang, indem sie kennwortlose Anmeldungen (mithilfe der Schlüsselauthentifizierung), transparente Multihops (löst das Problem mit dem Jump-Server) und andere Konfigurationsoptionen verwenden, um die Antwortzeit zu verbessern. Hinweis: Ich hatte immer Probleme mit Nicht-OpenSSH-Implementierungen von SSH.
  • GNU Screen/TMUX : Terminal-Multiplexer. Screen ist der Urvater von ihnen und ist immer noch stark, aber ich denke, die meisten Leute haben angefangen, auf TMUX umzusteigen (oder sogar anzufangen).
  • Vim/Emacs: Die alte Garde, aber beide eignen sich auf unterschiedliche Weise hervorragend für die Fernentwicklung. Es ist Vim, also braucht es nur eine Shell, während Emacs lokal ausgeführt werden und TRAMP für die Remote-Entwicklung verwenden kann.
2
dietbuddha

Hardware ist billig, Programmierer sind teuer.

Warum sollten Ihre Programmierer frustriert sein, wenn sie ihnen langsame Entwicklungsmaschinen geben? Die Kosten für das Upgrade der Hardware verblassen im Vergleich zu den Leistungsvorteilen, die sie erzielen werden.

Fragen Sie nach besseren Maschinen. Fragen Sie mindestens nach 4 GB RAM. Das Hinzufügen einer weiteren 2-GB-Tablette wird in weniger als einer Woche zurückerhalten.

1
Carra

Etwas anders: Haben Sie Ihren Managern/Buchhaltern eine Tabelle gegeben, in der die Kosten für die Verwendung dieser langsamen Maschinen aufgeführt sind? Weisen Sie sie darauf hin, dass eine VM -Lösung (sofern nicht richtig gemacht und nicht einfach)) die Entwickler und damit das Unternehmen einfach in dasselbe Boot setzen könnte.

1
Martijn Verburg

Der Mangel an Dual-Screen-Unterstützung war schon immer der Deal Killer. Ich kann mir einfach nicht vorstellen, bedeutende Entwicklungsarbeiten auf einem einzigen Bildschirm durchzuführen.

Jetzt rocken sie zum Testen/Bereitstellen/Fummeln, also denke ich nicht, dass sie auch vom Stapel fallen sollten.

1
Wyatt Barnett

Dies hängt davon ab, wie viel Verwaltungsleistung Sie über die VMware-Installation haben. Wenn Sie in einen Subpool mit niedriger Priorität versetzt werden, haben Sie abhängig von der Aktivität anderer Subpools langsame Computer.

1
NickJ

Wie von anderen angegeben, hängt es wirklich davon ab, welches Problem Sie mit den VM Desktops lösen möchten, und wägen dann die Vorteile der Lösung dieses Problems gegen die Nachteile ab, die der VM Umgebung entstehen .

Wir bewegen uns in Richtung einer hybriden Umgebung, in der alle unsere Onshore-Entwickler über traditionelle physische Maschinen verfügen, aber Offshore-Entwickler (die derzeit mit einem kleinen Outsourcing-Unternehmen zusammenarbeiten) virtuelle Desktops verwenden. Die Probleme, die wir mit den Remote-Desktops lösen möchten, sind sicherheits- und leistungsbezogen. Die virtuelle Umgebung bietet uns aus Sicherheitsgründen offensichtlich eine bessere Kontrolle. Aus Gründen der Leistung übertragen wir nur "geänderte Pixel" anstelle des vollständigen Quellcodes und müssen Proxyserver und dergleichen implementieren.

Ich bin mir immer noch nicht sicher, ob dies der richtige Weg ist, aber wir gehen dorthin.

0
Ted

Ich glaube nicht, dass Sie sich für eine Remote-Lösung entscheiden möchten VM Lösung. Die Netzwerkverbindung wird der Engpass sein, und selbst bei einer schnellen Verbindung kann dies ausreichen, um Frustration zu verursachen. Wir ziehen weg von dieser Technik bis zur Verwendung lokaler Entwicklungsumgebungen.

Wir entwickeln auf iMacs, was wirklich nett ist, aber unsere Webanwendungen laufen in einer Linux-Umgebung in der Produktion. Das Problem dabei ist, dass wir möglicherweise auf ein Problem stoßen, das nur unter Linux auftritt und möglicherweise nur schwer zu beheben ist. Hier kommt die Leistung virtueller Maschinen ins Spiel. Ich mag jedoch nicht einmal die Idee, in 100% der Fälle eine VM VM) zu verwenden.

Ich habe kürzlich von Vagrant (http://vagrantup.com/docs/getting-started/why.html) und Chef erfahren, weil ich die Arbeit mit VirtualBox sehr einfach gemacht habe. Vagrant gibt Ihnen die Möglichkeit, eine VM, wenn Sie sie benötigen, einfach zu starten und eine VM, wenn Sie dies nicht tun) abzureißen. Also könnte ich alles tun Meine Entwicklung mit meinem Mac. Wenn ich dann bereit bin, meinen Code zu testen, kann ich eine VM, um ihn zu testen, starten und ihn nur so lange behalten, wie ich ihn brauche. Vagrant Außerdem können Sie VMs problemlos für Ihre Mitarbeiter freigeben, sodass Sie alle sicher sein können, dass Sie in derselben Umgebung arbeiten.

Ich würde empfehlen, Vagrant auszuprobieren, damit Sie zumindest über die verfügbaren Optionen für die Entwicklung und Arbeit mit VMs informiert sind.

0
Andrew

Wenn Sie einen Mainframe mit 50 SSD-Festplatten in RAID10 haben und nur 3-4 Computer auf diesem Mainframe verwenden, funktioniert dies möglicherweise.

Ansonsten sind sie verzögert, sehr verzögert (obwohl in einigen seltenen Fällen Schnappschüsse dies ausgleichen können).

0
Coder

Ich habe an einem Legacy-Projekt mit 5 Maschinen gearbeitet, von denen jede eine Rolle in einer Berechnungspipeline spielt (Maschine 1 sendet eine Anfrage an Maschine 2, die wiederum eine Anfrage an Maschine 3 usw. sendet). Die Bereitstellung der Einstellungen auf der virtuellen Maschine hat uns jedoch RIESIGE Zeit gespart: 1. Das System war nicht debuggbar, da Entwickler faul waren/keine Zeit hatten, Tests in das Design einzubeziehen. 2. Es wurden zu viele Setups bereitgestellt, und ich musste Zeit aufwenden, um sie in Gruppen anzuordnen.

Jetzt benutze ich es, weil ich an zu vielen Projekten gleichzeitig arbeite. Das Hauptproblem, das ich jetzt habe, ist: 1. VMs verbrauchen viel zu viel Zeit für die Wartung. 2. VMs verbrauchen enorm viel Speicher, um ausgeführt zu werden

Dadurch werden VMs schwer zu verwenden, wenn Sie versuchen, sie für die Bestellung zu verwenden. Behalten Sie einen Hauptcomputer mit Ihrer E-Mail und Ihrem Text bei und entwickeln Sie ihn auf dedizierten VMs. Hält Ihr Leben ordentlich und sauber zu einem Preis.

0
Henry Aloni

Ich habe einen anständigen Desktop-Computer im Büro, mit dem ich über die Bildschirmfreigabe von meinem Laptop über VPN eine Verbindung herstellen kann.

Es funktioniert für Support-Vorfälle außerhalb der Geschäftszeiten und gelegentliches erzwungenes Remote-Arbeiten. Es ist sicherlich besser, als eine vollständig konfigurierte Umgebung auf einem zweiten Computer zu verwalten oder Dinge zu entwickeln, die eine geringe Latenz zum Rechenzentrum über ein WAN erfordern.

Es ist jedoch frustrierend, lange Zeit so zu arbeiten. Ich bin gelegentlich für die zweite Hälfte des Tages zur Arbeit gefahren, nachdem alles, was mich zu Hause gehalten hat, aus dem Weg geräumt wurde.

Latenz und Bildschirmfläche sind die beiden Killer für mich.

0
Bill Michell