Deploy com Git Hooks

Post publicado em 01/01/2018 08:15 Última atualização em 04/08/2019 20:38

[vc_row][vc_column][vc_column_text]Recentemente fiz um post sobre a má prática de deixar a pasta .git na área pública da hospedagem e recebi bastante críticas construtivas com relação à soluçãogambiarra que apresentei para resolver o problema. Dentre as críticas vieram também sugestões das maneiras mais corretas de se resolver este problema. A maneira que acreditei ser a mais simples foi com Git Hooks e é sobre isso que falarei aqui. Procurando por "deploy com git hooks" no Google, de 10 resultados, 9 são em inglês e essa foi a motivação para escrever este post. Utilizei como base o artigo em inglês que o Caio Vaccaro criou para a Digital Ocean. Mas antes de colocar a mão na massa, você precisa entender um pouco do conceito e avaliar se este processo é válido ou não para o seu cenário.  

Por que realizar deploy com Git Hooks?

Existem diversos meios de realizar deploy de aplicações, desde processos manuais que custam caro e são passíveis de erros, até Integração Contínua (CI) onde define-se um conjunto de regras e passos a fim de que a aplicação seja seguramente colocada em produção. O deploy com Git Hooks é a forma mais simples de automatização pois é de rápida configuração e garante que a aplicação Live estará sempre em sua última versão.

Existem riscos em automatizar o deploy com Git Hooks?

Sim. O risco é que como todo push é automaticamente sincronizado com a aplicação live, se um programador da equipe commitar e subir algo não plenamente testado ou com bug, este se replicará no ambiente de produção.   Agora que já lhe alertei sobre o cuidado desta prática, vou lhe mostrar de forma simples, sem configurações avançadas nem realização de tasks, como realizar o deploy com Git Hooks. A parte prática será dividida em 3 etapas, a primeira local para a criação de um projeto de teste, a segunda em um servidor para a criação do repositório e a terceira e última etapa para fazer as coisas funcionarem.  

Etapa 1: Criando um novo projeto

Este post vai ser um passo a passo que futuramente pretendo transformar em um screencast, então nosso primeiro passo é criar um novo projeto com o Git. Para fins de exemplo, criarei um projeto chamado git-hooks.
$ mkdir git-hooks
$ cd git-hooks
$ git init
No comando acima criei uma pasta chamada git-hooks, entrei na mesma e inicializei o git. Agora adicionarei um arquivo chamado index.html com o seguinte conteúdo.
<html>
    <head>
        <meta charset="utf-8">
    </head>
    <body>
        <h1>Página de exemplo</h1>
    </body>
</html>
Em seguida, o adicionarei no git e darei o primeiro commit. De momento ainda nada de push, somente o commit mesmo.
$ git add index.html
$ git commit -m "Added first file"
 

Etapa 2: Criando o repositório no servidor

Para este exemplo utilizarei a minha hospedagem atual, Configr, para mostrar como o processo é simples e rápido. Para este exemplo eu já criei um site chamado githooks.andrebian.com no meu painel e vou, ao decorrer deste conteúdo, sincronizar o meu projeto lá com Git Hooks. O caminho do site que criei na Configr é a seguinte:
/home/subdominios/githooks.andrebian.com/www
Onde www é a pasta pública de minha aplicação. A imagem mostra a estrutura completa da pasta do site. Aqui será criada uma pasta chamada repo.git. Após criar a pasta, entrarei na mesma e iniciarei o git, mas aí tem uma pequena diferença do que foi apresentado na parte 1 e esta diferença será explicada a seguir.
$ mkdir repo.git
$ cd repo.git
$ git init --bare
Perceba que logo após o git init existe a opção --bare. Esta opção serve para informar que a pasta não conterá nosso código-fonte, mas sim, apenas o versionamento. Ah, não é obrigatório a pasta conter o sufixo .git (como neste caso repo.git) no entanto é mais por questão de padronização de nomenclatura que a defini desta forma. Veja como foi o processo. Percebeu que na imagem existe uma pasta chamada hooks? É para ela que vamos agora!
$ cd hooks
Após estar na pasta, crie um arquivo chamado post-receive com conteúdo similar ao que apresento abaixo. Altere os endereços para a sua necessidade.
#!/bin/sh
            #Destino (área pública)     #Local do controle de versão
git --work-tree=/var/www/domain.com --git-dir=/var/repo/site.git checkout -f
  No meu exemplo, ficou assim: E o último item a ser realizado neste passo é aplicar a permissão para execução no arquivo post-receive.
