Uma máquina de desenvolvimento deve estar dentro de uma VM? [fechadas]

Este post de Rob Conery (observe a lesma) diz que o ambiente de desenvolvimento deve ser executado dentro de uma máquina virtual. Entendo o que ele está dizendo e tendem a concordar, mas ainda me sinto um pouco desconfortável. Agora que a virtualização está tão madura que até os sistemas de produção executados na velocidade das VMs não são um problema, mas como eu digo, algo me incomoda aqui.

Qual é a sua opinião sobre virtualizar sua máquina de desenvolvimento? Você já fez isso? Se você fez, alguma armadilha ou truques ao longo da estrada?

Minha experiência no desenvolvimento de VMs em um ambiente corporativo é que, devido à virtualização de vários núcleos estar cheia de dificuldades, é difícil obter o tipo de desempenho que muitas máquinas de desenvolvimento corporativo precisam.

Conseguir que o loop interno de teste de compilação de código seja o mais rápido possível requer as melhores máquinas possíveis - a compilação e a execução de testes obviamente são executadas mais rapidamente em máquinas com mais núcleos, pois essas atividades podem ser facilmente executadas de maneira simultânea * .

Até que os SOs de desenvolvimento dominantes possam lidar com o número de núcleos disponíveis sendo voláteis, e até que o software de virtualização possa oferecer inteligentemente algum tipo de contrato "até N core", as máquinas de desenvolvimento virtualizadas não oferecerão o mesmo tipo de retorno de produtividade que os dispositivos físicos.

EDIT: Isso apenas relata meus sentimentos pessoais ao desenvolver o uso de VMs ditadas pela empresa, que são geralmente proibidas para reduzir custos de hardware, que tendem a ser executados em servidores. A execução de uma VM local parece na maior parte supérflua, desde que você esteja aplicando uma boa disciplina de controle de origem, a menos que seu projeto exija especificamente que você desenvolva código para vários sistemas operacionais.

*: com o que quero dizer, as subtarefas dentro dos estágios de compilação e de teste podem ser executadas simultaneamente, NÃO compilando e testando simultaneamente :)

Eu faço todo o meu desenvolvimento pessoal em VMs. Eu tenho várias VMs configuradas para ambientes diferentes e funciona bem.

Eu tenho um laptop dell studio 15 (quad I7 2.8ghz, 8gb ram, gráficos ati) rodando win 7 ultimate 64bit com virtualbox instalado. Eu tenho todas as minhas VMs executando em um drive USB externo de 500GB com velcro no laptop.

VM 0 - Instalação limpa do Win 7 64bit como modelo base

VM 1 - Win 7 64bit (2 cpu, 4gb ram, 120gb hd) com o conjunto de ferramentas do Visual Studio 2008

VM 2 - Win 7 de 64 bits (2 cpu, 4 gb de ram, 120 gb de hd) com o conjunto de ferramentas do Visual Studio 2010

VM 3 - Win 7 de 64 bits (2 cpu, 2 gb de ram, 120 gb de hd) com o conjunto de ferramentas Eclipse Java

A menos que esteja fazendo algo que exija IO muito alto, sinto que o desempenho é bom e não saberia que estou dentro de uma VM se alguém tivesse me entregado o laptop e dito começar a desenvolver.

Eu gostaria de acrescentar que certos tipos de desenvolvimento são muito mais difíceis (se não impossíveis) por meio de máquinas virtualizadas.

Por acaso, trabalho em uma empresa onde oferecemos pacotes de software que se integram a vários dispositivos periféricos USB diferentes (por exemplo, webcams, impressoras de etiquetas, leitores de tarja magnética, etc ...). Mesmo se eu fosse mapear portas USB para um servidor virtualizado, notei problemas bizarros e inexplicáveis ​​com os drivers de dispositivos de terceiros.

Como eu disse, não acho que essa situação justifique NÃO funcionar em máquinas de desenvolvimento virutalizadas, no entanto, é uma que ainda não descobrimos, portanto, mantemos estações de trabalho físicas para diferentes ambientes em um laboratório.

Em nossa empresa, agora estamos usando a VM para desenvolvimento e teste. Embora existam algumas desvantagens em usar as VMs, seus benefícios as superam significativamente.

