Reflexões sobre o desenvolvimento usando máquinas virtuais [fechado]

51

Vou trabalhar como líder de desenvolvimento para uma startup e sugeri que usássemos VMs para o desenvolvimento. Não estou falando de cada desenvolvedor ter um desktop com VMs para teste / desenvolvimento, quero dizer, ter um rack de servidor no qual todas as VMs são gerenciadas e fazer com que os desenvolvedores trabalhem a partir de um microPC localmente, ou mesmo remotamente, de um microPC (ChromeOS alguém?) computador.

Para mim, os benefícios são o fato de ser extremamente escalável, mais barato a longo prazo, mais fácil de gerenciar e utilizar o hardware em seu potencial máximo. Quanto aos contras, não consigo pensar em nenhum outro limitador de exibição em particular, além de precisarmos de alguém para configurar / manter essa configuração.

Eu esperava que alguns de vocês tivessem uma configuração semelhante em seu local de trabalho e pudessem ponderar suas opiniões. Obrigado.

J_A_X
fonte
7
Este não é o IBM VM / ESA do seu pai! Todo o caminho de volta ao mainframe da IBM.
Vitor Py
23
O único limitador de exibição para mim seria o suporte a várias telas. Não consegui desenvolver em menos de 2 telas.
Justin Escudo
27
Há muitas razões exóticas: Às vezes, é necessário conectar uma chave USB a um computador físico para fins de licenciamento. Às vezes você está lidando com CDs reais. Às vezes você precisa reiniciar o otário com força. Às vezes, você precisa medir o desempenho como seria em um computador real. Às vezes você está desenvolvendo drivers. Às vezes você precisa de toda a velocidade que conseguir. Às vezes, você precisa demonstrar o produto em algum lugar sem acesso à Internet. Às vezes, você precisa entrar em um sistema usando a validação de impressão digital.
Job
47
Os IDE modernos exigem hardware local dedicado. Antes de sequer pensar em fazer isso, você deve ter uma bancada de testes e um estudo para ver se é viável. Você pode aprender uma coisa ou duas que não sabia sobre como as pessoas interagem com as máquinas. Se você me disser que não tem tempo ou dinheiro para realizar esse estudo, eu lhe direi que você não possui escala suficiente para justificar sua configuração.
Robert Harvey
4
Lembre-se de que você também precisa de máquinas físicas. Nosso servidor de teste está quase todo espalhado pela VM em dois hosts SAN. Mas encontramos problemas nos quais queremos / precisamos verificar se a virtualização não é um fator ou mesmo o culpado. Além disso, nem todas as VMs oferecem suporte a temas com vidro e, se você estiver desenvolvendo GUIs, precisará verificar sua GUI também em um ambiente com temas de vidro.
Marjan Venema

Respostas:

96

O que você espera economizar, como uma fração do orçamento de desenvolvimento? Parece-me que você está preocupado com um epsilon. O custo das máquinas para desenvolvedores é inferior a 5% do custo total para manter um desenvolvedor na equipe. Portanto, a única questão importante é "isso poupará tempo aos desenvolvedores?" Poderia, se eles não precisassem gastar tempo instalando e atualizando o software de desenvolvimento. Ou pode custar tempo, se a rede ficar inativa, ou o servidor ficar inativo, ou, provavelmente, se a capacidade de resposta da rede estiver faltando um pouco. O desenvolvimento moderno depende da interação tecla a tecla com um IDE, ou pelo menos um editor muito inteligente. O atraso dessa interação em até algumas dezenas de milissegundos destrói a produtividade do desenvolvedor. Há também o custo para os desenvolvedores aprenderem essa nova maneira de trabalhar.

Essas não são objeções às VMs, mas objeções em potencial ao desenvolvimento remoto.

kevin cline
fonte
Entendo o seu ponto, mas o servidor será local (mesma sala) que os desenvolvedores. A latência será se eles trabalharem em casa, e essa latência estará lá, não importa se é de uma VM ou se é a própria caixa do desenvolvedor. O orçamento de desenvolvimento inclui não apenas a criação de VMs de desenvolvimento, mas também ambientes de teste. Achei que esse método é muito mais escalável do que cada um com sua própria caixa e mais fácil para suporte. Obrigado pela resposta, porém, isso me fez pensar em outras coisas :)
J_A_X
5
Essa abordagem pode realmente economizar um tempo de manutenção. Mas provavelmente não em escala inicial. Deve haver 20 usuários ou mais para começar a ser financeiramente interessante.
SK-logic
6
Se você localizar o servidor em uma sala de equipamentos, obterá separação ambiental que é melhor para o servidor e as pessoas. O ruído de fundo no escritório é reduzido e o calor pode ser melhor gerenciado.
mattnz
11
@J_A_X: Essa latência não existiria quando se trabalha em casa se as máquinas forem laptops. A latência da rede através da VPN certamente estaria lá, mas a latência de interação com a própria máquina não estaria.
Adam Robinson
11
@J_A_X: a latência não existe se todo o ambiente de desenvolvimento estiver contido no laptop do desenvolvedor. E ainda pode haver latência perceptível pressionando as atualizações da tela pela sala, quando a interação ocorre a cada pressionamento de tecla. O atraso de 50 milissegundos no eco do caractere seria muito doloroso. Talvez tudo corra bem, mas vale a pena descobrir?
kevin Cline
58

