Integração Contínua / Entrega Contínua— Parte 2
- Parte 1 — Início
- Parte 2 — Jenkins Pipeline
- Parte 3 — Análise Estática de Código
- Parte 4 — Entrega com Ansible (AWX)
No artigo anterior, foi feito a configuração e integração do gitlab com o jenkins. O foco agora é na pipeline de integração. Antes de meter a mão na massa, vamos ver alguns conceitos importantes.
Pipeline as Code
Por padrão, a configuração do Jenkins tem sido feita pela interface gráfica, mas através do Pipeline Plugin é possível configurar toda a build do projeto junto com o código fonte. Esta abordagem nos permite ter maior controle sobre nossas pipelines, tendo versionamento, maior facilidade na análise da pipeline e maior facilidade na reutilização de pipelines, porque é bem mais fácil você copiar um arquivo do que repetir as configurações na interface gráfica para diversos projetos 😃
Multibranch Pipeline
Quando eu conheci esta funcionalidade, não consegui entender muito bem o por quê de usá-la, mas ao implementar uma pipeline simples, percebi algumas questões que me incomodaram e poderiam ser resolvidas com esta modalidade. Usando multibranch pipelines, você pode ter uma build diferente para cada branch no seu repositório, isto quer dizer que é possível executar a pipeline em uma branch de funcionalidade antes de enviar o código que foi escrito nesta branch, fazendo o merge para a branch de desenvolvimento, para ter certeza que está tudo certo em relação a testes e análise de qualidade.
Agora a parte que interessa!
Criando a pipeline de integração do projeto
Por padrão, ao receber uma notificação do Gitlab e iniciar a pipeline de integração, o Jenkins irá buscar um arquivo com o nome Jenkinsfile. Precisamos agora criar este arquivo.
Basicamente, o arquivo deve seguir algumas diretivas pré-definidas (leia a documentação da sintaxe de pipeline caso tenha dúvidas). Algo que pode chamar sua atenção logo de cara no trecho de configuração acima é a linha 2, que menciona docker. O que exatamente significa esta linha?
No primeiro artigo, criamos um volume em /var/run/docker.sock:/var/run/docker.sock nas configurações do docker-compose. Este volume permite que o socket do processo do docker sendo executado na máquina host (onde seu docker está instalado) seja usado dentro do container do jenkins. Traduzindo para o português, o jenkins pode usar o docker da máquina host, mesmo ele próprio estando dentro de um container, loucura né? 😅
Com isso, o jenkins pode baixar uma imagem de container com node, e executar todo o processo de integração dentro deste container, sem precisar fazer qualquer instalação de ferramenta no próprio jenkins, bem mais prático.
Logo abaixo das instruções do docker, temos o stages, onde definimos os passos que serão seguidos na pipeline. Por enquanto, temos somente dois passos: instalar os pacotes usados pelo projeto com npm install e executar os testes deste projeto com npm test (este foi o nome do script que eu fiz, no package.json).
Executando a pipeline
Com o Jenkinsfile já na raiz de seu projeto, faça seu commit, dê um git push e veja a mágica acontecer! 🎊🎉
Se tudo correu bem, você verá uma nova branch dentro da pasta de seu projeto Multibranch Pipeline.
Perceba que em momento algum foi configurada a branch específica, mas o jenkins foi capaz de detectar sua branch e adicionar por conta própria, após seu push.
Clicando na branch master, você verá o dashboard de jobs desta branch. Como vimos na configuração, temos somente dois estágios, e sendo estes completados, temos um job executado com sucesso.
E se criarmos uma nova branch do zero, e dermos um git push nesta nova branch, o que acontece? Vamos testar
Crie uma nova branch chamada ‘development’ a partir da branch master, faça o commit e dê o git push.
Novamente, se tudo correu bem, você terá uma nova branch adicionada ao projeto, sem precisar ter configurado previamente.
Clicando na branch development, você poderá ver que foram executados os mesmos procedimentos que foram executados na master.
Com isto, temos um fluxo integrado entre nosso Gitlab e Jenkins. Sempre que enviarmos código para nosso Gitlab usando git push, o Webhook configurado irá disparar uma notificação que vai fazer com que nosso projeto no Jenkins faça um scan no repositório do Git e inicie processos de integração de acordo com as mudanças nas branches. Para cada nova branch, será criada uma nova pipeline executando os passos descritos em nosso Jenkinsfile.
Agora vamos pensar um pouco no fluxo que desejamos seguir. Ao iniciar uma nova funcionalidade, um desenvolvedor deverá criar sua branch com nome feature/{nova_funcionalidade}. Ao fazer o git push nesta branch, como definimos anteriormente, os testes deverão ser executados para garantir o comportamento correto das novas funcionalidades e que estas não interferem no comportamento de funcionalidades anteriores, e deverá ser feita uma análise de qualidade no código escrito, para garantir o uso de boas práticas de programação.
Vamos delegar esta responsabilidade de análise de qualidade para outro serviço, o SonarQube. Mas isso vai ficar para o próximo artigo 😁
Mais um passo concluído no seu fluxo de integração contínua, nos vemos na próxima 🤘