$ chmod +x post-receive
O que foi feito até aqui foi registrar um gatilho que sempre quando receber um push garantirá que os arquivos necessários estarão presentes na pasta em que nossa aplicação Live está rodando. Para efeito de teste, mostro como de momento nada ainda foi enviado para o servidor. Acessando https://githooks.andrebian.com o resultado é a página padrão do meu cloud.  

Etapa 3: Fazendo tudo funcionar

Agora que já temos um projeto local e um servidor configurado, pronto para receber nossas atualizações e já as colocar em produção automaticamente, chega a hora de realizar os últimos procedimentos e são eles:
  1. Adicionar a URL do repositório no projeto local
  2. Realizar o primeiro push
  3. Acessar o site para validar que as alterações surtiram efeito
  4. Realizar pequenas modificações, commitar, subir e testar novamente se tudo está funcionando.
 

1. Adicionar URL do repositório no projeto local

Como mencionado na etapa 1, temos um projeto chamado git-hooks, certifique-se de que está com seu shell no local correto para então no seu servidor obter a URL do repositório e a adicionar com o nome de live.
$ git remote add live ssh://user@host/home/user/githooks.andrebian.com/repo.git
Altere o endereço para a sua necessidade. O resultado do comando git remote -v deve conter um remote chamado live, como na imagem abaixo. Caso o resultado contenha um remote chamado live, pode prosseguir, senão, retorne  e verifique o que pode ter ocorrido de errado.  

2. Realizar o primeiro push

Agora chegou a hora de enviarmos tudo pra produção, direto, sem validação, sem tasks, sem integração contínua.
$ git push live master
Se tudo ocorreu bem, é para neste momento nosso simples html já estar no ar!  

3. Acessar o site para validar que as alterações surtiram efeito

Acessando, no meu caso, https://githooks.andrebian.com é para o html com apenas um tag h1 já estar lá, isso apenas dando git push sem nenhum procedimento adicional. Simples não?! Um simples push já coloca tudo em produção.  

4. Realizar pequenas modificações, commitar, subir e testar novamente se tudo está funcionando

E agora vou aprimorar um pouco mais a página e subir estas novas alterações para ver se tudo está funcionando como esperado.
<html>
    <head>
        <meta charset="utf-8">
        <title>Exemplo de deploy com Git Hooks</title>
        <style>
            body {text-align: center; font-family: Cantarell, 'sans-serif';}
            h1 {color: #724170;}
            hr {color: #eee;}
            a {text-decoration: none;color: #724170;}
            a.btn:hover {background-color: #724170;color: #fff;}
            .btn {text-transform: uppercase;font-size: 16px;font-weight: 600;line-height: 2.8;border-radius: 0.3em;letter-spacing: 0em;box-shadow: 0 0em 0em rgba(0,0,0,0.18);border: #724170 solid 2px;text-decoration: none;padding: 5px;}
        </style>
    </head>
    <body>
        <a href="https://www.andrebian.com">
            <img src="https://www.andrebian.com/wp-content/uploads/2017/12/logo-andrebian-horizontal-fundo-transparente-full.png">
        </a>
        <hr>
        <br />
        <h1>Deploy com Git Hooks</h1>
        Esta página é o resultado do artigo sobre deploy com Git Hooks, leia o mesmo para entender como chegamos aqui.
        <br />
        <br />
        <a href="https://www.andrebian.com/deploy-com-git-hooks" class="btn">Ler o artigo</a>
    </body>
</html>
Agora o commit, push e tudo está no ar!
$ git add index.html
$ git commit -m "Added more info"
$ git push live master
O resultado:

Certo, mas já uso github, bitbucket ou outro, devo descartar?

Não. A intenção é que o remote live seja apenas mais um, o remote para o deploy automático da aplicação mas não necessariamente o único. Desta forma você pode continuar com seu remote origin normalmente.  

Conclusão

O processo de deploy automático com Git Hooks é muito prático e sem sombra de dúvidas é o mais simples de implementar se comparado com ferramentas de integração contínua. No entanto esta automatização requer cuidados extremos pois se algo subir de forma incompleta, não plenamente testada ou com introdução de novos bugs, imediatamente estará no ar. Então fica a dica, somente dê push em live quando tiver certeza de que tudo está pronto para ir para produção. Se possível, utilize git hooks também no ambiente de desenvolvimento para realizar tasks pre-commit ou pre-push, desta forma é possível impedir o commit ou push em caso de algum erro dando mais segurança ao ambiente de produção.   [/vc_column_text][us_cta title="Tem interesse em Git?" color="light" btn_link="url:https%3A%2F%2Fandrebian.com%3Fs%3Dgit|||" btn_label="Ler mais" btn_style="3" btn_size="20px"]Temos bastante conteúdos relacionados ao git que com certeza você gostará[/us_cta][/vc_column][/vc_row]


Scroll down