Acho que você está sendo tolo e insensato.

Primeiro de tudo, os custos da máquina são triviais em comparação com o custo de um desenvolvedor. Você deve trabalhar para maximizar a produtividade, não para minimizar o custo da máquina.

Segundo, a latência (não a largura de banda) é a chave para muitas tarefas de programação - especialmente a edição de texto. Para cada dólar / libra / euro que você economiza em máquinas para seus desenvolvedores, você gasta pelo menos dez em atualizações de rede para manter uma aparência de produtividade - e mesmo assim, eles provavelmente seriam mais produtivos se você economizasse fornecendo eles com Pentium III que você encontrou em uma lixeira em algum lugar.

Também acho que há um benefício substancial em fazer com que seus desenvolvedores usem um ambiente pelo menos razoavelmente próximo do esperado do usuário final de destino. Independentemente dos alvos oficiais de desempenho em uma especificação e tal, a maioria dos programadores baseia-se bastante em como o código "se sente" quando o testam. Quando eles estão usando um ambiente completamente diferente do usuário final, eles provavelmente perdem tempo com trivialidades enquanto ignoram completamente os principais problemas.

Por mais atraente que um ambiente homogêneo pareça do ponto de vista de suporte, você geralmente deve incentivar o máximo de variedade possível nas máquinas dos desenvolvedores. Os desenvolvedores raramente precisam de muito suporte de qualquer maneira, e saber imediatamente quando você tem código que falhará com um chip gráfico, CPU, adaptador de rede etc. mais do que paga o investimento mínimo.

Conclusão: se você está escrevendo um código que se destina (pelo menos principalmente) a ser usado em um ambiente de servidor virtualizado, você precisa fornecer isso aos seus desenvolvedores. Se você estiver fazendo isso de qualquer maneira para teste, também pode (mas não necessariamente) fazer sentido para o desenvolvimento. Da mesma forma, se você precisar (ou pelo menos tiver) de um servidor e rede severamente superespecificados, pode fazer sentido tirar vantagem disso usando o que você já tem disponível.

Sob circunstâncias mais típicas, no entanto, parece-me que é provável que isso introduza mais problemas do que resolve.

Jerry Coffin
fonte
4
Eu sei que não foi feito para ser levado a sério, mas eu absolutamente levar um ambiente virtual decente sobre alguma "Pentium III é você encontrado em um algum lugar lixo"
Davy8
Não não não. Não incentive tanta variedade entre as máquinas de desenvolvimento. Se você precisar desenvolver o hardware, faça-o corretamente, usando um conjunto de caixas de teste que representam o hardware no qual você precisa executar o software. Você nunca encoraja desvios aleatórios de hardware em suas máquinas de desenvolvimento individuais, é a pior prática de desenvolvimento de software .
precisa saber é
19

Essa foi uma das minhas idéias no passado: ter um servidor de alto desempenho com todo o software necessário e vários PCs de mesa de baixo desempenho que seriam usados ​​apenas para conectar-se ao servidor através da Área de Trabalho Remota.

Os benefícios seriam:

  • O backup sólido. Alguns desenvolvedores podem não querer fazer backup de seus computadores desktop regularmente, portanto, uma solução central seria mais confiável,
  • A possibilidade, para todo desenvolvedor, de trabalhar de qualquer lugar. Por isso, quero dizer também trabalhar em qualquer PC da empresa. Digamos que de manhã, o desenvolvedor queira condições de trabalho silenciosas. Ele vai para o seu próprio quarto e trabalha lá. Então ele quer fazer uma programação em pares ou trabalhar em um ambiente mais social. Ele simplesmente desliga o PC de mesa, vai para outra sala onde há dez computadores e se conecta a partir daí. Não "Preciso recarregar todos os meus aplicativos novamente".

