Una macchina di sviluppo dovrebbe essere all'interno di una VM? [chiuso]

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

Ottenere il ciclo interno del code-compile-test per essere il più veloce possibile richiede le migliori macchine possibili - la compilazione e l'esecuzione di test ovviamente funzionano più velocemente su macchine con più core, in quanto tali attività possono essere facilmente eseguite in un modo concorrente *.

Fino a quando i sistemi operativi di sviluppo mainstream non saranno in grado di gestire il numero di core disponibili e finché il software di virtualizzazione non offrirà in modo intelligente un tipo di contratto "fino a N core", le macchine di sviluppo virtualizzate non offriranno lo stesso tipo di rendimento di produttività fisico dispositivi.

EDIT: questo appena racconta i miei sentimenti personali sullo sviluppo utilizzando VM aziendali dettate, che sono spesso proibite per tagliare i costi hardware, che tendono ad essere eseguiti sui server. L'esecuzione di una VM locale sembra in gran parte superflua se si applica una buona disciplina di controllo del codice sorgente, a meno che il progetto non richieda specificamente lo sviluppo di codice per più SO.

*: con il quale intendo le attività secondarie all'interno degli stadi di compilazione e le fasi di test possono essere eseguite contemporaneamente, NON compilando e testando contemporaneamente:)

Faccio tutto il mio sviluppo personale nelle macchine virtuali. Ho diverse configurazioni VM per ambienti diversi e funziona perfettamente.

Ho un laptop dell studio 15 (quad i7 2.8ghz, 8gb ram, ati graphics) con win 7 ultimate 64bit con virtualbox installato. Ho tutte le mie macchine virtuali in esecuzione su un'unità USB esterna da 500 GB velcrata al laptop.

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

VM 1 - Win 7 64 bit (2 cpu, 4gb ram, 120gb hd) con il set di strumenti Visual Studio 2008

VM 2 - Win 7 64 bit (2 cpu, 4gb ram, 120gb hd) con il set di strumenti Visual Studio 2010

VM 3 - Win 7 64 bit (2 cpu, 2gb ram, 120gb hd) con il set di strumenti Java Eclipse

A meno che non stia facendo qualcosa che richiede un IO molto alto, ho sentito che le prestazioni sono buone e non saprei di essere all'interno di una VM se qualcuno mi avesse appena consegnato il portatile e ha 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 dispositivi periferici USB diversi (ad esempio webcam, stampanti di 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 dei dispositivi di terze parti.

Come ho detto, non penso che questa situazione giustifichi NON lavorare su macchine di sviluppo virutalizzate, ma è una cosa che non abbiamo ancora capito, quindi manteniamo le workstation fisiche per diversi ambienti in un laboratorio.

Nella nostra azienda stiamo utilizzando la VM per lo sviluppo e il test. Anche se ci sono alcuni inconvenienti per l'utilizzo di VM, i benefici superano di gran lunga quelli.

Prima di iniziare a utilizzare le macchine virtuali stavamo avendo problemi costanti con l'installazione di macchine di sviluppo per i nuovi sviluppatori. Il primo compito per il nuovo sviluppatore del team era di solito quello di creare una propria macchina di sviluppo. Siamo una piccola azienda e non abbiamo sempre la manodopera necessaria per aiutare i nuovi membri del team a configurare la macchina. Ciò ha portato a numerosi problemi: a volte l'errore era riproducibile solo sulla macchina o viceversa, oppure l'applicazione non poteva essere compilata correttamente ecc. Inoltre, c'era anche il problema che alcuni dei nostri sviluppatori senior lavoravano su più progetti in ambienti di lavoro che non erano sempre compatibili.

Quando siamo passati a VM - tutto è cambiato. Ora solo un ragazzo è responsabile della creazione dell'ambiente in VM con tutto ciò che è collegato al progetto. Quando ha finito, tutti i membri del team ricevono la copia della VM. Ciò riduce il tempo per la configurazione dell'ambiente per ogni nuovo membro del team (la copia della VM non può richiedere più di 2 ore). Ci consente anche di lavorare su più ambienti di lavoro.

Gli svantaggi dell'utilizzo di VM: SPEED. Sì, il risultato della prestazione sulla VM è visibile. Nelle stazioni di lavoro lente può rendere quasi impossibile lo sviluppo. Ma se hai una buona workstation (quad core, 8 + GB RAM, SSD) puoi lavorare normalmente (sto lavorando attualmente su un laptop con 8GB di RAM e processore Core2Duo).

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

• Che aspetto ha il tuo ambiente?
• Hai diritti di accesso sufficienti per lo sviluppo?
• Il tuo HW è in regola?

Ambiente

