Servidor de desenvolvimento vs desenvolvimento local

Nos dois últimos projetos em que trabalhei, as equipes preferem um ambiente de desenvolvimento local em vez de um servidor de desenvolvimento.

O líder do projeto afirmou que o local era melhor, pois não requeria conexão à Internet. Mas, isso parece assumido no desenvolvimento.

Qual é geralmente melhor?

Os benefícios da execução local é que você pode trabalhar sem influenciar / dificultar outras pessoas. Os benefícios de um servidor de desenvolvimento central é que você pode testar como suas alterações influenciam e interagem com as outras que estão fazendo enquanto estão sendo feitas.
Idealmente, você quer ter os dois. Desenvolva e execute seus testes de unidade localmente para que você possa isolar suas alterações até se sentir confortável com elas, depois integre-as no servidor da equipe para poder verificar a integração das alterações antes que as coisas cheguem aos sistemas de teste.

Outro benefício de um servidor local no seu laptop é que você pode trabalhar remotamente, onde não tem acesso à rede da empresa e, portanto, não pode acessar o servidor de desenvolvimento.

Na verdade, existem 3 opções:

Desenvolvimento local

• vantagens:
  • fácil de trabalhar com a maioria das ferramentas de desenvolvimento
  • não há necessidade de conexão com a internet
  • não afetando outros desenvolvedores
• desvantagens:
  • depende do SO subjacente
  • pode ser necessário executar todos os tipos de serviços de servidor em sua máquina local
  • ambiente pode ser bem diferente da produção

Máquina virtual local

• vantagens:
  • bastante fácil de trabalhar com a maioria das ferramentas de desenvolvimento, desde que você configure corretamente o compartilhamento de pastas
  • não há necessidade de conexão com a internet
  • não afetando outros desenvolvedores
  • ambiente pode ser praticamente idêntico à produção
  • serviços do servidor iniciados / parados na máquina virtual
• desvantagens:
  • um pouco mais de recursos necessários (principalmente quantidade de RAM, a CPU não é um problema com o suporte moderno à virtualização de hardware).
  • algumas ferramentas de depuração local que se conectariam diretamente ao servidor não funcionarão

Servidor de desenvolvimento compartilhado

• vantagens:
  • ambiente pode ser praticamente idêntico à produção
  • serviços de servidor no servidor
• desvantagens:
  • acesso remoto
  • mudanças que afetam outros desenvolvedores
  • depuração muito mais difícil (usando ferramentas remotas ou logs)

Solução ideal

Use qualquer uma das opções de desenvolvimento local e envie para o servidor de desenvolvimento compartilhado depois de concluir parte independente do recurso e verificar se seu código não está completamente quebrado.

Seu ambiente de desenvolvimento realmente depende de como seu departamento / empresa de TI é organizado e executado. Em geral, embora o ambiente de desenvolvimento fechado corresponda ao do ambiente de produção, melhor.

Se, por exemplo, você está desenvolvendo aplicativos de desktop independentes que não requerem acesso à Internet, é claro que um ambiente de desenvolvimento local é aceitável.

Por outro lado, se você estiver desenvolvendo um aplicativo de desktop que exija comunicação com um servidor / banco de dados remoto etc. e não tenha conexão de rede para simular isso no trabalho, poderá encontrar erros adicionais na produção devido à latência da rede e problemas de segurança.

Se você estiver desenvolvendo um aplicativo de Internet / Nuvem, enquanto precisar da Internet para desenvolver o aplicativo, precisará de acesso para testar e verificar.

Aliás, você não precisa de uma conexão com a Internet para ter um servidor de desenvolvimento apenas uma conexão de rede local.

Faz ambos,

Desenvolvimento local até que o seu trabalho seja concluído e testado.

Envie para o servidor compartilhado no final do dia e execute testes de integração para garantir que você não quebrou nada.

Por quê?

• É mais rápido codificar localmente. Menos etapas entre testes, menos preocupações de integração.

• O isolamento de falhas é mais fácil quando algo quebra somente depois que você o envia ao servidor compartilhado. Você sabe que ele funciona bem localmente, portanto deve ter algo a ver com a forma como se integra ao servidor compartilhado. Se você trabalhou diretamente no servidor compartilhado, seria especialmente difícil diminuir erros.

Eu faria algo assim:

Depois que cada pessoa envia as alterações no final do dia, todos os testes de integração são executados e, se algum deles falhar, você sabe exatamente quem foi o código que foi quebrado no projeto. Reverta as alterações, conserte o problema localmente, tente empurrá-lo novamente, repita até que todos os testes passem e depois para a próxima pessoa.

Depende muito de como você entrega seus projetos. Alguns argumentos para ter um ambiente de desenvolvimento central podem ser:

Controle de qualidade: até onde você quer ir nos testes? Os ambientes locais de desenvolvimento têm restrições nos recursos de teste. Os ambientes de teste virtual são mais adequados para testes de carga e testes de sistema automatizados.

A infraestrutura central pode ajudar a reduzir o ciclo de entrega de teste de desenvolvimento. Implementando assim uma entrega contínua.

Benefícios adicionais do servidor de desenvolvimento central podem ser controle de origem, gerenciamento de tarefas, builds centrais, ..