Bem, existem vários problemas sérios com isso, fazendo-me pensar que nunca usarei algo assim nos próximos anos.

  • Especificidade de soluções remotas. Que tal trabalhar à distância usando várias telas de computador ao mesmo tempo? Quero dizer, é fácil? Isso é óbvio? Os atalhos que uso diariamente estão ativados ao trabalhar à distância? Eu não tenho tanta certeza. E se eu pressionar Ctrl + Shift + Esc para ver a lista de programas em execução no momento? Ah, sim, não funciona, então agora devo me lembrar de fazê-lo de uma maneira diferente.

  • Desempenho atingido. Não tenho certeza de que não haverá redução no desempenho. E lembre-se, um programador que usa um computador lento é um programador infeliz. E a empresa que deixa seus programadores descontentes com condições ruins nunca produzirá software de alta qualidade.

  • Maior impacto de um desastre. Você hospedará a solução em um servidor redundante? Você tem rede redundante em sua empresa? Digamos que o roteador desligue e não seja redundante. Isso significa que todos os desenvolvedores agora não podem trabalhar. Em absoluto. Porque eles não têm software instalado localmente. Porque eles nem têm código-fonte: está no servidor. Então todo mundo para e você está pagando todas essas pessoas por hora apenas para esperar a substituição do roteador.

  • Custos de hardware. Se for um único servidor, quanto custará? Se você tiver, digamos, vinte desenvolvedores, 64 GB de RAM no servidor seriam suficientes? Não tão certo. A solução quad-core com duas CPUs seria suficiente? Mais uma vez, tenho algumas dúvidas. Caso contrário, o que você pensa? Algum tipo de nuvem? Ou você tem uma solução escalável que funciona em vários servidores? Você está pronto para pagar o custo do Windows Server (se você usa o Windows) por máquina?

  • Custo de eletricidade. Se você trabalha remotamente, significa que você gasta quase a mesma quantidade de energia do lado do servidor como se estivesse trabalhando localmente, mais a quantidade de energia desperdiçada pela máquina local e pela rede.

  • Licenças. Não tenho certeza se devo colocá-lo como um benefício ou um problema, mas sinto que o custo do licenciamento de software nesse caso será muito maior.

E, novamente, pense em todos os custos de gerenciamento, suporte, implantação, manutenção. Com uma solução personalizada como essa, ela pode facilmente se tornar enorme, sem contar que toda vez que algo falhar, você verá todos os desenvolvedores por aí, esperando para poder continuar seu trabalho.

Arseni Mourzenko
fonte
Se o servidor estiver inativo, você perderá tudo. A menos que você replicar esse servidor também ...
Rudy
4
@Rudy: Na maioria das lojas, se o servidor cair, você também não pode trabalhar localmente (sem acesso ao banco de dados para testes, sem check-ins, sem check-out, sem acesso a rastreamento de bugs, sem e-mail, ...)
sleske
4
@sleske concordou com DB, e-mail e outras coisas, mas com DVCS você pode pelo menos check-in / agência / ...
MBX
A maioria das lojas, especialmente uma que pensa em usar VMs em um rack para hospedar ambientes de desenvolvimento, teria servidores separados para banco de dados, email etc. Além disso, mesmo que alguns desses serviços ocorram, você ainda terá acesso à área de trabalho local e ao que quer que tenha acontecido estar trabalhando no momento.
Pete
@sleske - Existe hoje um mecanismo de banco de dados que não possa ser executado na estação de trabalho de um desenvolvedor?
kevin Cline
18

Usamos instâncias do Amazon EC2 sob demanda como máquinas de desenvolvimento. Isso não tem nada a ver com custo. Temos um "pool de desenvolvedores" trabalhando em vários projetos e precisamos da capacidade de avançar rapidamente entre os projetos.

Em geral, a VM economiza tempo de configuração inicial. Mas a longo prazo, perde tempo devido à perda de produtividade. O custo não é um eixo, porque o custo do desenvolvedor é muito maior que o custo da máquina.

Os custos de produtividade incluem - tempo gasto para iniciar uma imagem de VM (vários minutos), capacidade de resposta ruim e restrições de recursos / memória. Inicialmente, essas não são muitas, mas com o tempo elas se tornam irritantes.

Em um de nossos projetos, refatoramos o código para simplificar a configuração inicial para "baixar código e executar o maven". Com essa mudança, era simples para um novo desenvolvedor começar a trabalhar no projeto - e agora ninguém usa a imagem da VM da amazon. Também queremos imitar isso em outros projetos, mas isso levará tempo. Até lá, temos nossas imagens ec2.

