Como configurar multi usuários no servidor dev com git e github

Question

Estou trabalhando no aplicativo da lâmpada. Nós temos 2 servidores (Debian) Live e Dev.

Eu constantemente trabalho em dev main para adicionar novos recursos e corrigir bugs.
Quando feliz tudo funciona bem eu scp o código relevante para o sistema Live. Banco de dados (mysql) é local para cada máquina.

Agora esta é uma configuração bem básica e eu quero melhorar o fluxo de trabalho um pouco. Eu uso git e github para controle de versão. Admito que eu realmente só usei um ramo. Seus podem ser 3 desenvolvedores diferentes que trabalham no código em momentos diferentes. Todos nós usamos o mesmo nome de usuário linux para conectar ao servidor dev e editar o código diretamente quando necessário. Eu costumo então enviar e empurrar o código no final do dia para o github.

Uma coisa a se ter em mente é que não é fácil executar esse código em uma máquina local, pois há muitas configurações de subdomínio e de subdomínio que não funcionariam em uma máquina local, por isso é importante trabalhar no servidor de desenvolvimento. não localmente.

Eu preciso criar um novo processo porque precisamos ter um tronco principal agora e uma ramificação com uma grande reescrita de código.

Qual é a melhor maneira de fazer isso? Devo criar logins unix diferentes para cada desenvolvedor e configurar diferentes áreas de trabalho no servidor de desenvolvimento para as alterações? por exemplo.

/ var / www / mysite_derek / var / www / mysite_paul / var / www / mysite_mike

meu pensamento é que eles podem fazer um pull do branch principal e então criar seu próprio branch e mesclá-lo de volta. Eu não tenho certeza de como isso funcionará com o git local e com o github.

também precisarei criar diferentes contas de usuário do github.

Eu gostaria de fazer isso da maneira certa e futura para ter muitos desenvolvedores em potencial, mas também não quero complicar demais. Eu solução simples e elegante é o preferido.

alguma recomendação ou sugestão?

    

Answer 1

Uma solução que usamos com cerca de 12 desenvolvedores é a seguinte. Funciona muito bem e contribui para uma configuração flexível sem precisar modificar a configuração do servidor. Provavelmente não será dimensionado para 40-50 devs devido à latência da rede e à velocidade do armazenamento do servidor.

Compartilhamos a árvore / var / www / via Samba, para que os clientes Windows possam usar seus clientes IDE e VCS locais para editar no servidor LAMP. Ninguém tem uma conta no servidor Linux.

Crie sua estrutura de diretórios assim:

/var/www/mysite.com/www/derek/
/var/www/mysite.com/www/paul/
/var/www/mysite.com/www/mike/

Em seu DNS interno, crie um registro curinga que aponte **. dev * para o endereço IP do seu servidor da lâmpada. Estou assumindo 123.45.67.89 aqui.

No Apache, defina um virtualhost parecido com este:

<VirtualHost 123.45.67.89>
   ServerName lamp.dev
   ServerAlias *.dev
   VirtualDocumentRoot /var/www/%-3.0.%-2/%-4/%1/
</VirtualHost>

As partes importantes são o caractere curinga do ServerAlias, que faz com que esse vhost responda a todas as solicitações recebidas que terminam com '.dev'. O outro importante é o VirtualDocumentRoot, que parece complexo, mas não é tão ruim. Ele simplesmente corta o nome do host recebido em partes e constrói o DocumentRoot fora das partes. Você pode ler mais sobre isso aqui .

Agora, qualquer desenvolvedor pode visitar o link e visualizar sua cópia de trabalho pessoal do mysite.

Adicionar um novo site, subdomínio ou desenvolvedor é simplesmente um caso de criar os diretórios corretos no compartilhamento do Samba.

Para implantar nos servidores de produção, eu recomendo que você abandone scp e veja Capistrano , e a excelente interface web centralizada Webistrano . Capistrano é um bit centrada em Rails, mas leva apenas algumas linhas para se adaptar ao PHP, por exemplo. O Webistrano fornece uma GUI central na qual você pode implantar ou atualizar um site diretamente do controle de versão com o pressionar de um botão. Não é necessário ignorar implementações facilmente com script, que podem ser repetidas de forma confiável e revertidas em caso de problemas.