L'utilizzo di una VM può essere d'aiuto se si sta lavorando su più versioni di un progetto; più progetti; o il targeting di un sistema operativo diverso da quello normalmente eseguito (sistema operativo host). Faccio un sacco di lavoro su SharePoint ed essere in grado di eseguire una macchina diversa per le varie versioni di una versione è utile poiché posso solo avviare una macchina diversa e avere una buona sensazione per lo stato del GAC / database. Inoltre, se hai bisogno di indirizzare un ambiente applicativo * nix ma hai una macchina Windows, puoi ancora fare lo sviluppo in una VM (questo è il modo in cui sto imparando Ruby a casa anche se in genere faccio lavoro con .NET. Sostengo generalmente quando eseguo test di sviluppo / sviluppo di ASP.NET sulla stessa versione di IIS che verrà eseguita in ultima analisi (lo stesso razionale si applica ad altri ambienti di destinazione del server). A seconda della versione del sistema operativo, potrebbero esserci alcune piccole ma importanti differenze. Nota che questo non implica che tu debba codificare su una versione specifica di IIS / OS, ma siamo onesti, davvero, deve davvero lavorare dove lo distribuirai non solo sulla tua macchina locale.

Anche le macchine virtuali (a seconda del software utilizzato) consentono di scattare istantanee dello stato corrente della macchina e / o clonarle. Questo può essere prezioso quando si prototipa qualcosa e non si deve essere preoccupati di ciò che sta accadendo nel tuo GAC / Registro / ecc. Inoltre li ho trovati molto preziosi nella creazione di una demo client prima del tempo. Dato che l'ambiente demo era in una VM, potevo continuare a lavorare fino a mostrare al cliente ciò che avevamo completato perché stavo lavorando su una macchina diversa .

Diritti sufficienti

Questo vale generalmente per le persone che lavorano per un'azienda con un insieme piuttosto rigido di politiche per i diritti di accesso. Se non si è in grado di avere un amministratore senza restrizioni sul proprio computer, questo sarebbe un buon momento per lavorare in una VM. In genere i poteri sono solo preoccupati di bloccare il sistema operativo host, l'ospite può essere completamente aperto (autorizzazioni saggia). Ho incontrato strani problemi con i profili di roaming, i diritti di amministratore danneggiati e l'esecuzione di VS 2010; l'utilizzo di una macchina virtuale mi ha permesso di evitare questi problemi.

Il tuo HW è in regola?

Questo si riduce a quando le tue immagini VM sono su un server e il tuo telecomando in esse OPPURE le esegui localmente. Se si sta eseguendo sul server, probabilmente il problema maggiore è che ci sono troppe VM in esecuzione sullo stesso hardware. A livello locale, fondamentalmente si vuole molta RAM e per ridurre al minimo la frequenza di sovraccarico del buffer R / W per il proprio disco rigido. Per lo sviluppo LOB / SharePoint / ASP.NET di base ho scoperto che almeno un minimo di 8 GB di RAM e una configurazione dual hard drive funzionano in pratica (eseguendo un i5 ma ho anche lavorato con un Core 2). Il secondo disco rigido fa la più grande differenza di prestazioni.

Nota: non ho statistiche 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 ho lavorato con esso. Non sarei sorpreso se si utilizzasse Virtual PC (come incursione iniziale nell'uso di VM) per gli sviluppatori jaded sull'uso del software di virtualizzazione.

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

La mia esperienza personale: ho un iMac di fine 2009, e ho scoperto che Visual Studio 2010 è praticamente 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 si disattiva e passa a fuoco apparentemente in modo casuale. Ho appena finito con il Boot Camp.

Ovviamente, un mio nuovo progetto coinvolgerà un'applicazione iOS con uno strumento di configurazione basato su Windows, quindi potrebbe essere troppo doloroso non usare la virtualizzazione, ma se la tecnologia di virtualizzazione desktop non è andata abbastanza avanti nell'ultimo anno o così, probabilmente installerò un altro desktop qui.

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

Ho usato VM per lo sviluppo e in generale non è tremendamente diverso dallo sviluppo sulla mia macchina. Se stai utilizzando 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 un computer di sviluppo, quindi non è così grande se viaggi o lavori molto da casa. Inoltre non ho mai capito come eseguire più monitor su Desktop remoto, ma sono sicuro che questo è il mio fallimento piuttosto che un problema con il principio. Di solito usavo 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 si sta lavorando in un modo in cui è necessario controllare il codice funziona su piattaforme diverse, in particolare roba come lo sviluppo di programmi di installazione, quindi essere in grado di eseguire VM per diverse versioni del SO è incredibilmente utile.

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

Alcuni dei ragazzi hanno bruciato l'installazione del software beta, e alcune delle beta della MS non possono essere rimosse, quindi sono state costrette a usare virtuals fino a quando non hanno riformattato i loro dischi rigidi.

Per lo sviluppo in virtuals, il mio consiglio è di ottenere qualcosa con un minimo di 8GB di RAM. 16 o più sarebbero migliori, in quanto troverai qualsiasi studio virtuale dotato di esigenze reali di circa 1,5 GB di RAM dell'host per funzionare a velocità superiori a "glaciale". Inoltre, procurati un sacco di dischi rigidi quando acquisti un computer. Per le unità che scegli dalla tua pila di hardware di ricambio, cerca quelle almeno due volte le dimensioni del VHD che eseguirai.