Sripathi Krishnan
fonte
14

Tenha muito cuidado aqui. Recentemente, fui implantado em um cliente em que todos os funcionários do departamento de TI tinham sua VM essencialmente pelo mesmo motivo - para permitir que eles tivessem PCs mais baixos na mesa e depois se conectarem remotamente à VM e fizessem seu trabalho normal.

A experiência não foi bonita. Pelo menos uma vez por semana, estávamos correndo muito devagar por vários motivos. Geralmente, podíamos saber quando alguém da equipe estava executando um conjunto de pacotes SSIS com uso intensivo de processador. Eles acabaram transferindo alguns de nós para servidores diferentes, o que ajudou alguns, mas o desempenho nunca foi bom.

Eu acho que se você for fazer isso - faça sua devida diligência na energia do servidor, suas necessidades de processamento, quantas máquinas você servirá, etc. Isso poderia economizar algum dinheiro, mas se não for implementado corretamente, pode causar MUITOS de dores de cabeça.

Observe: isso NÃO é uma chama da arquitetura da VM - apenas um aviso para as pessoas que estão olhando para ela - verifique se você tem seus patos seguidos antes da implementação.

Catchops
fonte
11
+1 Faça sua lição de casa! O cara que fez isso na minha última empresa teve experiência e saiu sem problemas. Foi o melhor sistema que já usei para desenvolvimento, mas levou a maior parte de um ano para projetar e implementar.
Christopher Bibbs
12

O desenvolvimento em máquinas virtuais pode funcionar muito bem, mas apenas se bem:

  • Só porque o uso de VMs permite que você tenha um único computador para toda a equipe, em vez de um por desenvolvedor, não significa que é uma boa ideia
  • A reinicialização não deve exigir a abertura de um tíquete de suporte com um tempo de resposta de 24 horas
  • As VMs de desenvolvimento não devem estar em um datacenter a 5.000 milhas de distância dos desenvolvedores.
  • Embora as VMs possam ser gerenciadas por desenvolvedores e, portanto, sem suporte, isso não significa que elas não possam acessar serviços de rede, como controle de origem.
  • A conexão da área de trabalho remota deve ser padrão, não um applet personalizado de "alta segurança" que converte as aspas digitadas em trema.
  • Obter uma nova VM ou reconstruir uma existente deve levar minutos, não semanas

Eu já vi todos esses problemas e não gosto muito de trabalhar com eles. No entanto, também tenho uma configuração de VM em casa que uso por opção. Isso é executado mais rapidamente do que uma instalação local faria e permite coisas como ambientes separados para diferentes projetos e recriações rápidas quando um ambiente se torna instável.

Tom Clarkson
fonte
9

Trabalho com VMs, mas não o recomendo para o seu projeto principal.

O motivo de eu usar VMs para desenvolvimento é porque tenho que dar suporte a projetos legados (por exemplo, VB6, .NET 1.1, etc ...) e não quero sujar minha máquina principal, tendo que instalar o VS2003 / 2005 / vb6 / etc ... Funciona bem, mas há problemas intermitentes aqui e ali.

Além disso, a interação é mais lenta, as VMs demoram um pouco para iniciar / desligar, não têm efeitos de interface do usuário nativos (como o Aero no Win7), etc.

Tudo o que você vai economizar em termos de dinheiro, você desperdiçará e muito mais com o aborrecimento que está prestes a impor à sua equipe. Além disso, como alguém mencionado aqui, não há suporte para várias telas. Preciso de pelo menos três telas para ser o mais produtivo possível.

AngryHacker
fonte
Eu uso o VMWare Workstation para desenvolvimento em três monitores.
JC01
8

A regra número 1 do desenvolvimento é manter seus desenvolvedores felizes. Você achará isso quase impossível de fazer com VMs remotas. O suporte a vários monitores é irregular, o atraso e os blips da rede são problemáticos e a economia de custos é geralmente mínima.

Trabalhe em VMs, claro, mas permita também VMs locais e faça do computador físico um animal ridiculamente rápido também.

Eu telecomuto 100% e entre o meu ISP pessoal e a VPN - apesar da alta confiabilidade - eles têm blips suficientes que me deixariam maluco se eu não pudesse trabalhar no modo offline.

Geralmente, apenas giro uma variedade de imagens do VirtualBox e trabalho com elas. A cópia de algumas centenas de MBs por cabo não exige muito tempo, se você precisar de um novo localmente também.

Jordânia
fonte
5

