Una macchina di sviluppo dovrebbe trovarsi all'interno di una macchina virtuale? [chiuso]

Questo post di Rob Conery (nota la lumaca) dice che l'ambiente di sviluppo dovrebbe essere eseguito all'interno di una macchina virtuale. Vedo quello che sta dicendo e tendo ad essere d'accordo, ma mi sento ancora un po 'a disagio. Ora che la virtualizzazione è così matura che persino i sistemi di produzione che funzionano alla velocità delle macchine virtuali sono praticamente un problema, ma come ho detto qualcosa mi disturba qui.

Qual è la tua opinione sulla virtualizzazione della tua macchina di sviluppo? L'hai già fatto? In caso affermativo, insidie ​​o problemi lungo la strada?

La mia esperienza con lo sviluppo su VM in un ambiente aziendale è che a causa della virtualizzazione di più core con difficoltà, è difficile ottenere il tipo di prestazioni di cui hanno bisogno molte macchine di sviluppo aziendale.

Far sì che il ciclo interno di test di compilazione del codice sia il più veloce possibile richiede le migliori macchine possibili: la compilazione e l'esecuzione dei test ovviamente funzionano più velocemente su macchine con più core, poiché tali attività possono essere eseguite abbastanza facilmente in modo simultaneo * .

Fino a quando i sistemi operativi di sviluppo tradizionali non saranno in grado di gestire la volatilità del numero di core disponibili e finché il software di virtualizzazione non sarà in grado di offrire in modo intelligente un tipo di contratto "fino a N core", le macchine di sviluppo virtualizzate non offriranno lo stesso tipo di rendimenti di produttività dei dispositivi fisici.

EDIT: Questo racconta solo i miei sentimenti personali sullo sviluppo utilizzando macchine virtuali dettate dall'azienda, che sono spesso vietate per ridurre i costi hardware, che tendono a funzionare sui server. L'esecuzione di una VM locale sembra per lo più superflua, purché si applichi una buona disciplina del controllo del codice sorgente, a meno che il progetto non richieda espressamente lo sviluppo di codice per più sistemi operativi.

*: con questo intendo le attività secondarie all'interno delle fasi di compilazione e fasi di test possono essere eseguite contemporaneamente, NON compilando e test contemporaneamente :)

Faccio tutto il mio sviluppo personale nelle macchine virtuali. Ho diverse macchine virtuali configurate per ambienti diversi e funziona bene.

Ho un laptop dell studio 15 (quad I7 2.8ghz, 8 gb di ram, grafica ati) con Win 7 Ultimate a 64 bit con VirtualBox installato. Ho tutte le mie VM in esecuzione su un'unità USB esterna da 500 GB velcroed sul laptop.

VM 0 - Win 7 64 bit clean install come modello di base

VM 1 - Vinci 7 64 bit (2 CPU, 4 GB di RAM, 120 GB di HD) con il set di strumenti di Visual Studio 2008

VM 2: Vinci 7 64 bit (2 CPU, 4 GB di RAM, 120 GB di HD) con il set di strumenti di Visual Studio 2010

VM 3: Vinci 7 64 bit (2 CPU, 2 GB di RAM, 120 GB di HD) con il set di strumenti Java di Eclipse

A meno che non stia facendo qualcosa che richiede un IO molto elevato, ho sentito che le prestazioni sono buone e non saprei di essere all'interno di una VM se qualcuno mi avesse appena passato il laptop e mi avesse detto di iniziare a sviluppare.

Vorrei aggiungere che alcuni tipi di sviluppo sono molto più difficili (se non impossibili) attraverso macchine virtualizzate.

Mi capita di lavorare in un'azienda in cui offriamo pacchetti software che si integrano con una serie di periferiche USB diverse (ad es. Webcam, stampanti per etichette, lettori di bande magnetiche, ecc ...). Anche se dovessi mappare le porte USB su un server virtualizzato, ho notato problemi bizzarri e inspiegabili con i driver di dispositivo del fornitore di terze parti.

Come ho detto, non credo che questa situazione NON meriti di lavorare su macchine di sviluppo virutalizzate, tuttavia è una che non abbiamo ancora capito, quindi manteniamo stazioni di lavoro fisiche per diversi ambienti in un laboratorio.

Nella nostra azienda ora stiamo usando la VM per lo sviluppo e il testing. Sebbene vi siano alcuni inconvenienti nell'uso delle VM, i loro vantaggi sono significativamente superiori.