Antes de começarmos a usar as VMs, tivemos problemas com a configuração de máquinas de desenvolvimento para novos desenvolvedores. A primeira tarefa do novo desenvolvedor da equipe era geralmente configurar sua própria máquina de desenvolvimento. Somos uma empresa pequena e nem sempre temos mão de obra para ajudar os novos membros da equipe a instalar sua máquina. Isso levou a problemas diferentes: às vezes o bug era reproduzível apenas na máquina ou eles não podiam reproduzi-lo, o aplicativo não era capaz de criar corretamente etc. Também havia um problema de alguns de nossos desenvolvedores seniores estarem trabalhando em vários projetos em ambientes de trabalho que nem sempre eram compatíveis.

Quando mudamos para VMs, tudo mudou. Agora, apenas uma pessoa é responsável por configurar o ambiente em uma VM com tudo o que está relacionado ao projeto. Quando ele termina, todos os membros da equipe recebem a cópia da VM. Isso reduz o tempo para configurar o ambiente para cada novo membro da equipe (a cópia da VM não deve demorar mais de uma hora). Também nos permite trabalhar em vários ambientes de trabalho em paralelo.

As desvantagens do uso de VMs: velocidade. O desempenho atingido na VM é visível. Em estações de trabalho mais lentas, isso pode tornar o desenvolvimento quase impossível. Se você possui uma boa estação de trabalho (quad core, 8 + GB de RAM, SSD), provavelmente não notará.

Como outros já mencionaram, depende de várias coisas:

• Como é o seu ambiente?
• Você tem direitos de acesso suficientes para desenvolver?
• Seu HW está pronto para o rapé?

Meio Ambiente

Usar uma VM pode ajudar se você estiver trabalhando em várias versões de um projeto; múltiplos projetos; ou segmentar um SO diferente daquele que você normalmente executa (SO host). Faço muito trabalho do SharePoint e poder executar uma máquina diferente para as várias versões de uma versão é útil, pois posso iniciar uma máquina diferente e ter uma boa noção do estado do GAC / banco de dados. Além disso, se você precisar direcionar um ambiente de aplicativo * nix, mas possuir uma máquina Windows, ainda poderá fazer o desenvolvimento em uma VM (é assim que estou aprendendo Ruby em casa, mesmo que eu geralmente faça o trabalho de desenvolvimento .NET). Geralmente, defendo ao testar / desenvolver o desenvolvimento do ASP.NET na mesma versão do IIS em que o aplicativo será executado (o mesmo racional se aplica a outros ambientes de destino do servidor). Dependendo da versão do sistema operacional, pode haver algumas diferenças pequenas, mas críticas. Observe que isso não implica que você deva codificar para uma versão específica do IIS / OS, mas, sejamos honestos, ele realmente tem que funcionar onde você a implantará, não apenas na sua máquina local.

As VMs também (dependendo do software usado) permitem tirar instantâneos do estado atual da máquina e / ou cloná-los. Isso pode ser inestimável na criação de protótipos de alguma coisa e você não precisa se preocupar tanto com o que está acontecendo no seu GAC / Registro / etc. Como o ambiente de demonstração estava em uma VM, eu poderia continuar trabalhando até o ponto de mostrar ao cliente o que concluímos porque estava trabalhando em uma máquina diferente .

Direitos suficientes

Isso geralmente se aplica a pessoas que trabalham para uma empresa com um conjunto bastante rígido de políticas para direitos de acesso. Se você não conseguir ter um administrador sem restrições em sua máquina, seria um bom momento para trabalhar em uma VM. Normalmente, os poderes estão preocupados apenas em bloquear o sistema operacional do host, o convidado pode estar aberto (permissões). Eu tive problemas estranhos com perfis de roaming, direitos de administrador inválidos e execução do VS 2010; usar uma VM me permitiu evitar esses problemas.

Seu HW está pronto para o rapé?

