Deploy simples com Git Artigo

Conheça os cursos gratuitos do WebDevBr! - Inscreva-se!


Este artigo foi publicado a 2 anos, 1 mês, 2 semanas, 2 dias atrás.

Deploy simples com Git

Depois do artigo de ontem sobre Deploy automático com GitHub e PHP várias pessoas me questionaram sobre o porque deveria ser feito assim e não apenas com Hooks do Git, então deixo aqui esta possibilidade para vocês e uma idéia para ir além, assim podem decidir o que é melhor.

O que você precisa

Neste ponto é ideial que você conheça o Git a ponto de conseguir publicar algo no GitHub, se não, acalme-se, é muito simples e rápido:

  • Cadastre-se aqui no WebDevBr
  • Acesse a área de alunos.
  • Faça o curso free de Git
  • Pronto!

O curso é curto, não vai tomar muito tempo da sua vida e você vai conhecer uma ferramenta fantástica.

Gostou deste artigo?

Receba atualizações semanais com novos artigos do WebDevBr e outras dicas!

O que seu servidor precisa

Você vai precisar que seu servidor tenha:

Eu uso um cloud na Digital Ocean, mas existem outras possibilidades, uma vez ouvi falar que a King Host tem tudo isso, mas como diz a música: "Nunca vi, nem comi, eu só ouço falar!"

Como deve funcionar

Sempre que você estiver satisfeito com uma etapa do desenvolvimento do seu projeto e quiser publicar, basta rodar um comando e pronto, está tudo no servidor.

Neste processo, você não manda para o GitHub, envia diretamente para o servidor e o Git se encarrega de executar as tarefas necessárias.

Bacana né!

Esse processo é bem mais rápido e seguro que o FTP tradicional por vários motivos, vários mesmo, mas vou deixar aqui alguns que eu priorizo:

  • Não sobrescreve arquivos, só envia as últimas alterações e você pode usar um .gitignore para o git ignorar o que você quiser.
  • Você sempre pode voltar para uma versão anterior do projeto com o Git
  • Backup facilitado em outros lugares (um comando git clone [url do repositório] e pronto!)
  • Mais seguro, ele só atualiza os arquivos que você alterou
  • Super simples para automatizar tarefas
  • Histórico de alterações com data, hora, quem alterou e arquivos e linhas alterados
  • Você pode proteger o acesso com uma conta prêmium, ou usar o BitBucket (lá isso é free)
  • Facilita o trabalho em equipe

Preparando o Git no servidor

Você vai precisar acessar o servidor remoto e criar um repositório do Git vazio antes de começar, é simples na verdade, basta ir até um diretório que vai ficar o projeto e fazer assim:

git init --bare

O comando inicia um repositório sem diretório de trabalho, a ideia é tornar impossível o uso de "manipulações do git" (add, rm, commit...) diretamente no servidor (o que seria uma péssima prática).

Note que o diretório acaba com .git, isso é um padrão muito bem adotado, mas não obrigatório.

Obs.: Não esqueça de trocar o [nome-do-projeto] pelo nome do projeto, rsrs.

Agora vamos criar um diretório para os arquivos, ele pode se chamar public ou web ou o que você quiser. Tomando como base que você ainda esteja dentro do diretório .git, rode os comandos a seguir:

cd ..
mkdir web
cd [nome-do-projeto].git

O primeiro comando sai do diretório do .git, o segundo cria um diretório web e o último volta para o .git, ainda temos algumas configurações para fazer nele.

O último passo é configurar os Hooks. Hook é a maneira como o Git dispara scripts quando certas ações são tomadas, as três importantes para nós agora são:

  • post-receive: Executa algo após receber dados
  • pre-receive: Executa algo antes de receber dados
  • update: Igual o anterior, porém o update executa em cada branch, enquanto o pre-receive executa apenas uma vez.

Aqui vamos usar apenas o post-receive, informei os demais apenas para você ter mais opções.

Ambos os arquivos ficam dentro de [nome-do-projeto].git/hooks/, caso não exista um post-receive ai dentro, você pode criar, aqui um exemplo simples:

#!/bin/sh
GIT_WORK_TREE=/usr/nginx/webdevbr/web git checkout -f

Você precisa dar permissão de execução para o post-receive:

chmod +x post-receive

O /usr/nginx/webdevbr/web após GIT_WORK_TREE é o diretório aonde os arquivos ficaram disponível para web (lembra que criei um diretório antes).

Prontinho.

Seu repositório remoto está pronto.

Git no seu computador

O processo local é bem simples, você só precisa adicionar o repositório remoto (o seu servidor) ao repositório local, existem várias formas de fazer isso.

Se você não tem nada criado localmente:

git clone ssh://[ip-ou-endereco-do-servidor]/caminho/completo/ate/o/[nome-do-projeto].git [projeto]

Troque o [projeto] pelo diretório que ele deve salvar, e sim, se não existir será criado.

Obs.: Você pode usar --origin [name] no fim do git clone aonde [name] será o nome do remote, remote são os endereços dos servidores que enviaremos nossos códigos, por exemplo:

git clone ssh://192.168.2.1/usr/share/nginx/loja-virtual.git loja --origin production

Ele já vai deixar um remote chamado production pra você, se você não informar --origin o padrãos erá usado, ou seja origin.

Para adicionar outros remotes ou se você já tem o repositório criado:

git remote add origin ssh://[ip-ou-endereco-do-servidor]/caminho/completo/ate/o/[nome-do-projeto].git

Enviando para o servidor, ou servidores

Agora temos dois remotes, um chamado origin e outro chamado production, vamos estudar um exemplo prático.

Imagine que você tem um ambiente de homologação, ou seja, que guarda a versão mais rescente do projeto para testes, enquanto o ambiente de produção exibe a versão estável para os usuários, isso poderia ser assim:

  • homologacao.seusite.com.br - ambiente de homologacao
  • www.seusite.com.br - site real

Ambos estão no mesmo servidor, e após o ok do cliente, o homologacao passa para o "site real", é bem prático de trabalhar assim.

Eu sei que o remote origin envia para o homologação, e que o production envia para o projeto real, então eu posso:

git push origin master <-envia as últimas alterações para o homogação
git push production master <-envia as últimas alterações para o site real

Aconselho que você também de uma olhada na documentação oficial do Git, o passo a passo é bem simplificado e vai muito além do que vimos aqui.

Conclusão

Você ainda pode somar este ideia com o artigo anterior, ou seja, enviar para o GitHub ou BitBucket que atualizaria o ambiente de homologação automaticamente enquanto mantem uma cópia online dos códigos para o seu cliente ou a equipe, manter um backup, enfim, quando estiver tudo redondo você atualiza no endereço final ``git push production master`, as propostas não se contradizem, você soma os recursos.

Disse rescentemente no Hangout PHP boas práticas, se você não usou a fundo não pode ter opinião sobre!

Obs.: Não uso nenhum dos dois métodos, rsrs, uso Capistrano, mas já falei dele no meu Medium.


* Parcelamento apenas cartão de crédito! Pode haver uma pequena variação no parcelamento em relação a simulações apresentadas!