Motivi per utilizzare una VM per lo sviluppo [duplicato]

La latenza è un grande grande No! Uso la VM per test manuali e test automatici, cercando anche di mantenere una VM per fallback (se il sistema principale si interrompe, posso solo accendere e continuare).

IMHO RDP è una pessima idea, gli sviluppatori dovrebbero essere senza problemi e ogni secondo è importante.

Penso che la sola latenza mi farebbe impazzire.

Non menzionare un numero di altri problemi di rete: cosa succede se per qualche motivo non riesci a collegarti alla VM (un router o un collegamento in basso tra te e l'altro, o il server non funziona, o per qualsiasi ragione).

Inoltre, un laptop è molto più portatile.

Nel nostro negozio, il modo in cui lavoriamo è il seguente:

• Visual Studio installato localmente sulla workstation degli sviluppatori.
• VM per ogni sviluppatore, generalmente per ogni client su cui lavorano, eseguendo le applicazioni server (SQL, IIS, CMS / MOSS / Commerce Server / etc).

In genere funziona bene per noi: mappiamo un'unità alla VM sul desktop e lavoriamo localmente, ma contro il file system remoto, ecc.

L'unico vero problema è il debugging: per VS2008 hai bisogno dell'app Remote Debugging in esecuzione sul server e devi collegarti al processo piuttosto che colpire F5.

Non sono sicuro di questi argomenti per utilizzarli:

• Mantengono il codice sorgente "sicuro".

Se hai il controllo del codice sorgente attivo, non importa se una macchina muore, a meno che per "sicuro" significhi "rimanere sulla nostra rete, non venga lasciato su un treno dove chiunque potrebbe trovarlo".

E per quanto riguarda:

• Se vogliamo lavorare da casa, potremmo semplicemente usare i nostri PC di casa

A meno che tu non abbia un grande monitor a casa, lo sviluppo da lì sarà abbastanza doloroso, e se hai una configurazione di monitor di grandi dimensioni, probabilmente hai una macchina con cui eseguire Visual Studio, e quindi il mio modo di lavorare funzionerà da casa: connettiti alla VPN dell'ufficio, mappare un'unità e non ci sei.

Non abbiamo privilegi amministrativi sulla VM e non possiamo modificare le impostazioni secondo le necessità.

Questa è una grande bandiera rossa per me. Non prenderei nemmeno in considerazione la possibilità di lavorare in un'azienda che non concede agli amministratori l'accesso all'amministratore. Il tuo computer aziendale può essere bloccato, ma lo sviluppo spesso richiede il tweaking e la riproduzione delle impostazioni della macchina.

Come affermato da voi e da altri - il problema della "produttività gratuita" da parte delle persone che portano a casa i laptop è un affare fatto - che con la latenza è sufficiente.

In qualità di manager, mi piacerebbe anche mantenere gli sviluppatori felici, se vogliono laptop e nessuna VM per lo sviluppo primario, nessun problema.

VM ha il suo posto - ma IMO non come ambiente di sviluppo primario.

Il più grande argomento che ho sostenuto è che l'uso di una macchina per influenzare negativamente la tua produttività. C'è un motivo per cui noi come sviluppatori abbiamo macchine veloci, monitor doppi, ecc. Anche lavorare su una macchina che manca nella RAM può essere abbastanza brutto da farti "fuori dalla zona" perché devi aspettare che la macchina si riattivi te.

Argomenti specifici che vorrei trattare sono:

They work for TeamVM.

TeamVM ha provato a lavorare in modo non VM e, in tal caso, qual è stata la differenza di produttività?

They keep the source code "safe".

Non sono nemmeno sicuro di quello che pensano i tuoi dirigenti. Si stanno riferendo ad avere il vero codice in natura sul tuo laptop?

If we want to work from home, we could just use our home PCs.

Sicuramente questo renderà il tuo lavoro più suscettibile a furti, virus, ecc. Soprattutto in un ambiente domestico in cui più persone hanno accesso alla tua macchina.

Licenses (I don't know what the argument is, only that it's been used).

Questa è sicuramente un'aringa rossa? Se vogliono che lavori da casa sul PC di casa, dovranno comunque pagare i soldi per le licenze per quelle macchine?

Uso una combinazione dei due, anche se la maggior parte delle mie VM sono in esecuzione sul mio computer locale. La mia posizione predefinita è quella di utilizzare la mia macchina base per le prestazioni e nessuna VM. Tuttavia, a volte è molto più facile svilupparsi contro gli ambienti virtuali. Lo faccio principalmente quando ...

1. Ho bisogno di installare software o servizi particolari che preferirei non avere, o non possedere, sulla macchina base. per esempio. MOSS, Microsoft CRM, Exchange, Oracle, DB / 2, (siamo generalmente una MS house) servizi di terze parti di cui non mi fido o che sono difficili da disinstallare.

2. Devo emulare un ambiente di rete con più macchine, soprattutto se ho bisogno di un controller di dominio o di un server Exchange.

3. Sto testando diverse configurazioni e sistemi operativi.

Uso le macchine virtuali per lo sviluppo, non riesco a modificare il codice tramite VNC / RDP durante il normale flusso di lavoro.

Devo scrivere tre tipi di applicazioni, Linux, Windows e Portable. Quindi, di solito ho una VM Linux e una VM Windows in esecuzione sul mio desktop di sviluppo che mi consente di compilare e testare il lavoro su entrambe le piattaforme. Certo, quando eseguo il programma tramite RDP o VNC è un po 'confuso quando mi chiedo se la latenza è nell'applicazione, ma se sto usando una VM non sono ancora nella fase in cui mi interessa ancora.

Direi al tuo capo che modificare il codice tramite RDP equivale a provare a bere un milkshake ghiacciato attraverso un ago ipodermico. Capisco la paranoia, ma questa non è la soluzione.

Ho lavorato in un negozio in cui disponevamo di una configurazione VM per lo sviluppo ed era principalmente a causa della complessità della configurazione. In realtà, eseguivamo la VM localmente sui nostri sistemi (questa azienda per qualche motivo continuava a vivere negli anni '90 quando si trattava di workstation per sviluppatori e non aveva neanche un laptop).

Ho finito per costruire il mio ambiente di sviluppo sul mio sistema principale e ha funzionato molto meglio.

Come altri hanno già detto, la latenza e la convenienza sono un grosso inconveniente. Qualcuno al piano di sopra viene presentato, probabilmente da persone IT, quanti risparmi avranno andando seguendo questa rotta. Se hai una parola, vai con un calo del 10% della produttività a causa della latenza e non essere in grado di lavorare in remoto. Il compenso medio totale della squadra è probabilmente da qualche parte intorno a $ 100k conservatori, quindi prendi quel numero di membri della squadra e stai probabilmente guardando dei soldi seri. Per non parlare dei costi di turnover perché perderai tutte le persone "buone" che andranno a lavorare per una startup che "ottiene" e non tenta di lasciare dettare IT ai loro brillanti sviluppatori.

Poiché tutti sembrano concordare sul fatto che la latenza è un grande killer, ecco uno scenario alternativo che abbraccia alcuni dei vantaggi effettivi quando si dispone di una server farm in-house per eseguire le macchine virtuali con una latenza minima o nulla:

1) Velocità. Il server assegna alla mia VM più risorse di quante ne abbia il mio portatile, il che significa che si compila più velocemente, corre più velocemente e la mia produttività accelera.

2) Stabilità. Qualcosa si è rotto? Basta tornare all'ultima istantanea stabile. Ci vogliono circa trenta secondi.

3) Coerenza. Tutte le macchine virtuali sono uguali, un clone dell'ambiente in cui questo codice verrà eventualmente eseguito. Non ci sono strane stranezze legate alla personalizzazione dei computer portatili quando lavoro nella VM.