Minha equipe implementou com êxito uma configuração de "servidor lento para PC / VM rápida". Para uma equipe de 20 desenvolvedores, tínhamos um servidor de 8 processadores e 256 GB de RAM conectado via fibra a uma SAN muito rápida. Era caro, mas mais barato do que fornecer a cada desenvolvedor uma estação de trabalho com desempenho semelhante. Para uma equipe pequena (4 desenvolvedores), não tenho certeza de que as economias de escala aumentariam e realmente salvariam qualquer coisa.

Christopher Bibbs
fonte
11
Você encontrou problemas em outras VMs quando alguém começou a compilar um projeto grande ou executou outras tarefas que exigem muitos recursos?
TheLQ
@TheLQ Sem problemas, mas o cara que projetou o sistema o havia feito anteriormente, portanto o hardware foi selecionado e ajustado apenas para esta tarefa. A última vez que perguntei a ele, ele disse que os processadores sempre estavam ociosos, mas os discos giravam como loucos.
Christopher Bibbs
então um disco san estava no limite com 8 desenvolvedores - o que você diria para ~ 20? quantos san exigimos para essa tarefa?
Toskan
11
@Toskan Não, tínhamos 20 desenvolvedores e 8 CPUs no servidor. Quanto ao número de discos, acredito que nossa SAN tenha 12 discos, mas não tenho certeza.
Christopher Bibbs
5

Vale a pena examinar as VMs para desenvolvimento, mas o custo financeiro é o motivo errado .

Isso foi abordado brevemente no Expert .NET Delivery de Marc Holmes usando o NAnt & CruiseControl.net - em suma, o argumento para o desenvolvimento em uma VM é que desencoraja qualquer aspecto do trabalho de se tornar dependente da configuração específica do desenvolvedor. Você monitora sua VM no início de cada projeto e, a menos que você realmente precise de uma ferramenta específica, ela não fica por aí. Isso minimiza a probabilidade de que as alterações feitas sejam interrompidas na máquina de qualquer pessoa, exceto a sua. Os desenvolvedores podem chorar por ter seus brinquedos levados - mas, em última análise, confiar em ferramentas é uma fraqueza e tudo o que você não pode fazer intuitivamente em um ambiente limpo é um cheiro.

Note que eu não acredito necessariamente nos argumentos apresentados acima. Eu entendo e até certo ponto me alinhar com eles, mas estou fazendo-os por causa de argumentos, para gerar discussão.

Tom W
fonte
7
É por isso que você tem um mecanismo de construção - a integração contínua deve capturar essas dependências. Os desenvolvedores, no entanto, precisam de todas as ferramentas que podem obter.
4
Sim - não leve meus brinquedos embora. Eles me tornam produtivo para fazer as coisas. Construir para implantação e testar em um ambiente de destino são problemas diferentes a serem resolvidos.
quickly_now
Uma opção é desenvolver scripts de configuração que copiem seus aliases, arquivos de configuração e outros arquivos de instalação. Por exemplo, no Linux, tenho um alias configurado para extrair todas essas coisas do git.
Michael Durrant
4

Desvantagens potenciais

  • Se o host da VM ficar inoperante ... você estará todo hospedado. Se você já teve uma equipe de 20 pessoas gritando "GAH! NÃO RESPONDEM !?" em uníssono ... não é divertido.
  • Se você está permitindo fotos instantâneas ... elas consomem recursos rapidamente. 20 pessoas * 10 a 20 instantâneos, cada um deles ocupa muito espaço no disco rígido (ou pelo menos o suficiente para começar a causar problemas).
  • Se você encontrar problemas com o uso de recursos no host, novamente, todos experimentarão a dor.

IME, é uma boa solução e funciona, mas você precisa de um hardware decente no host e quando coisas ruins acontecem, elas acontecem a todos.

Steven Evers
fonte
4

Isso falha em um dos critérios mais importantes do teste de Joel.

Certifico-me de que todos os meus desenvolvedores tenham pelo menos um laptop ou desktop i3 ou melhor com tanta memória RAM quanto possível.

8 GB é o que eu me esforço.

Isso os torna mais produtivos e eles podem realmente executar o Virtual Box em suas máquinas locais para desenvolvimento e teste, em vez de manter servidores caros. Eles podem capturar instantaneamente sua Virtual Box, instalar coisas malucas e testar diferentes navegadores e instaladores e tudo mais e em segundos voltar a uma configuração boa conhecida sem a necessidade de entrar em contato com os serviços de "TI".

Os desenvolvedores precisam das máquinas mais rápidas da empresa, com mais permissões de RAM e root em suas máquinas locais. Fim da história.


