Como devemos configurar um servidor da Web que suporte o desenvolvimento contínuo?

Question

Eu aluguei um VPS (Linux - Fedora) e ele deve ser usado como um servidor da Web para desenvolvimento e produção do mesmo aplicativo da Web.

Eu tenho o apache, o subversion e todos os pacotes necessários para executar o PHP.

No apache, criei dois hosts virtuais:

dev.mydomain.com (for ongoing development, /var/domains/dev.mydomain.com/public_html )
www.mydomain.com (for production, /var/domains/www.mydomain.com/public_html )

Haverá apenas um desenvolvedor e ele usará o Netbeans como IDE no Windows XP.

Posso imaginar que a primeira coisa que ele fará é fazer o checkout de uma cópia do repositório SVN para o seu computador no Netbeans. O que eu vou fazer é apenas configurar dois repositórios SVN nessas pastas.

/var/domains/dev.mydomain.com/public_html
/var/domains/www.mydomain.com/public_html

Então, quando ele faz algumas alterações em sua cópia local e, em seguida, confirma as alterações, ele pode visitar dev.mydomain.com em seu navegador para visualizar as páginas e depurar o código.

Mais tarde, quando ele achar que os códigos em dev.mydomain.com podem ser usados na produção, ele poderá usar o Netbeans para confirmar as alterações em www.mydomain.com .

Existe algum problema com o cenário acima? É assim que tal servidor web deve ser configurado?

    

Answer 1

Supondo que você esteja fazendo HTML / design gráfico puro, isso deve ser bom. Se o pai for dinâmico, especialmente se estiver fazendo algo, mesmo que vagamente complicado / interessante / complicado, eu não configurei minha caixa de produção para ser minha caixa de desenvolvimento.

Você deseja um ambiente de desenvolvimento que seja o mais parecido com o ambiente de produção possível, e usar a mesma caixa faz isso, mas há alguns problemas. O mais importante é que você pode reduzir sua caixa de produção testando seu novo desenvolvimento. Loops infinitos, funções sem saída adequada, snafus do banco de dados .... Tudo isso (e mais) pode afetar negativamente o ambiente de produção.

Minha primeira inclinação, se você não está fazendo desenvolvimento interno, é alugar uma segunda caixa. Minha segunda inclinação é comprar uma caixa de batedores barata na qual você possa replicar o ambiente. É menos crítico que o hardware seja parecido com o software. Por exemplo, no meu último trabalho, tínhamos servidores autônomos high-end de pequenas empresas em uma colo para lidar com nosso ambiente de produção. Nosso ambiente de teste foi um par de eMachines.

Para recapitular: se você estiver desenvolvendo web dinamicamente, eu não usaria a produção para testá-lo. Obtenha um segundo ambiente hospedado ou compre uma caixa de batedeira e configure-a de forma idêntica.

    

Answer 2

É útil comprometer e publicar automaticamente pelo menos para projetos pequenos, mas um script de implantação real (por exemplo, usando o rsync como sugere o @Kevin M) fornece melhor controle e isolamento do ambiente de produção. Por exemplo, algumas estruturas dependem de uma certa configuração de diretório (para caches, tmp dirs) que não faz sentido manter na subversão. Um script de implantação pode garantir que esses diretórios existam com as permissões adequadas, etc.

Você precisará fazer algumas coisas se quiser que as confirmações sejam publicadas automaticamente:

1. Este artigo descreve como configurar a implantação automática em confirmações. Você pode ou não precisar de todos os scripts, dependendo da configuração do usuário, permissões, etc.
2. Você desejará certificar-se de que seu servidor esteja configurado para não exibir os diretórios .svn em sua cópia de trabalho publicada.

Além disso, se você estiver dependendo do software instalado (php, python, etc). Você vai querer elaborar um plano de como realizar atualizações e testá-las antes de enviar o software para a produção. Isso é mais difícil de fazer em uma única caixa.

    

Answer 3

Acho que as informações do repositório estão armazenadas na cópia de trabalho, por isso não serão enviadas para qualquer lugar especificado. Além disso, as informações são armazenadas em um formato de banco de dados, não na estrutura familiar de diretório / diretório / diretório / file.html em que ele está armazenado para o cliente.

O que você quer é rsync . O desenvolvedor fará o seu svn checkout normal do repositório subversion como você descreveu, mas quando ele estiver pronto para enviar para a produção, você ou ele irá logar no servidor via ssh e fazer rsync -av --cvs-exclude /var/domains/dev.mydomain.com/public_html /var/domains/www.mydomain.com/public_html . Esta lista tudo o que foi atualizado e ao mesmo tempo copia para produção, exceto para os diretórios .svn