Prima di iniziare a utilizzare le macchine virtuali, abbiamo riscontrato problemi con l'impostazione di macchine di sviluppo per i nuovi sviluppatori. Il primo compito per il nuovo sviluppatore nel team era di solito impostare la propria macchina di sviluppo. Siamo una piccola azienda e non abbiamo sempre la forza lavoro per aiutare i nuovi membri del team a configurare la propria macchina. Ciò ha portato a diversi problemi: a volte il bug era riproducibile solo sulla propria macchina o non era in grado di riprodurlo affatto, l'applicazione non poteva essere costruita correttamente ecc. Inoltre c'era anche un problema che alcuni dei nostri sviluppatori senior stavano lavorando su più progetti in ambienti di lavoro che non erano sempre compatibili.

Quando siamo passati alle macchine virtuali, tutto è cambiato. Ora solo una persona è responsabile della configurazione dell'ambiente in una macchina virtuale con tutto ciò che è correlato al progetto. Al termine, a tutti i membri del team viene fornita la copia della VM. Ciò riduce i tempi di configurazione dell'ambiente per ogni nuovo membro del team (la copia della VM non dovrebbe richiedere più di 1 ora). Inoltre ci consente di lavorare su più ambienti di lavoro in parallelo.

Gli svantaggi dell'utilizzo di macchine virtuali: velocità. L'hit di prestazioni sulla VM è visibile. Su workstation più lente può rendere lo sviluppo quasi impossibile. Se hai una buona workstation (quad core, 8 + GB di RAM, SSD) probabilmente non te ne accorgerai.

Come altri hanno già detto, dipende da diverse cose:

• Che aspetto ha il tuo ambiente?
• Hai diritti di accesso sufficienti per fare lo sviluppo?
• Il tuo HW è all'altezza?

Ambiente

L'uso di una VM può essere d'aiuto se si lavora su più versioni di un progetto; più progetti; o indirizzare un sistema operativo diverso da quello che si esegue normalmente (sistema operativo host). Faccio molto lavoro su SharePoint e poter eseguire una macchina diversa per le varie versioni di una versione è utile poiché posso semplicemente avviare una macchina diversa e avere una buona idea dello stato del GAC / database. Inoltre, se devi indirizzare un ambiente di applicazione * nix ma hai una macchina Windows, puoi comunque fare lo sviluppo in una macchina virtuale (questo è il modo in cui sto imparando Ruby a casa anche se in genere lavoro .NET dev). In genere, quando eseguo test di sviluppo ASP.NET / sviluppo sulla stessa versione di IIS, sostengo che l'app alla fine verrà eseguita (questa stessa logica si applica ad altri ambienti di destinazione del server). A seconda della versione del sistema operativo potrebbero esserci alcune piccole ma critiche differenze. Nota che questo non implica che devi codificare su una versione specifica di IIS / OS, ma siamo sinceri, deve davvero lavorare dove hai intenzione di distribuirlo non solo sul tuo computer locale.

Le macchine virtuali (a seconda del software utilizzato) consentono inoltre di acquisire istantanee dello stato corrente della macchina e / o clonarle. Questo può avere un valore inestimabile durante la prototipazione di qualcosa e non devi preoccuparti di ciò che sta accadendo nel tuo GAC / Registro di sistema / ecc. Li ho anche trovati molto preziosi nell'impostare una demo client in anticipo. Poiché l'ambiente demo era in una macchina virtuale, potevo continuare a lavorare fino al punto di mostrare al client ciò che avevamo completato perché stavo lavorando su una macchina diversa .

Diritti sufficienti

Ciò si applica generalmente alle persone che lavorano per un'azienda con una serie piuttosto rigida di politiche per i diritti di accesso. Se non riesci ad avere un amministratore senza restrizioni sulla tua macchina, sarebbe un buon momento per lavorare in una macchina virtuale. In genere i poteri si preoccupano solo di bloccare il sistema operativo host, l'ospite può essere completamente aperto (per quanto riguarda le autorizzazioni). Ho riscontrato strani problemi con i profili di roaming, i diritti di amministratore paralizzati e l'esecuzione di VS 2010; l'utilizzo di una VM mi ha permesso di evitare questi problemi.

Il tuo HW è all'altezza?