Isso se resume a suas imagens de VM em um servidor e seu controle remoto nelas OU você as executa localmente. Se você estiver executando no servidor, a maior preocupação provavelmente será a existência de muitas VMs em execução no mesmo hardware. Localmente, você basicamente quer muita RAM e para minimizar a frequência com que sobrecarrega o buffer R / W do seu disco rígido. Para o desenvolvimento básico de LOB / SharePoint / ASP.NET, descobri que um mínimo de 8 GB de RAM e uma configuração de disco rígido duplo funcionam muito bem na prática (executando um i5, mas também trabalhei com um Core 2). O segundo disco rígido faz a maior diferença no desempenho.

Nota: Não tenho estatísticas para fazer backup disso, mas notei que o Virtual PC tem uma tendência a ter um desempenho inferior ao VMWare e ao Virtual Box. Não posso falar com o Hyper-V, pois não trabalhei com ele. Eu não ficaria surpreso se o uso do Virtual PC (como uma incursão inicial no uso de VMs) forçou o desenvolvedor a usar software de virtualização.

Como sempre: depende. Por exemplo, eu certamente não o recomendaria para nenhum desenvolvimento relacionado a jogos em tempo real ou em computador.

Minha experiência pessoal: Eu tenho um iMac do final de 2009 e descobri que o Visual Studio 2010 é basicamente inutilizável no Parallels Desktop, a ponto de pressionar uma tecla no editor de código levar alguns segundos para se registrar. O Windows no SQL Server Management Studio desfocaria e alternaria o foco aparentemente aleatoriamente. Acabei indo para o campo de treinamento.

Obviamente, um novo projeto meu envolverá um aplicativo iOS com uma ferramenta de configuração baseada no Windows; portanto, pode ser muito doloroso não usar a virtualização, mas se a tecnologia de virtualização de desktops não tiver se adiantado o suficiente no último ano, Provavelmente vou configurar outra área de trabalho aqui.

Quando se trata de testar um aplicativo de servidor, essa é uma situação diferente. Estou perfeitamente feliz em virtualizar isso, mas preciso de capacidade de resposta nos meus aplicativos de desenvolvimento.

Eu usei VMs para desenvolvimento e, em geral, não é tremendamente diferente de desenvolver em minha própria máquina. Se você estiver usando o Controle de origem corretamente, não haverá muitas diferenças.

As principais diferenças são que, se você está offline por algum motivo, não possui uma máquina de desenvolvimento disponível, portanto, não é tão bom se você viaja ou trabalha muito em casa. Também nunca descobri como executar vários monitores na Área de Trabalho Remota, mas tenho certeza de que é minha falha e não um problema com o princípio. Normalmente, eu usava meu monitor principal para desenvolvimento e mantinha o segundo da minha máquina desktop com email, navegadores e assim por diante.

Acrescentarei que, se você estiver trabalhando de uma maneira em que precisa verificar se o seu código funciona em diferentes plataformas - especialmente coisas como o desenvolvimento de instaladores -, então, é possível executar VMs para diferentes versões do sistema operacional.

Eu os usei na empresa anterior. Vários controles de terceiros não coexistiram bem com outras versões da mesma empresa. Também usei alguns para testar e depurar outros sistemas operacionais (XP vs Vista vs 7). Um virtual tinha VB6 e VS2003 para os produtos mais antigos. Sim, na máquina de um desenvolvedor típico, pode ser lento e complicado, mas eu tinha alguns discos rígidos sobressalentes que "doei" e coloquei os virtuais em seus próprios discos rígidos em seus próprios controladores. Eu fui o último a continuar usando virtuals e, para alguns erros, somente eu poderia trabalhar neles (devido a problemas de sistema operacional e componentes).

Alguns dos caras se cansaram de instalar o software beta, e alguns dos betas da MS não puderam ser removidos; portanto, eles foram forçados a usar virtuais até reformatarem seus discos rígidos.

Para desenvolver em virtuais, meu conselho é obter algo com um mínimo de 8 GB de RAM. 16 ou mais seria melhor, pois você encontrará qualquer necessidade virtual equipada com estúdio visual de cerca de 1,5 GB de RAM do host para rodar em velocidades acima do "glacial". Além disso, obtenha muitos discos rígidos ao comprar um computador. Para unidades que você escolhe da sua pilha de hardware sobressalente, procure por aquelas com pelo menos o dobro do tamanho do VHD em execução.