Como configurar Gitlab CI e React em poucos passos
Alguns anos atrás eu tinha uma percepção de que CI era coisa de outro mundo, na época trabalhava com um software sem testes automatizados ou ferramentas para garantir padrão de código como ESLint, era difícil entender o conceito e enxergar valor no processo de CI, pois na época não havia uma “necessidade ou dor latente”.
Novas experiências me fizeram implementar CI em um projeto, a necessidade foi de automatizar a execução de testes unitários, testes de aceitação, verificação de padrão de código e build, no nosso cenário.
Vou mostrar abaixo como você pode configurar um pipeline básico e rodar o CI do seu projeto em poucos minutos
Requisitos
Para acompanhar os passos abaixo, considero que você já tem o código fonte de uma aplicação em um repositório do Gitlab, vou utilizar nos exemplos uma aplicação gerada pelo “create-react-app”, no final da publicação deixarei o link para o meu repositório de exemplo.
Porquê Gitlab?
Dentre vários softwares de CI existentes, o Gitlab é um software livre, tem hospedagem de repositório e runners grátis, fácil de configurar e atende muito bem ao que se propõe.
O que são os runners?
São servidores que recebem o código fonte do repositório e executam o trabalho definido no script do pipeline. O Gitlab disponibiliza shared runners gratuitamente, mas você pode configurar o seu próprio runner caso precise de mais flexibilidade ou desempenho.
O que é pipeline?
É uma definição de fluxo de todas as etapas que o código fonte deve passar, ele pode conter etapas paralelas ou não.
Como definir o meu pipeline?
O Gitlab possui um arquivo de configuração chamado gitlab-ci.yml que deve ser criado na raiz do seu repositório, através dele declaramos nosso script de execução do pipeline.
Vamos definir os stages do nosso pipeline em ordem sequencial de execução.
Agora criamos nossas jobs (eslint, unit_tests, react_build) e associamos aos stages, neste exemplo cada job pertence a um único stage, você pode associar mais de um job por stage para que executem em paralelo.
A propriedade image define o nome da imagem utilizada para execução do container Docker, desta forma garantimos que independente do runner que irá executar esta tarefa, o ambiente será sempre o mesmo.
Na propriedade before_script você pode definir um ou mais comandos necessários para preparação do ambiente, o exemplo abaixo instala a dependência eslint.
Na propriedade script devemos declarar o comando principal da job, por exemplo: execução do build, testes.
Pronto!
Após você realizar um commit e push para o repositório, automaticamente uma pipeline será iniciada, acompanhe o andamento através do menu pipelines / jobs acessível na página do seu repositório.
Entre nos detalhes da job para acompanhar o log de execução:
Não pare por aí
Existem dezenas de configurações que podem ser feitas através do arquivo gitlab-ci.yml ou através da interface do Gitlab para adequar o processo a sua realidade, exemplos:
- Integrações com outras aplicações como Slack para avisar quando uma pipeline falhou.
- Bloquear o aceite de um merge request caso o commit falhe na pipeline.
- Obter coverage do teste através de uma job e exibir no README.md do projeto.
- Extrair relatório de testes ou outros arquivos de uma job através de artifacts.
Link para o repositório de exemplo:
https://gitlab.com/rafaelcaviquioli/react-ci/pipelines
Conclusão
Utilizar os runners compartilhados do Gitlab pode não atender um projeto que tenha muito volume de integrações ou que necessite de maior performance para execução da pipeline, mas sem dúvida este problema é resolvido alocando o seu próprio runner em uma máquina física ou na nuvem.
A aplicação do CI tem um papel muito importante em projetos que valorizam a qualidade e integridade do código e que conseguem medi-la através de alguma ferramenta, principalmente por servir de apoio no dia a dia do desenvolvedor.