Questo si riduce alle immagini della VM che si trovano su un server e al telecomando in esse OPPURE le esegui localmente. Se si è in esecuzione sul server, probabilmente la maggiore preoccupazione sarà se ci sono troppe VM in esecuzione sullo stesso hardware. A livello locale, vuoi sostanzialmente molta RAM e minimizzare la frequenza con cui sovraccarichi il buffer R / W per il tuo disco rigido. Per lo sviluppo di base LOB / SharePoint / ASP.NET ho scoperto che un minimo di 8 GB di RAM e una configurazione a doppio disco rigido funzionano in pratica bene (eseguendo un i5 ma ho lavorato anche con un Core 2). Il secondo disco rigido fa la differenza più grande in termini di prestazioni.

Nota: non ho alcuna statistica per eseguire il backup ma ho notato che Virtual PC ha una tendenza a sottoperformare rispetto a VMWare e Virtual Box. Non posso parlare con Hyper-V poiché non ci ho lavorato. Non sarei sorpreso se usando Virtual PC (come incursione iniziale nell'uso di VM) lo sviluppatore stanco sull'uso del software di virtualizzazione.

Come al solito: dipende. Ad esempio, certamente non lo consiglierei per qualsiasi sviluppo in tempo reale o relativo ai giochi per computer.

La mia esperienza personale: ho un iMac di fine 2009 e ho scoperto che Visual Studio 2010 è sostanzialmente inutilizzabile in Parallels Desktop, al punto che premere un tasto nell'editor di codice richiede pochi secondi per registrarsi. Windows in SQL Server Management Studio defocus e commuterebbe il focus apparentemente a caso. Ho appena finito con il campo di addestramento.

Naturalmente, un mio nuovo progetto coinvolgerà un'applicazione iOS con uno strumento di configurazione basato su Windows, quindi potrebbe essere troppo doloroso non utilizzare la virtualizzazione, ma se la tecnologia di virtualizzazione desktop non si è spostata abbastanza nell'ultimo anno o giù di lì, Probabilmente ho appena impostato un altro desktop qui.

Quando si tratta di testare un'applicazione server, questa è una situazione diversa, sono perfettamente felice di virtualizzarla, ma ho bisogno di reattività nelle mie applicazioni di sviluppo.

Ho usato macchine virtuali per lo sviluppo e in generale non è tremendamente diverso dallo sviluppo sulla mia macchina. Se stai usando correttamente il controllo del codice sorgente non ci sono molte differenze.

Le differenze principali sono che se sei offline per qualsiasi motivo non hai a disposizione una macchina di sviluppo, quindi non eccezionale se viaggi o lavori molto da casa. Inoltre, non ho mai capito come eseguire più monitor su Desktop remoto, ma sono sicuro che sia il mio fallimento piuttosto che un problema con il principio. Di solito utilizzavo il mio monitor principale per lo sviluppo e mantenevo il secondo per la mia macchina desktop con e-mail, browser e così via.

Aggiungerò che se stai lavorando in un modo in cui devi controllare che il tuo codice funzioni su piattaforme diverse - in particolare cose come lo sviluppo di programmi di installazione - quindi essere in grado di eseguire macchine virtuali per diverse versioni del sistema operativo è incredibilmente utile.

Li ho usati nella compagnia precedente. Numerosi controlli di terze parti non coesistevano bene con altre versioni della stessa società. Ho anche usato un paio per testare ed eseguire il debug di altri sistemi operativi (XP vs Vista vs 7). Un virtuale aveva VB6 e VS2003 per i prodotti più vecchi. Sì, su una macchina tipica di uno sviluppatore può essere lento e ingombrante, ma avevo alcuni dischi rigidi di riserva che ho "donato" e messo i virtuali sui loro dischi rigidi sui loro controller di unità. Sono stato l'ultimo a continuare a usare i virtual e, per alcuni bug, solo io potevo lavorarci su (a causa di problemi con il sistema operativo e i componenti).

Alcuni ragazzi si sono bruciati installando software beta e alcuni beta di MS non sono stati rimossi, quindi sono stati costretti a utilizzare i virtual fino a quando non hanno riformattato i loro dischi rigidi.

Per lo sviluppo in virtual, il mio consiglio è di ottenere qualcosa con un minimo di 8 GB di RAM. 16 o più sarebbe meglio, dal momento che troverai esigenze virtuali equipaggiate con Visual Studio circa 1,5 GB di RAM dell'host per funzionare a velocità superiori a "glaciale". Inoltre, ottieni molti dischi rigidi quando acquisti un computer. Per le unità che scegli dal tuo stack hardware di riserva, cerca quelle che hanno almeno il doppio del disco rigido virtuale che eseguirai.