É uma boa ideia instalar o Mercurial no servidor e o hg pull para implantar?

Acabei de começar um novo emprego no mês passado e parece que eles NÃO têm controle de origem para seu código. Eles contam com os backups que o provedor de hospedagem faz para eles.

Depois de conversar um pouco, convenci meu chefe de que deveríamos definitivamente usar o controle de origem e depois que dei um pequeno seminário sobre isso, toda a equipe está a bordo; eles amavam Mercurial.

Então, neste momento, é assim que trabalhamos:

º----------BitBucket
º---------/
º--------/

Eu e os outros três desenvolvedores hg pulldo BitBucket, fazemos nossas alterações e depois hg pushno BitBucket.

Agora, para implantação, alguém precisaria enviar por FTP os arquivos mais recentes para o servidor de produção.

Eu estava pensando em instalar o Mercurial em nosso servidor e usar hg clone(posteriormente hg pull) para manter as versões atualizadas na produção.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

isso é uma boa ideia? Quaisquer armadilhas potenciais que eu possa não estar vendo? Alguém aqui fez algo semelhante? Como você implanta um grande aplicativo de estrutura PHP (estamos usando o Moodle)?

Essa é certamente uma boa ideia e é um método comum a ser usado para implantação. Você pode usar uma ramificação estável para fins de implantação, mantendo o tronco para o desenvolvimento contínuo, para poder testar a ramificação estável antes de implementá-la na produção.

O único problema pode surgir quando você possui informações confidenciais em sua base de código (como chaves de API etc.) que não deseja enviar para servidores de terceiros (no seu caso, isso seria Bitbucket). Nesse caso, um script simples que é executado depois que você extrai os dados do repositório para restaurar os dados confidenciais no local correto resolverá esse problema.

Lembre-se de que essa estratégia de implantação não é atômica. Pode acontecer que alguns arquivos já estejam atualizados enquanto outros ainda podem estar no estado antigo enquanto o aplicativo está sendo acessado. Isso pode causar efeitos colaterais inesperados.

Uma maneira de realizar implantações atômicas é usando links simbólicos. Crie um diretório contendo os novos arquivos. quando tudo estiver pronto, altere um link simbólico para o diretório usado. Se você mantiver a versão antiga por perto, também poderá reverter facilmente.

Outra (na minha opinião, melhor) possibilidade: use um servidor de compilação / servidor de integração contínua.

Breve explicação: este é um servidor (pode estar internamente, não precisa estar na Internet) que você configurou para monitorar seus repositórios e, sempre que houver novos conjuntos de alterações nos repositórios, o servidor cria seu código ( AFAIK, isso não é necessário no PHP) , executa testes de unidade e implanta seu código no servidor da web.

Para mais informações, consulte estes links:

• Artigo da Wikipedia sobre CI
• Pergunta do estouro de pilha: Qual é o objetivo de um "Build Server"?

Existem muitos produtos diferentes para CI por aí , mas o único que usei até agora é o TeamCity . Muito fácil de configurar ... de fato, foi o primeiro que tentei e gostei tanto que fiquei com ele.

Solução barata alternativa:

Se a configuração de um servidor de compilação for muito trabalhosa ou se você quiser ter mais controle sobre quando exatamente o site é implantado, basta configurar um arquivo de script (Batch / Powershell no Windows ou algo semelhante no Linux / Mac) que puxe o versão mais recente do seu repositório e enviá-la por FTP no servidor de produção.

Basicamente, é o mesmo que um servidor de compilação, apenas mais simples.

Não importa o quão exatamente você o resolva no final ... certifique-se de automatizá-lo de alguma forma!

Você deseja implantar com um único clique / digitando um único comando, para que TODOS possam fazê-lo sem precisar saber nada de especial e sem cometer erros - mesmo em caso de desastre ou estresse.

Fazemos isso, ou coisas semelhantes a isso. O @johannes não atômico menciona o ângulo é uma questão, embora em termos realistas aconteça com tanta rapidez que deva dar certo e que haja maneiras de contornar isso, como ele aponta.

Provavelmente mais importante do que essa não atomicidade seria "como você gerencia atualizações de esquema de banco de dados" - implantar código incorreto dessa maneira facilita a correção. O grande problema é quando você implanta uma atualização que altera o banco de dados que você deseja reverter. Ou se você estiver fazendo atualizações incorretas e corrompendo dados.

O outro problema que tivemos com as ferramentas DCVS (em vez de usar o SVN) é que agora você tem uma cópia de toda a base de código na máquina em algum lugar que um invasor possa pegar. E também que a base de código DCVS pode ficar muito pesada em termos de tamanho, o que pode importar se você estiver pagando por armazenamento e / ou backup. Ainda estamos usando o SVN para a implantação final por esses motivos.

É uma ótima idéia, mas lembre-se do seguinte:

• Tente não se comprometer no servidor (embora algumas vezes raras faça sentido, por exemplo, instalar um plug-in ou adicionar ativos de conteúdo)
• Use um servidor intermediário ou uma implantação de repositório secundário para testar
• Tenha sempre cuidado para hg update -Cnão afetar a produção (por exemplo, exclua arquivos importantes)
• Tenha uma filial de produção e desenvolvimento, implante apenas a filial de produção
• Trate os ativos como backup (por exemplo, imagens para conteúdo) e ignore os dados do usuário (por exemplo, anexos / uploads, cache, etc.)
• Sempre tenha uma hg statussaída limpa no servidor (isso ajudará você a ter certeza de que está ignorando coisas como cache)
• Não implante o repositório na pasta da web. Use links simbólicos de fora do espaço público (por exemplo, ln -s / myrepo / src / web / public_html / myapp)
• Cuidado para não versão dos arquivos de configuração (especialmente com senhas do banco de dados ou outras)
• Não use em vez de um backup de produção, este é um backup de desenvolvimento para código de produção , não para dados de produção

Por fim, acho que a coisa mais valiosa para adicionar um DVCS ao seu processo de implantação é que isso adicionará segurança à sua implantação, às vezes hackers injetam código malicioso nas suas coisas e você realmente não tem como detectá-lo facilmente sem algo como controle de versão ( distribuído especialmente, já que o aspecto distribuído para o VCS facilita a verificação da integridade de seus arquivos).

Eu tive alguns sites obtidos cortado algumas vezes, tendo Mercurial me ajuda litterally desfazer essa hacks por apenas emitir um hg update -Cno servidor (é claro que você pode querer fazer uma hg statuse obter os arquivos afetados para análise posterior).