Aplicando CI/CD da sua aplicação com Circle-CI
Desenvolvimento

Aplicando CI/CD da sua aplicação com Circle-CI

Aplicando CI/CD da sua aplicação com Circle-CI
Ramon Teixeira
27 de dezembro de 2019
Aplicando CI/CD da sua aplicação com Circle-CI

Recentemente, comecei um projeto com o Luiz (Bagunça) e até escrevi sobre ele aqui. Hoje quero mostrar como construí as pipelines de CI/CD para o frontend dessa aplicação, o projeto é VueJS compilado com Vue-CLI e disponibilizado na AWS com S3 + Cloudfront. 

Como pré-requisito, pede-se para se ter um bucket s3 e o cloudfront criado, há diversos materiais para auxiliá-lo, em breve escreverei em como construir utilizando terraform, mas enquanto isso deixo um link que acredito ser útil para você

Não tratarei assuntos sobre o porquê da escolha, ou se é a melhor escolha. Digamos que eu gostei da propaganda que sempre aparece nos vídeos do youtube, e acabei querendo testar.  

Vou iniciar explicando como fazer o arquivo de configuração do Circle-CI

Crie na raiz do projeto o diretório “.circleci” e dentro do diretório o arquivo “config.yml” 

Na primeira linha é a versão do arquivo do Circle-CI, em seguida é configurado cada job que estará disponível para execução. 

Chamei de “build” o processo que vai executar o lint, testes e salvar o dist do projeto. Após o nome do job, defini a imagem Docker que será executado, o circle-CI oferece imagens deles, que estão pré-disposto para execução, porém é possível utilizar qualquer imagem do Docker HUB. Lembrando que ao utilizar uma imagem fora das oferecidas, o tempo do build terá um tempo maior, por necessitar baixar a imagem todo build. 

O atributo “working_directory” defini o diretório a ser executado. 

Logo depois dele é iniciado as etapas pelo atributo “steps”: 

  • Checkout: baixa o código fonte do projeto 
  • Restore_cache: restaura o cache utilizando a chave informada (md5 do package.json), assim quando é alterado alguma dependência, é feito a instalação do zero das dependências. 

Ainda dentro do steps, utiliza-se o atributo “run” para informar uma execução shell script, podendo nomear cada um dos executores, conforme abaixo: 

Os comandos utilizado foram todos rodados pelo yarn, conforme configurado na seção de scripts no package.json do projeto: 

Para finalizar as etapas desse Job, vamos salvar o cache das dependências e salvar o dist da aplicação. O cache de dependências irá ajudar a otimizar o tempo do build e o dist permite carregar o artefato pronto pela etapa de deploy. 

Novamente será utilizado as chaves de cache (conforme feito a restauração no início do job), para o cache de dependência continuará sendo o checksum do package.json, enquanto o dist do projeto utilizará as variáveis do circle-CI “CIRCLE_BRANCH” e “CIRCLE_SHA1”, tornando disponível o artefato para determinado commit de determinada branch (evitando que um build de produção pegue um artefato de outra branch). 

Pronto, o job de build está feito. Agora mostrarei os comandos para o job chamado “deploy”, desta vez utilizarei uma imagem pega pelo Docker hub com o aws-cli instalado. 

Notem que tudo começa a ficar similar com o anterior, porém adicionei uma etapa no início para instalar o pacote ca-certificates no Alpine, pois é preciso para não dar erro de certificado SSL ao baixar o cache. 

Nas etapas seguintes, foi restaurado o cache do diretório dist, em seguida o comando aws s3 sync sincroniza todo conteúdo do diretório dist dentro do bucket, apagando os conteúdos que não existirem no diretório (importante para projetos SPA que geram arquivos minificados com hash). Por último é chamado a invalidação de cache do CloudFront para todos conteúdos “/*”. 

OK, agora temos os Jobs prontos para executar uma rotina de CI e CD, mas agora falta apenas definir em que momento cada um irá rodar. Para isto utilizei a tag workflows, que cria fluxos com os jobs, podendo definir quais branches rodam determinados Jobs ou até mesmo agendar horário para execução de Jobs (Ex: nightly build).  

Neste exemplo rodarei o comando de build para todas as branches, assim terei um fluxo de CI que garante que a branch atual está 100% pronta para rodar, e quando rodar a branch “master”, será disparado o job de deploy, para subir para produção. 

Pronto, o projeto está com a configuração pronta, agora próxima etapa será ativar o projeto no circle-ci e depois habilitar os hooks no projeto no github para exibir no Pull Request. 

O arquivo completo você pode visualizar aqui

Entrando no site do Circle-CI e fazendo seu login, você irá para o painel principal, no painel lateral vá em “Settings” -> “VCS” e clique em “Manage GitHub Checks” 

Irá abrir a tela do github para dar acesso aos repositórios, escolha os que deseja, ou se quiser pode selecionar “All repositories”. 

 Voltando agora ao painel principal, no painel lateral, vá em “Add Projects” 

Agora, você verá uma página com um quickstart, onde é possível copiar uma configuração default por linguagem, mas como já configuramos o arquivo config.yml, vamos apenas selecionar o botão “Start building” e pronto o projeto iniciará o build inicial. 

Configurando as credenciais AWS 

Para configurar o acesso a AWS, basta ir no botão de configuração do projeto e no menu “AWS Permissions”, preencha as informações da credencial. 

Utilizando badges 

Caso queira adicionar uma badge no README do seu projeto, exibindo o status atual do build, basta ir no botão de configuração do projeto e no menu “Status Badges”, copie o conteúdo do “Embed Code” e cole no local que preferir do teu README. 

Habilitando integração com Pull Request no Github 

Agora que já temos o build funcionando corretamente, o projeto está com a sinalização de sucesso/falha, agora podemos configurar algumas opções que evitem o máximo a quebra da master. Então, vamos no projeto do Github, “Settings” -> “Branches” -> “Add rule” 

No campo “Branch name pattern” coloque “master” e em “Rule settings” vamos marcar as opções: 

Estas opções configuram que para poder aceitar o merge para a master, a branch do Pull Request precisa estar com a última versão do destino, e precisa ter tido sucesso no Job de Build (lint, test e build) do Circle-CI. 

Todas essas regras serão aplicadas até a quem é administrador/owner do projeto. 

Espero que tenha sido útil, e qualquer dúvida ou feedback, não hesite em entrar em contato. 


Escrito por

Ramon Teixeira
Ramon Teixeira é formado em Sistemas de Informação pela UNISUL, atualmente esta finalizando a especialização em Arquitetura de Software. Integrante da equipe IT Services da DB1 Global Software, atuando como desenvolvedor Java. Se interessa por tecnologias e técnicas que impactam na arquitetura de sistemas e na quebra de paradigmas.

Inscreva-se e receba nossa newsletter!

Estamos sempre gerando conteúdos inéditos para compartilhar conhecimento com você, além das últimas notícias de tecnologia.