
Estou trabalhando na aplicação da lâmpada. Temos 2 servidores (Debian) Live e Dev.
Eu trabalho constantemente no dev main para adicionar novos recursos e corrigir bugs.
Quando estou satisfeito, tudo funciona bem, eu coloco o código relevante no sistema Live. O banco de dados (mysql) é local para cada máquina.
Agora, esta é uma configuração bastante básica e quero melhorar um pouco o fluxo de trabalho. Eu uso git e github para controle de versão. Admito que só usei um branch. Podem ser três desenvolvedores diferentes que trabalham no código em momentos diferentes. Todos nós usamos o mesmo nome de usuário Linux para nos conectar ao servidor de desenvolvimento e editar o código diretamente quando necessário. Normalmente, eu comprometo e envio o código no final do dia para o github.
Uma coisa a ter em mente é que não é fácil executar esse código em uma máquina local, pois há muitas configurações de apache e subdomínios que não funcionariam em uma máquina local, por isso é importante trabalhar no servidor de desenvolvimento, não localmente.
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 essas alterações? por exemplo
/var/www/meusite_derek /var/www/meusite_paul /var/www/meusite_mike
meu pensamento é que eles podem fazer um pull do branch principal e então criar seu próprio branch e mesclá-lo novamente. Não tenho certeza de como isso funcionará com o git localmente e com o github.
precisarei criar contas de usuário diferentes no GitHub também.
Eu gostaria de fazer isso da maneira 'certa' e à prova de futuro por ter muitos desenvolvedores em potencial, mas também não quero complicar demais. Uma solução simples e elegante é a preferida.
alguma recomendação ou sugestão?
Responder1
Uma solução que usamos com cerca de 12 desenvolvedores é a seguinte. Funciona muito bem e proporciona uma configuração flexível sem a necessidade de modificar mais a configuração do servidor. Provavelmente não será dimensionado para 40-50 desenvolvedores devido à latência da rede e à velocidade de armazenamento do servidor.
Nós compartilhamos o/var/www/árvore via Samba, para que os clientes Windows possam usar seus IDE locais e clientes VCS 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/
No seu DNS interno, crie um registro curinga que aponte **.dev* para o endereço IP do servidor da lâmpada. Estou assumindo123.45.67.89aqui.
No Apache, defina um host virtual semelhante a 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 curinga 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 a partir das partes. Você podeLeia mais sobre isso aqui.
Agora, qualquer desenvolvedor pode visitarhttp://derek.www.mysite.com.dev/e veja sua cópia de trabalho pessoal do mysite.
Adicionar um novo site, subdomínio ou desenvolvedor é simplesmente o caso de criar os diretórios corretos no compartilhamento do Samba.
Para implantar nos servidores de produção, recomendo que você abandone o scp e dê uma olhadaCapistranoe o excelente frontend web centralizadoWebistrano. Capistrano é um pouco centrado em Rails, mas leva apenas algumas linhas para se adaptar ao PHP, por exemplo. Webistrano fornece uma GUI central onde você pode implantar ou atualizar um site diretamente do controle de versão com o apertar de um botão. Ter implantações com scripts fáceis, que podem ser repetidas de forma confiável e revertidas em caso de problemas, não devem ser ignoradas.