Três ganchos do Git para integração contínua

Descubra como os hooks do Git impõem compilações limpas em ramificações de recurso e muito mais.

Sarah Goff-Dupont Sarah Goff-Dupont

Se você usa o Git há um tempo, é bem provável que já ouviu falar dos hooks do Git. Talvez você tenha brincado com eles um pouco. Os hooks do Git são incríveis no contexto da integração contínua. Sendo assim, neste artigo vou mergulhar em três casos de uso e direcionar você para hooks prontos que você pode adicionar ao seu fluxo de trabalho. Se você está começando com os hooks do Git, não se preocupe: a gente vai começar com o básico.

Noções básicas sobre os hooks do Git

Os hooks são o mecanismo nativo do Git para acionar scripts personalizados antes ou depois de operações como commit e merge. Pense neles como o sistema de plug-in do Git. Se você olhar no diretório .git de qualquer repositório do Git você vai ver um diretório chamado "hooks" que contém um conjunto de scripts de hook como exemplo.

.git/hooks

Instalar os hooks do Git é simples e bem documentado, então não vou entrar nesse assunto aqui.

Existem duas classes amplas de hooks: a do lado do cliente e a do lado do servidor. Os hooks do lado do cliente são executados na estação de trabalho local, enquanto os hooks do lado do servidor são executados no servidor do Git.

Você também pode classificar ganchos como pré ou pós. Ganchos pré-recebimento são invocados antes de determinadas operações Git e têm a opção de cancelar uma operação, se necessário. Eles atuam como seguranças protegendo seu repositório por trás de uma corda, impedindo que você e seus colegas façam o commit de códigos com defeito. Ganchos pós-recebimento são executados após uma operação ter sido concluída e, portanto, não têm a opção de cancelá-la. Em vez disso, ganchos pós-recebimento automatizam partes do seu fluxo de trabalho de desenvolvimento.

Usar hooks do #Git é como ter robozinhos prontos para realizar todos os seus desejos.

Ganchos de Git automatizam coisas como…

  • verificar se você incluiu a chave de item do Jira associada na mensagem de commit
  • aplicar pré-condições para mesclagem
  • enviar notificações à sala de bate-papo da equipe
  • configurar seu espaço de trabalho depois de mudar para um branch diferente

Impor builds limpos em branches de recursos

Os hooks pré-recebidos do lado do servidor são um complemento poderoso à integração contínua, pois podem impedir que os desenvolvedores enviem código para a ramificação principal, a menos que o código atenda a certas condições, como guardiões ninja de elite, o protegendo de código ruim.

Em geral, os desenvolvedores sabem que não é indicado fazer merge com a ramificação principal quando existem testes falhos na ramificação deles. Mas, às vezes, a gente esquece de verificar. Ou quando a gente compartilha uma ramificação com outras pessoas, às vezes mais mudanças são feitas desde a última vez que a gente verificou o build da ramificação… coisas acontecem.

Assim, você pode adicionar um hook do lado do servidor que procura merges de entrada para a ramificação principal. Quando ele encontra um, o script verifica o build mais recente na ramificação e, se houver algum teste com falha, o merge vai ser rejeitado. Meu colega e representante dos desenvolvedores da Atlassian, Tim Petterson, escreveu um script de hook para esse evento, projetado para trabalhar com o Bamboo e o disponibilizou no Bitbucket. Você pode pegar, personalizar e adicionar o script ao seu repositório.

Protegendo sua cobertura de código duramente conquistada

Algo que vejo muitas equipes tendo dificuldade é manter a forma de verificação do código. Muitas vezes, as equipes precisam de cobertura retroativa para a base de código com testes e é bem frustrante ver essa cobertura tão suada escapar à medida que mais recursos são adicionados sem testes. Então, o Tim também escreveu um hook do lado do servidor de pré-recebimento para proteger a ramificação principal de recusar a forma de verificação do código.

Este hook também procura por merges de entrada para a ramificação principal. Em seguida, ele se conecta com o servidor de integração contínua para verificar a forma de verificação do código atual na ramificação principal e cobertura na ramificação. Se a ramificação tiver cobertura inferior, o merge vai ser rejeitado.

A maioria dos servidores de integração contínua não expõe dados de forma de verificação do código por meio de APIs remotas, assim, o script envia o relatório de forma de verificação do código. Para tanto, o build deve ser configurado para publicar o relatório como um artefato compartilhado, tanto na ramificação principal quanto no build da ramificação. Uma vez publicado, você pode obter o relatório de cobertura mais recente da ramificação principal conectando o servidor de integração contínua. Para a cobertura de ramificações, você obtém o relatório de cobertura do build mais recente ou para builds relacionados ao commit que está passando por merge.

E só para ficar claro, todas essas ações pressupõem que você já tenha a forma de verificação do código em execução. O hook não faz mágica — ele só procura os dados de cobertura nos resultados do build. Esse hook também funciona com o Bamboo por padrão, assim como o Clover (ferramenta de forma de verificação do código da Atlassian para Java e Groovy). Mas ele pode ser personalizado para se integrar a qualquer servidor de build ou ferramenta de forma de verificação do código.

Verificação do status dos builds de ramificação

Porque amigo de verdade não deixa ramificações com falhas para o outro consultar.

Aqui está uma chance de brincar com os hooks do Git do lado do cliente: um script de hook de pós-consulta que expõe o status do build da ramificação direto da janela do terminal, também do Tim. O script obtém o número de revisão principal da ramificação da cópia local e consulta o servidor de integração contínua para ver se essa revisão foi construída e, em caso afirmativo, se o build foi bem-sucedido.

Digamos que você queira ramificar a partir da principal. Esse hook vai dizer se o commit principal na ramificação principal foi compilada com sucesso, o que significa que é um commit "seguro" da qual criar uma ramificação de recursos. Ou digamos que o gancho diga que o build para a revisão falhou, ainda assim, o mural da equipe mostra um build verde para a ramificação (ou vice-versa). Isso significa que sua cópia local está desatualizada. Vai ficar a seu critério decidir se você obterá as atualizações ou continuará trabalhando na cópia local que você tem.

Usar esse gancho poupou aos desenvolvedores da Atlassian inúmeras dores de cabeça. Se você não consegue convencer a sua equipe a adotar os ganchos de servidor discutidos acima, pelo menos instale esse na sua estação de trabalho local. Você não vai se arrepender.

Todos os ganchos do Git para integração contínua que eu mostrei aqui funcionam com Bamboo, Clover e Bitbucket por padrão. Porém, lembre-se de que os ganchos do Git são neutros em termos de fornecedor; assim, você pode personalizá-los para que funcionem com qualquer pilha de ferramentas que você tenha. Automação para a vitória!