fonte
4

Eu trabalhei em VMs antes para desenvolvimento, tanto VMs locais (em execução no PC local) quanto remotas. Os locais eram muito mais agradáveis ​​de se trabalhar do que os remotos.

As VMs remotas, às quais estávamos conectando pelo RDP, apresentavam um pequeno atraso entre cada pressionamento de tecla e ação. É possível desenvolver sob tais condições por um curto período de tempo, mas dia após dia se tornou muito frustrante.

Felizmente, desenvolvi-me em uma VM local no VMWare porque precisava executar o Flash Builder em uma máquina Linux e fiquei muito feliz com isso desde que tivesse memória suficiente - era bastante utilizável.

prunge
fonte
Só tenho que acrescentar que você precisa de uma CPU com Nested Page Tables (2.Gen Virtualization Support) para obter um bom desempenho. Usando VM Ware com trajetos compartilhados é bastante lento quando você não tem SSDs (leva> 20seg para git addou git statusem repo com 7k arquivos)
mbx
3

Fazemos isso para nossas máquinas remotas e funciona bastante bem. Raramente trabalhamos em casa (normalmente apenas para uma correção de emergência aqui e ali); portanto, usamos apenas netbooks de baixo custo, remotados em nossas rápidas máquinas de escritório no escritório. Eles definitivamente ainda são mais lentos (provavelmente limitados pela rede mais do que qualquer coisa), mas trabalham para tarefas curtas de vez em quando. Isso realmente não seria aceitável para um cavalo de trabalho em tempo integral, no entanto, uma vez que a VM pode frequentemente causar um pouco de atraso que mesmo com o melhor hardware, IMHO, é um pouco perturbador.

Morgan Herlocker
fonte
2

No meu último trabalho, fizemos exatamente isso:

Usamos um Windows Terminal Server, onde cada desenvolvedor tinha uma conta. Os desenvolvedores ainda tinham PCs regulares (porque eles já estavam lá), mas os PCs executavam apenas o cliente RDP.

Fizemos o desenvolvimento do Java, portanto, o software usado no local onde compilador Java + IDE (principalmente Eclipse), além de navegador da Web, ferramentas de consulta de banco de dados, cliente de controle de versão e ocasionalmente office sw (OpenOffice.org no nosso caso).

Não encontramos nenhum problema real e o desempenho foi bastante decente.

O único problema real era que você realmente precisa tomar cuidado para não atrapalhar os outros em algumas situações, porque está compartilhando um sistema. Quando as operações de TI precisavam fazer cópias grandes de arquivos ou executar backups no servidor, o desempenho diminuía para todos. Quando identificamos e resolvemos isso (copiando com baixa prioridade ou durante a noite), tudo teve um bom desempenho.

Portanto, a ressalva é: avalie o desempenho o mais rápido possível e planeje seu hardware e seu uso de acordo.

sleske
fonte
Os desenvolvedores podem instalar software nessas contas? Às vezes, o Eclipse não é a ferramenta para o trabalho.
Kevin cline
@ Kevin Cline: Sim, a instalação do sw foi permitida e possível. No entanto, os desenvolvedores não tinham direitos de administrador, portanto, você só podia instalar o SW que não exigisse direitos de administrador para instalar ou executar. Eu poderia instalar tudo o que precisava sem problemas, mas ouvi dizer que ainda existem aplicativos por aí que precisam de direitos de administrador para instalar ou apenas executar.
sleske
@sleske Na minha experiência, os desenvolvedores devem ter direitos de administrador em suas máquinas de desenvolvimento, virtuais ou não. Na minha opinião, um desenvolvedor precisa se apropriar das ferramentas que eles usam e a máquina de desenvolvimento é apenas outra ferramenta.
Manfred
@ John: Isso realmente depende das ferramentas que você precisa. Se nenhuma das suas ferramentas precisar de acesso de administrador, você não precisará de acesso de administrador. Não vejo por que você sempre precisa de acesso de administrador. Obviamente, se você precisar fazer coisas como instalar drivers de dispositivo ou executar coisas na porta 80, precisará de acesso de administrador.
Novelas
2

TL; DR: Eu fiz isso em vários trabalhos e agora prefiro.

O custo é o motivo errado para focar. Aqui estão alguns melhores.

