Git com integração/implementação contínua: cinco dicas para repositórios Git de fácil utilização com IC

Os sistemas de armazenamento externo como o Artifactory (que cria um complemento para o Bamboo), o Nexus ou o Archiva podem ajudar no caso dos artefatos gerados pela sua equipe ou pelas equipes ao redor. Os arquivos de que você precisa podem ser incluídos no diretório de builds no início do build — assim como as bibliotecas de terceiros que você obtém via Maven ou Gradle.

Se a rede não conta com nenhum sistema de armazenamento externo, é mais fácil aproveitar a compatibilidade com arquivos grandes (LFS) oferecida pelo Git.

Git LSF é uma extensão que armazena ponteiros para arquivos grandes em seu repositório, em vez de armazenar os arquivos em si. Os arquivos em si são armazenados em um servidor remoto. Como você pode imaginar, isso reduz o tempo de clonagem drasticamente.

É provável que você já tenha acesso ao Git LFS — compatível com Bitbucket e GitHub.

Digamos que seu build exija todo o histórico do repositório: se, por exemplo, uma das etapas no seu build atualizar o número de versão no seu POM (ou similar), ou você estiver mesclando dois branches a cada build. Ambos os casos exigem que o Bamboo envie as alterações por push de volta ao seu repositório.

Com o Git, as alterações simples feitas nos arquivos (como atualizar o número da versão) podem ser enviadas sem todo o histórico presente. Porém, para o processo de merge, o histórico do repositório ainda é necessário, pois o Git precisa de informações passadas para encontrar o ancestral comum das duas ramificações. E essa exigência é problemática quando o build usa clonagem superficial. O que me leva à dica nº 3.

A operação de clonagem também fica muito mais rápida, e o Bamboo faz essa ação por padrão.

Observe que o armazenamento em cache do repositório o beneficia apenas se você estiver usando agentes que persistam de um build para outro. Se você criar e destruir agentes de build em EC2 ou outro provedor de nuvem sempre que um build é executado, o armazenamento em cache do repositório não fará diferença, pois você estará trabalhando com um diretório de build vazio e precisará obter uma cópia completa do repositório de qualquer maneira.

Clones superficiais mais armazenamento em cache de repositório dividido pelos agentes elásticos vs. persistentes é igual a uma interessante rede de fatores. Aqui está uma pequena matriz para ajudá-lo a criar uma estratégia.

É (quase) desnecessário dizer que implementar a integração contínua em todas as suas ramificações ativas é mais do que recomendado. Porém, é bom executar todas os builds em todas as ramificações em relação a todos os commits? É provável que não. Entenda o motivo.

Considere a Atlassian, por exemplo. A gente tem mais de 800 desenvolvedores, todos enviando alterações para o repositório várias vezes ao dia — a maioria envia para as ramificações de recursos. É muito build! E, a menos que você faça a escala instantânea e infinita dos agentes de build, essa imensidão de builds resulta em muita espera na fila.

Um dos nossos servidores internos do Bamboo abriga 935 planos de builds diferentes. A gente conectou 141 agentes de build a esse servidor sem deixar de seguir as práticas recomendadas, como aprovação de artefatos e paralelização de teste, para que todo build seja o mais eficiente possível. E o pior: a criação de builds depois de cada push estava atrapalhando o progresso do trabalho.

Em vez de simplesmente montar outra instância do Bamboo com outros 100 agentes ou mais, recuamos e perguntamos se isso era realmente necessário. E a resposta foi negativa.

Dessa forma, demos aos desenvolvedores a opção de transformar seus builds de branch em botões, em vez de sempre acioná-los automaticamente. É uma boa maneira de equilibrar o rigor de teste com a preservação de recursos, e os branches são o local em que a maior parte da atividade está acontecendo. Por isso, é uma ótima oportunidade para economias.

Muitos desenvolvedores gostam de ter o maior controle que botões oferecem e consideram que se encaixam perfeitamente no fluxo de trabalho deles. Outros preferem não pensar sobre quando executar um build e atêm-se a acionadores automáticos. Ambas as abordagens podem funcionar. O importante é ter seus branches em teste em primeiro lugar e garantir que você tenha um build limpo antes de mesclar na cadeia produtiva.

Porém, ramificações críticas, como ramificações da versão estável e principal, são outra história. Builds têm acionamento automático, seja sondando o repositório quanto a alterações ou enviando notificações push do Bitbucket para o Bamboo. Uma vez que a gente usa ramificações de desenvolvimento para todo o trabalho em andamento, os únicos commits que vêm para o principal devem (em teoria) ser ramificações de desenvolvimento sendo mescladas. Além disso, essas são as linhas de código com base nas quais a gente lança e cria as ramificações de desenvolvimento. Assim, é muito importante termos resultados de teste em tempo hábil para cada merge.

Fazer pesquisas no repositório a cada poucos minutos à procura de alterações é uma operação muito fácil no Bamboo. Porém, ao escalar até centenas de builds em milhares de ramificações envolvendo dezenas de repositórios, o uso de recursos aumenta rápido. Em vez de sobrecarregar o Bamboo com toda essa pesquisa, você pode fazer com que o Bitbucket avise quando uma alteração for enviada e precisar ser criada.

É comum alcançar esse feito por meio da adição de hooks ao repositório, mas a integração entre o Bitbucket e o Bamboo faz toda a configuração "por baixo dos panos". Depois de vinculados no back-end, o build orientado a repositório aciona o Just Work™ pronto para uso. Não é necessário usar Hooks ou configurações especiais.

Não importa a ferramenta usada, os acionadores controlados por repositório têm a vantagem de "hibernarem" automaticamente quando a ramificação-alvo fica inativa. Ou seja, chega de desperdiçar os ciclos de CPU do sistema de integração contínua pesquisando centenas de ramificações abandonadas ou de perder tempo com o fechamento manual dos builds das ramificações. (Vale observar que o Bamboo pode ser configurado com facilidade para ignorar as ramificações após X dias de inatividade, se ainda assim você quiser fazer as pesquisas.)