As builds automatizados desempenham um papel central na automação da integração contínua (CI) e são um dos principais facilitadores de um pipeline do CI/CD. Eles constituem a primeira de uma série de etapas automatizadas projetadas para avisar mais cedo possível sobre quaisquer problemas no seu código causados por suas alterações mais recentes.
Quando falamos sobre um build nesse contexto, estamos nos referindo a mais do que apenas o ato de compilar e vincular o código-fonte para criar um executável.
O processo de build automatizado inclui uma série de verificações, bem como o agrupamento de todas as partes necessárias para a execução do programa. Mesmo que você esteja trabalhando em uma linguagem interpretada, precisará de uma etapa de build.
Os arquivos resultantes no final do estágio de build – conhecidos como artefatos de build – são enviados através do pipeline de CI/CD para outros estágios de teste, seguidos pelo estágio de staging. Se um build passar em todas as etapas do pipeline, ele estará pronto para ser lançado em produção.
Antes de examinarmos o que envolve a automação da compilação, vamos considerar por que um processo de gerenciamento de compilação automatizado é importante.
Se você trabalha num IDE, você normalmente pode disparar um build com um atalho de teclado, então por que automatizar o processo?
Para começar, embora o build local seja útil quando você deseja verificar a integridade de seu trabalho ou fazer uma demonstração rápida de alguma coisa para seu chefe, não é uma boa prática usar um build local para seu pipeline de CI/CD.
O uso de um servidor de build dedicado garante um ambiente limpo, que logo sinalizará quaisquer dependências ausentes que, de outra forma, causariam problemas e atrasos quando o build for implantado num ambiente de teste.
Sem um build automatizado para disparar os outros estágios do pipeline, o CI/CD seria muito menos confiável. Se você tiver que se lembrar de fazer login no servidor de build e iniciar cada build, incluindo quaisquer testes, cuidar do processo caso algo falhe e, em seguida, mover o resultado para o repositório de artefatos para que possa ser implantado para os testes, então seu processo é propenso a erros.
É fácil adiar o início do build até que você tenha mais algumas alterações para testar, mas isso prejudica os benefícios do CI/CD.
Finalmente, a estratégia por trás de um pipeline de CI/CD é falhar rapidamente.
Quanto mais cedo você descobrir um problema, mais fácil será corrigi-lo e mais eficiente será o processo de automação de builds. Automatizar a fase de build é mais rápido do que disparar manualmente as várias etapas envolvidas e muito mais rápido do que mover arquivos e executar testes manualmente.
Ao automatizar o build, você garante que todas as etapas sejam realizadas na ordem correta em cada commit (ou em um lote de commits) e obtém o benefício de um feedback rápido enquanto libera tempo.
Se você está começando em CI/CD, configurar builds automatizados e dispará-los cada vez que alguém da sua equipe efetuar uma alteração é uma das primeiras coisas que você precisa fazer (depois de colocar tudo no controle de fontes). Você talvez já tenha um script de build ou um arquivo de definições, ou por cortesia do seu IDE ou que você mesmo escreveu.
Caso contrário, você precisará escolher uma ferramenta de automação de compilação apropriada para o idioma em que está trabalhando e especificar os arquivos para compilar, vincular e empacotar. Você pode então usar um servidor de CI para coordenar as várias etapas, desde o disparo inicial até o fornecimento de feedback e definição das condições de falha.
A integração contínua automatizada envolve o acionamento de um build após cada commit para o branch master, para que cada alteração seja integrada e testada assim que for realizada. Se o build for concluído com sucesso, ele irá disparar a próxima etapa do processo.
A maioria das ferramentas de CI permite que você configure gatilhos adicionais para o build e personalize os estágios do pipeline que seguem.
Por exemplo, você pode querer disparar o mesmo conjunto de etapas quando os commits forem feitos para qualquer branch de um diretório específico. Por outro lado, com a ajuda de uma ferramenta de implantação, você pode querer agendar uma compilação noturna que é submetida a camadas adicionais de teste e é usada para atualizar ambientes de preparação. Você também pode iniciar o estágio de build manualmente.
É uma boa prática executar as etapas de build num servidor de build dedicado, em vez de usar sua máquina de desenvolvimento. Construir num ambiente limpo sinaliza quaisquer dependências ausentes e evita problemas do tipo “mas funciona na minha máquina”.
A etapa de compilação propriamente dita invoca sua ferramenta de automação de compilação escolhida (como Maven, Ant ou Gradle), que executa as tarefas especificadas no script de construção ou no arquivo de definição.
Depois de ter uma noção de quanto tempo suas compilações levam para serem executadas, vale a pena usar uma ferramenta de implantação para configurar uma condição de falha para compilações que não são concluídas dentro de um período especificado. Esta prática evita que builds de longa duração bloqueiem recursos.
Além de preparar seu código para implantação, o processo de gerenciamento de compilação automatizado é um ponto ideal para executar várias outras verificações no seu código, como testes de unidade e linting e análise de código estático. A execução dessas verificações como parte de cada compilação com a ajuda de ferramentas de implantação e a resolução de quaisquer problemas à medida que surgem ajudam a melhorar a qualidade do seu código.
Apesar dessas verificações serem executadas antes que os artefatos de build serem produzidos, uma falha não precisa necessariamente interromper o resto do pipeline. Por exemplo, você pode decidir que deseja publicar o artefato de build e progredir para o próximo estágio do pipeline, mesmo que tenham sido encontrados erros de linting. Configurar um limite de qualidade ajuda a evitar que “pequenos” problemas se acumulem com o tempo.
A saída do processo de build automatizado são artefatos de build, que podem incluir instaladores, arquivos WAR, bibliotecas e contêineres. Publicar esses arquivos em um repositório de artefatos fornece um local central a partir do qual você pode implementar compilações em diferentes ambientes, idealmente com a ajuda de ferramentas de implementação.
Depois do build, o estágio seguinte de um pipeline de CI/CD geralmente envolve testes funcionais automatizados, que requerem que o build seja implantado em um ou mais ambientes de teste (às vezes junto com outros componentes, como um banco de dados ou outros microsserviços). Se esses testes forem concluídos com sucesso, o mesmo build poderá ser usado para atualizar os ambientes de teste e, por fim, ser lançado em produção.
Você pode visualizar os resultados da fase de build, inclusive se o build foi criado com sucesso, além dos resultados dos testes de unidade e outras verificações, a partir de sua ferramenta de CI. Configurar alertas para notificar sobre falhas permite que você reaja rapidamente e coloque seu código de volta num estado que permite o lançamento.
Uma ferramenta de implantação também reunirá dados de seu pipeline para que você possa analisar tendências. A revisão do histórico de construção e métricas, como duração do build, taxas de sucesso e cobertura de código, podem trazer insights que lhe ajudarão a melhorar seu processo de CI/CD.
Automatizar suas compilações é uma das primeiras etapas essenciais na configuração de um pipeline de CI/CD e no gerenciamento geral de compilações. Nesse sentido, é uma boa prática adotar ferramentas de implantação apropriadas. A fase de build fornece a primeira rodada de feedback rápido e viabiliza os estágios subsequentes do pipeline, desde o testes automatizados até a entrega contínua e implantação.