Razões

  • Consistência da plataforma nos diferentes ambientes (desenvolvimento, teste e produção).
    • Motivo: elimina completamente um vetor de defeito, defeitos de diferenças de plataforma em diferentes ambientes.
  • Permite que alterações do sistema, como atualizações, ocorram primeiro nos vms de desenvolvimento, sejam verificadas, acumulem para testar, verifiquem e entrem em produção; tudo muito mais fácil com o desenvolvimento (e teste) vms.
    • Por que: Controle. Posso capturar instantâneos, reverter, identificar os deltas, fazer as alterações em um servidor e propagar um sucesso simplesmente duplicando a VM, etc.
  • Às vezes, os sistemas contra os quais você desenvolve estão disponíveis apenas em uma rede segura. Como alternativa, o servidor em que o software será executado pode ter apenas acesso limitado ou características de rede diferentes.
    • Por que: A VM de desenvolvimento pode estar na VLAN que tem acesso ao sistema ou serviço bloqueado. Como alternativa, se o servidor de desenvolvimento tiver o mesmo acesso limitado que o servidor de teste e produção, nunca haverá a questão de codificar acidentalmente um requisito em uma característica de rede ou acesso que não estará disponível.

Desafios

O desafio número um é o desenvolvimento remoto, especialmente se você precisar passar por um gateway ou servidor de salto. Isso dificulta, especialmente se os desenvolvedores não são bem-arredondados (eles têm algum conhecimento de engenharia de sistema, conhecimento de rede, etc.).

Existem muitas variações de desenvolvimento remoto, mas elas geralmente se resumem a duas diferenças principais.

  • Execute suas ferramentas de desenvolvimento no ambiente remoto e use protocolos como clientes RDP, clientes X11 remotos etc.
  • Execute suas ferramentas de desenvolvimento localmente e use protocolos para sincronizar ou executar de forma transparente no servidor remoto, geralmente usando ssh como a camada de transporte.

Ferramentas

Existem ferramentas que ajudarão no desenvolvimento remoto e existem IDEs que o facilitam. Você precisará investigar até que ponto ele é capaz de desenvolvimento remoto; muitos não ficam sem rodar no mesmo servidor em que o código está sendo desenvolvido. No entanto, existem outras ferramentas.

  • Shell Seguro: As configurações de desenvolvimento remoto mais bem-sucedidas usam ssh em maior grau, usando logins sem senha (usando autenticação de chave), multi-saltos transparentes (resolve o problema do servidor de salto) e outras opções de configuração para melhorar o tempo de resposta. Nota: Eu sempre tive problemas ao usar implementações não-OpenSSH do SSH.
  • GNU Screen / TMUX: Multiplexadores de terminal. A tela é o avô deles e ainda está forte, mas acho que a maioria das pessoas começou a mudar (ou até começar) no TMUX.
  • Vim / Emacs : A velha guarda, mas ambos funcionam muito bem para o desenvolvimento remoto de maneiras diferentes. É o Vim, então tudo o que precisa é de um shell, enquanto o Emacs pode ser executado localmente e usar o TRAMP para desenvolvimento remoto.
dietbuddha
fonte
1

Em uma abordagem um pouco diferente - você forneceu aos seus gerentes / contadores uma planilha destacando o custo do uso dessas máquinas lentas? Saliente para eles que uma solução de VM (a menos que seja feita da maneira correta e que não seja fácil) pode simplesmente colocar os desenvolvedores e, portanto, a empresa no mesmo barco.

Martijn Verburg
fonte
1

Isso dependerá da quantidade de energia administrativa que você possui sobre a instalação do VMware. Se você colocar um subconjunto de baixa prioridade, terá máquinas lentas, dependendo da atividade de outros subconjuntos.

NickJ
fonte
1

O hardware é barato, os programadores são caros.

Por que você deseja que seus programadores fiquem frustrados, dando a eles máquinas de desenvolvimento lento? O custo da atualização do hardware diminui em comparação com os benefícios de desempenho que eles obterão.

Peça máquinas melhores. No mínimo, peça 4 GB de RAM. A adição de outro tablet de 2GB será recuperada em menos de uma semana.

Carra
fonte
problema é que as janelas de 32 bits que está instalado no cadernos
Toskan
1

A falta de suporte para tela dupla sempre foi a causa da morte. Não consigo imaginar um trabalho de desenvolvimento significativo em uma única tela.

Agora, eles são ótimos para testar / implantar / mexer, então não acho que devam cair da pilha também.

Wyatt Barnett
fonte
O RDP suporta vários monitores na versão mais recente.
Andrew Lewis
splitview.com/...
Andrew Lewis
Eu pensei que estávamos falando sobre VMs, não RDP aqui. . .
Wyatt Barnett
Desculpe, eu estava me referindo a VMs remotas. Você pode executar vários monitores com o VMWare Workstation 7+
Andrew Lewis
Eu acho que depende do tamanho do monitor.
Manfred
0

