Configuração do servidor de desenvolvimento interno / externo

Question

Estou tentando evitar o problema de fazer uma suposição e fazer a pergunta errada. Vou descrever a situação em que estou e qual é o problema.

Eu atualmente tenho um servidor de desenvolvimento que executa bancos de dados de desenvolvimento e testes. Os desenvolvedores executam o apache localmente, mas se conectam aos bancos de dados do servidor de teste para que todos estejam na mesma página. Conforme o tempo passou, as responsabilidades desse servidor aumentaram. É frequentemente usado como uma área de teste para que os clientes assinem as alterações. Enquanto isso, o número de clientes e bancos de dados cresceu. Hoje, o servidor de desenvolvimento parou. Essa foi uma interrupção real no fluxo de trabalho atual para a equipe de desenvolvimento.

Uma mistura de tarefas de desenvolvimento ativo e CRON que foram configuradas durante o teste, eventualmente, diminuiu o desempenho do servidor ao ponto de ficar inutilizável. Eu acredito que o acesso ao disco do servidor foi o gargalo.

Pedi atualizações de hardware anteriormente, mas infelizmente elas não foram fornecidas pela gerência. Uma atualização de hardware só faria muito também. Eu estou querendo saber se há uma maneira melhor de alcançar o que queremos e queremos configurar o novo servidor da maneira correta quando ele chegar.

O ideal é que eu goste de um sistema que facilite a "parada" de sites, incluindo o anúncio cron que torna inacessíveis seus URLs temporários, quando eles não estão em desenvolvimento ativo. Igualmente importante é que eu precisaria de uma maneira simples de "iniciá-los" novamente, de preferência por meio de uma interface do usuário, para que nossa equipe não técnica possa fazê-lo.

Eu gosto da ideia de uma solução baseada em docker / vm mas não tenho 100% de certeza de como manteria isso. O maior obstáculo para usar algo assim é provavelmente que eu não tenho certeza de como eu poderia configurá-los para uso como um ambiente de teste.

    

Answer 1

Você poderia atribuir a cada projeto de teste sua própria porta alta para usar em vez da porta SQL normal e encaminhar essas portas para o servidor SQL real em 1433 (ou onde quer que esteja). Então você poderia apenas controlar o encaminhamento de porta. Você poderia fazer o mesmo com portas HTTP.

Eles podem ser encaminhados no próprio servidor (com iptables ou firewalld) ou nos clientes (com firewalls, tunelamento ssh ou qualquer coisa que eles possam usar em suas plataformas).

Se isso fosse feito no lado do cliente, você não precisaria dar a todos os desenvolvedores acesso root no servidor para ativar suas portas novamente. Outro benefício seria que, se o servidor se tornasse totalmente inutilizável devido a muita carga, você ainda poderia desativar o encaminhamento de portas em clientes até que a carga se tornasse mais gerenciável e você pudesse acessar o servidor novamente.

    

Answer 2

Isolar o desenvolvimento do teste de aceitação do usuário seria útil. Algumas maneiras de fazer isso.

Divida os recursos em VMs dev e uat separadas. Mover-se do dev para o uat só é feito quando outro desenvolvedor assina que não elimina o desempenho ou seria de outra forma terrível.

Faça com que os desenvolvedores executem suas próprias alterações em suas próprias estações de trabalho. Tem ferramentas de implantação que podem ativar VMs com uma cópia local do banco de dados de preparo e sua revisão de código. Depois que essa ramificação for mesclada, continue com o teste integrado no sistema de migração de dados / uat.