Se você tiver um mainframe com 50 discos SSD no RAID10 e usar apenas 3-4 máquinas nesse mainframe, ele poderá funcionar.

Caso contrário, eles estão atrasados, realmente atrasados ​​(embora, em alguns casos raros, o instantâneo possa compensar isso).

Codificador
fonte
0

Eu tenho uma máquina de desktop decente no escritório à qual posso me conectar do meu laptop por VPN usando o compartilhamento de tela.

Ele funciona para incidentes de suporte fora de horas e ocasionalmente trabalho remoto forçado. Certamente é melhor do que manter um ambiente totalmente configurado em uma segunda máquina ou desenvolver coisas que precisam de baixa latência para o datacenter em uma WAN.

No entanto, é frustrante trabalhar dessa maneira por longos períodos. Ocasionalmente, fui trabalhar para a segunda metade do dia, uma vez que tudo o que me mantinha em casa foi tirado do caminho.

Latência e imóveis de tela são os dois assassinos para mim.

Bill Michell
fonte
0

Eu não acho que você queira usar uma solução de VM remota. A conexão de rede será o gargalo e, mesmo em uma conexão rápida, pode ser suficiente para causar frustração. Estamos nos afastando dessa técnica para o uso de ambientes de desenvolvimento local.

Desenvolvemos no iMacs, o que é muito bom, mas nossos aplicativos da Web estão sendo executados em um ambiente Linux na Produção. O problema é que, eventualmente, podemos encontrar um problema que só acontece no Linux e pode ser difícil de solucionar. É aí que entra o poder das máquinas virtuais. No entanto, eu nem gosto da idéia de usar uma VM 100% do tempo.

Recentemente, aprendi sobre o Vagrant (http://vagrantup.com/docs/getting-started/why.html) e o Chef por tornar o trabalho com o VirtualBox super fácil. O Vagrant oferece a capacidade de iniciar facilmente uma VM quando você precisar e derrubar uma VM quando não for necessário. Para que eu pudesse fazer todo o meu desenvolvimento usando meu Mac. Então, quando estiver pronto para testar meu código, eu posso iniciar uma VM para testá-lo e mantê-lo apenas enquanto eu precisar. O Vagrant também permite compartilhar facilmente VMs com seus colegas de trabalho, para que todos possam ter certeza de que estão trabalhando no mesmo ambiente.

Eu recomendaria verificar o Vagrant para que você tenha pelo menos conhecimento das opções disponíveis quando se trata de desenvolver e trabalhar com VMs.

Andrew
fonte
0

Eu tenho trabalhado em um projeto legado referente a 5 máquinas, cada uma delas tendo um papel em um pipeline de computação (a máquina 1 envia solicitação para a máquina 2, e por sua vez envia a solicitação para a máquina 3, etc.). A implantação da configuração na máquina virtual nos poupou MUITO tempo: 1. O sistema não podia ser comprado porque os desenvolvedores eram preguiçosos / não tinham tempo para incorporar os testes no design. 2. Muitas configurações foram implantadas e eu precisava gastar tempo organizando-as em grupos.

Agora eu uso porque trabalho em muitos projetos ao mesmo tempo. O principal problema que tenho agora é: 1. As VMs estão consumindo muito tempo para manter. 2. As VMs estão consumindo enormes quantidades de memória para executar

Isso torna as VMs difíceis de usar quando você tenta usá-las para ter ordem. Mantenha uma máquina principal com seu e-mail e texto, desenvolva em VMs dedicadas. Mantém sua vida arrumada e limpa a um custo.

Henry Aloni
fonte
0

Conforme declarado por outros, realmente depende do problema que você está tentando resolver com os desktops da VM e, em seguida, avalia os benefícios de resolver esse problema contra as desvantagens que o ambiente da VM terá.

Estamos caminhando para um ambiente híbrido, onde todos os nossos desenvolvedores onshore terão máquinas físicas tradicionais, mas os desenvolvedores externos (trabalhando com uma pequena empresa de terceirização no momento) usarão desktops virtuais. Os problemas que estamos tentando resolver com os desktops remotos estão relacionados à segurança e ao desempenho. O ambiente virtual obviamente nos proporcionará maior controle do ponto de vista da segurança e, para o desempenho, transferiremos apenas "pixels alterados" em vez do código fonte completo e teremos que implementar servidores proxy e tal.

Ainda não tenho certeza se este é o caminho certo a seguir, mas é para onde estamos indo.

Ted
fonte