NextJS: CI e CD para Front-end com o Github Actions

Entendendo CI e CD - Apresentação

Olá, pessoas. Sou Mario Souto e sejam muito bem-vindos a esse curso da Alura falando sobre Github Actions voltando para front-end, comigo Dev Soutinho, Mario Souto. Tem muita coisa legal para abordarmos. Você provavelmente já ouviu falar de Github Actions, já ouviu falar de CSSD, esse termo de Continuous Integration, Continuous Delivery e tem curiosidade sobre ele.

A minha ideia é tentar clarear para você um pouco desse tópico, tentar trazer alguns pontos-chave que você pode aplicar no seu dia a dia como front-end. Pegar um pouco dessa mentalidade de DevOps, essa ideia de configuração de coisas como código, como integramos isso no dia a dia, como você pode pegar todos esses conceitos e fazer o seu software no dia a dia ter mais qualidade.

Espero que você esteja preparado para começar essa jornada onde vamos abordar vários tópicos, como rodar os testes automatizados, quando rodar os testes automatizados, como fazer tarefas remotas via GitHub, como até fazer algumas coisas que vão melhorar a sua experiência como desenvolvimento no geral. Esse é o meu convite. Vejo você daqui a pouco no próximo vídeo. Até já.

Entendendo CI e CD - O que é CI e CD

Agora que você já comprou a ideia, quer aprender junto comigo, vamos falar o que é esse tal de CI e CD. Nada mais justo que para falar de CI e CD eu faça uma busca no Google com você. Então o que é CI e CD? Se pegarmos a primeira definição que aparece no Wikipédia, vamos encontrar o seguinte, "Em Engenharia de Software ou CI/CD pode se referir às práticas combinadas de integração contínua e entrega contínua".

Vou até dar um zoom para você que estiver no celular conseguir ver melhor. "CI/CD preenche as lacunas entre as atividades e equipes de desenvolvimento e operação, reforçando a automação na compilação, teste e implantação de aplicativos". Uma outra forma legal de começarmos a abordar isso é o seguinte.

Já parou para pensar como uma empresa que tem mil pessoas decide quem "builda" o aplicativo para ir para a loja? Ou como ela decide quem roda os testes para cada pull request que você sobe no seu código, no pull request que está aberto, cada commit que você sobe gera um pull request? Como fazemos para validar tudo isso?

Ou melhor, como você faz para garantir que as pessoas de um time estão programando com padrão parecido para você não olhar aquele arquivo e saber, "Esse é de fulano, esse arquivo é de ciclano". Ou melhor, como você garante que a funcionalidade que você acabou de fazer está funcionando?

Você pode ouvir várias dessas perguntas e falar, "Para a qualidade de código, posso usar o Linter". Qualidade de código digo no aspecto visual, de ele ficar padronizado. Para garantir de funciona são testes. Só que precisamos rodar isso toda vez. E pode ser que você rode na sua máquina, suba para o request, faça uma outra alteração e esqueça de rodar.

Então o CI e CD, gosto de dizer que eles vão entrar quando estamos lidando com o esquecimento das pessoas, com quão passivo estamos de deixar algum detalhe passar. Gosto até de mostrar essa imagem que você vai encontrar no Google muito parecida com essa da resposta que vimos. Basicamente, pensa que para o seu software ir para o ar, existe um processo contínuo que tem que acontecer.

Então você descobre um problema e esse problema vira uma tarefa, essa tarefa vai ser pega por alguém do time, alguém do time vai entender o que precisa ser feito para conseguir resolver essa funcionalidade, vai escrever código para isso, vai escrever testes para isso e abrir uma sugestão de melhoria, uma solução de mudança, um pull request. Esse pull request vai ser “emergiado” na branch main e aí você vai ter que garantir que esse novo código rode com tudo o que tinha antes.

Então na prática conseguimos encaixar isso. Basicamente, vamos ter um plano, ou seja, a tarefa, o problema que queremos resolver, vamos escrever um código, vamos rodar esse código na máquina e escrever um teste. E aí você garante que esse teste está funcionando, está passando e tudo o mais. Quando o time aprova esse código do teste, vamos para a etapa que release.

Então vamos começar a trabalhar para colocar esse código no ar. Uma vez que foi feito o release, podemos fazer em stage ou algo do gênero, mas aí vai para colocarmos no ar, de fato, viria a parte do deploy. Tem a parte de Operação e Monitoramento que vai de você descobrir se esse código no ar está gerando novos bugs ou algo do gênero.

Talvez esse bug novo não foi previsto nos testes, não foi previsto nas etapas anteriores ou até foi uma combinação nova. Na hora de integrar duas funcionalidades elas deram conflito. Então você monitora isso e, de novo, traça um plano com código, build, testa e vai seguindo. Basicamente é como se isso fosse praticamente quase que uma esteira onde as pessoas vão estão escrevendo o código delas, vão estar fazendo os commits no dia a dia.

Para cada commit que você faz é interessante você garantir que o seu código está funcionando com o que tinha antes. Sei que estou batendo bastante nessa tecla porque CI/CD se resume muito a isso. Se formos quebrar o Continuous Delivery é muito mais próximo a etapa de entrega. Ou seja, depois que você terminou o pull request e vai colocar ele no ar, você precisa garantir que ele está testado e compatível com tudo o que já existe.

Enquanto que o Continuous Integration é enquanto você quer entregar o seu software, a parte que você está programando na feature nova, a parte de integração, você está garantindo que o caminho novo da API que você criou não quebra as coisas que já existiam. Ou o botão novo de Login que você fez funciona de acordo com o Login que já tínhamos antes.

Então essa é mais ou menos a ideia que quero trabalhar com vocês. Em linhas gerais, a definição é essa, o Continuous Delivery é muito relacionado a colocar o software no ar e o Integration é para garantir que o pull request que está aberto é compatível com o código que está atualmente na branch main.

E agora na próxima meta é falar com vocês sobre GitHub Actions e conseguirmos ver essa forma de trabalhar com o CI/CD usando essa ferramenta do GitHub. Entender o que são esses workflows e outras coisas. Mas vamos ver isso no próximo vídeo. Até daqui a pouco.

Entendendo CI e CD - Scripts iniciais do projeto

No vídeo anterior a esse comentei que íamos começar a ver as GitHub Actions nesse vídeo. Eu ia explicar o que é idea workflow, de pipeline, como funciona essas coisas. Mas, na verdade, para poder mostrar isso o melhor jeito é trazer na prática porque vamos precisar abrir um pull request para ver essas coisas passando, ver o CI/CD acontecendo na prática.

Então para isso resolvi escolher criar um projeto super simples com NextJS. Se você está acompanhando os conteúdos que temos na Alura, você provavelmente já viu que tem conteúdos sobre NextJS que você pode se aprofundar e tudo o mais. Tem no meu canal do YouTube também. Então você pode se aprofundar lá.

Vamos criar um projeto super simples só para podermos começar a contextualizar isso com vocês. Por onde vou começar? Vou na área de trabalho e colocar "06-github-actions-front-end". Então como vamos trabalhar com GitHub Actions do ponto de vista do front-end? Vou arrastar essa pasta para o VSCode. Ele já viu abrir certo e posso jogar ele em uma nova aba. Está aqui, "06-github-actions-front-end".

O próximo passo que vou ter é basicamente abrir o terminal dentro do VSCode. Você pode ir em, "View > Terminal" e o terminal já tem esse comando que abre para você. Por hora, vou só inicializar esse projeto com o NextJS. De novo, vai ser um projeto super simples só para conseguirmos pegar os conceitos de rodar o Linter, de rodar os testes e outras tarefas que vamos ter que fazer automaticamente para cada pull request que formos abrindo.

Como vou fazer? Vou dar git init e rodar também um npm init-y. No caso, vou usar o próprio yarn, yarn init -y. Se você quiser usar o npm fica à vontade, fica a seu critério. Inicializei o projeto em yarn, já pegou o autor e tudo o mais. Vou adicionar as coisas que precisa para poder usar o NextJS. Então é, yarn add react react-dom next. Enquanto instala você pode conferir tudo o que estou te mostrando esse passo a passo no “Getting Started” da documentação do NextJS.

Então ele fala yarn add next react react-dom. No caso, inverti a ordem lá. Mas o padrão vai ser esse. Tem até os scripts do próprio NextJS que esse é o ponto que queria pegar e começar a trabalhar com vocês. Porque para você ter um projeto Next, basta fazermos o seguinte. Basta criar uma pasta “pages” e nela criar o “index.js” e fazer, export default function HomeScreen() { return ( <div> <h1>Página Inicial</h1></div> ) }.

Uma vez que fiz isso, para poder rodar o projeto, precisamos de um comando. Normalmente usamos npm start ou yarn start. Isso é um dos princípios do CI/CD para poder trabalhar com GitHub Actions para poder fazer tudo o que estamos fazendo. Sempre que estamos usando esses comandos que até a própria documentação do NextJS sugere para nós, estamos trabalhando com scripts, estamos criando pequenas automações para nós.

Por que pequenas automações? Porque se eu quiser rodar o Next sem estar do jeito que ele está, olha o que preciso fazer. Entrando na pasta “node_modules”, dentro dela tem uma pasta “.bin”. Se eu não tiver o yarn start para poder rodar, preciso fazer assim, ./node_modules/.bin/next dev. Se eu rodar esse comando, o NextJS vai estar rodando no modo de desenvolvimento. Agora consigo vir no navegador e rodar “localhost:3000” e ele abre a página para nós.

Preciso acessar a pasta “node_modules”, achar o binário do Next e fazer um monte de coisa. quando estamos trabalhando com essas automações, principalmente de CI/CD para rodar as coisas automaticamente, você vai estar querendo simplificar os passos.

Então uma forma de simplificar esse acesso é dentro do arquivo “package.json”, se criar essa entrada scripts, "scripts": {}, e chamar "scripts: { "dev": "next" }, o próprio npm, o próprio yarn já está preparado para abrir a pasta “node_modules”, procurar o binário e verificar se tem algum Next aqui.

Se tiver, ele vai executar para nós tal como esse “nanoid” e esse “loose_envify”. Ambos vão ter o mesmo comportamento. Não sei o que eles fazem. Mas sei que quando colocamos esse Next, é um atalho para “node-modules”, “bin” e “next” que estamos usando. Posso colocar o dev, "scripts": { "dev": "next dev" }. Se rodarmos agora yarn dev ou npm run dev, ele vai rodar para nós o comando e de novo conseguimos acessar.

Então queria pegar isso com você. Acostumar você que não é só o comando para poder rodar a ferramenta, para poder entrar no modo de desenvolvimento, é o comando que estamos criando uma automação. Isso já é uma automação pequena de infraestrutura que impacta no nosso desenvolvimento, impacta na Developer Experience.

Fica mais fácil desenvolver tendo que rodar só yarn dev para todos os projetos que você usa, não importa como ele roda, do que ter que lembrar qual é o “.bin” que preciso chamar para poder rodar o “next”, para poder rodar o servidor node ou seja lá o que for. Essa é a ideia que quero passar com vocês. Então agora de próximos passos o que vou fazer?

Vamos ir além nisso. Se voltarmos, tem mais comandos. Tem o build, tem o start e tem o lint. Vamos copiar cada um deles. Inicialmente quero trabalhar um pouco mais com essa ideia dos comandos. Por quê? Se eu vier no “Source Control”, repara que tem um monte de arquivos que estamos precisando mexer, tem um monte de arquivos que estamos monitorando com o Git.

Primeiro de tudo, vou criar um arquivo “gitignore”, npx gitignore node. Ele vai deixar menos arquivos para nós. Ficou só esses de monitorar. E agora vou explorar esse comando de build porque uma das etapas do processo de CI/CD é fazer o deploy. Já criamos o projeto, já temos uma página. Podemos até colocar duas. Vou colocar uma nova e chamar de "sobre.js".

Vai ser SobreScreen ou AboutScreen, export default function AboutScreen(). Você escolhe o nome que você achar melhor. Então temos a AboutScreen. Se viermos no navegador, não está acessando porque desliguei o comando, mas na prática está rodando o projeto. Vamos voltar no “package.json”. Quando rodamos o comando build do Next, rodamos assim, yarn build.

Lembrando que criamos um atalho que acessa o “node_modules”, faz o “bin”. Ele vai gerar um build dentro dessa pasta “.next”. Só que o Next tem um formato que você exporta uma pasta com os arquivos estáticos dele que gosto bastante de usar. Esse comando para exportar é outro, é o next export. Posso fazer assim, yarn export. Criei esse novo comando. O que o export faz?

Das nossas páginas ele faz um mini build delas. Só que ele pega só o arquivo HTML e o arquivo JavaScript, ou seja, você não precisa ter um servidor com o NextJS para rodar ele por de baixo dos panos e tudo o mais. Dessa forma podemos pegar esses arquivos HTML e publicar eles em diferentes provedores. Você pode publicar na Vercel, na Netlify, também no Heroku. Tem vários lugares que você pode colocar esse arquivo. Até no GitHub Pages você consegue guardar isso.

Vou deixar alguns links meus que podem te ajudar a fazer esses deploys. Mas na prática vamos fazer um deploy também. No caso, vamos usar Vercel. Mas queria mostrar que conseguimos gerar o build da nossa aplicação e colocar nessa pasta “out”. Funciona. Apago e vou em next export e geramos de novo. Aprendemos a criar comandos, vimos o npm scripts, estamos pegando aquelas automações e comecei a fazer paralelo com essa parte de CI/CD de deploy.

Normalmente, quando você gera essa parte de release para mandar para o ar, todo mundo deve poder gerar isso, independente do lugar onde esteja. Então queremos ter um arquivo de build aqui. E você pode ter diferentes passos para isso. No caso, estamos usando o export para gerar o artefato final que é o que vamos estar usando.

Podemos até apagar esse comando de build e falar que o build desse projeto é o next export. Porque se eu chamar agora yarn build, ele vai gerar de novo a pasta. Fomos até além. Para evitar ter algum resquício do arquivo anterior, podemos apagar a pasta “out”. Então, "build": "rm -rf out && next export", ou seja, incrementamos agora. Estamos tentando apagar a pasta “out” e aí criamos o next export.

Então vamos fazer assim, posso agora fazer o yarn build e ele gerou a pasta de novo. Se rodarmos sem, ele vai sempre tentar apagar a pasta e criar de novo. Repara que estamos automatizando para garantir que se tiver alguma página que apagamos ou algo do gênero, garantimos que essa pasta build vai ser sempre a mais intacta possível, a mais recente possível.

Estou evitando pegar qualquer versão anterior. Quero que quando rode o export esteja a versão correta. Podemos ir além. Por exemplo, estou falando de gerar a coisa de build e tudo o mais. Talvez usar o nome build seja até melhor do que out, porque out fica meio fora, meio despadronizado. Podemos fazer o seguinte, se eu quiser renomear a pasta “out” faço assim, mv out e passo o novo nome, build, por exemplo, mv out build.

E aí mudei de out para build. Na frente, depois que exportamos esse código, fazemos um "build": "rm -rf out && next export && mv ./out build". Então de “./out” vai para “./build”, "build": "rm -rf out && next export && mv ./out ./build". Olha como está ficando complexo isso.

Isso faz parte do processo de CI/CD porque estamos deixando um comando claro que vai rodar na máquina de qualquer pessoa ou de alguma outra forma que vamos configurar mais para frente como é o build da nossa aplicação. Faltou até colocar no Gitignore. Então vou dizer que a pasta “build” não pode ser versionada pelo GitHub, # Nosso Projeto build/.

E agora temos que dizer que temos que apagar a pasta “build” também no começo. Então se eu rodar, yarn build, vou até apagar essa anterior, o comando build vai sempre gerar uma nova pasta build e apagar a anterior para nós. Então estamos criando uma sequência de passos. Criamos uma automação usando o que o pessoal chama de npm scripts para deixar isso claro e padronizado para rodar nas máquinas dos membros do time.

Esse é um primeiro princípio que quero mostrar para vocês das automações. Logo vocês vão ver como ligamos isso junto com uma GitHub Action para fazermos deploy e tudo o mais. Tem também essa parte de lint que é um outro tópico que trouxe que é manter um pouco da qualidade de como estamos rodando o software e tudo o mais.

Mas primeiro queria introduzir essa parte de criar o projeto e mostrar que só de definir esses scripts, já estamos fazendo uma automação e já estamos fazendo um workflow, um fluxo de trabalho que logo logo vai encaixar com o CI/CD. Espero que tenha ficado claro. Vejo você no próximo vídeo onde vamos começar, de fato, a integrar com essa parte das GitHub Actions, com pull request e outras coisas. Então vejo você daqui a pouco. Até mais.

Sobre o curso NextJS: CI e CD para Front-end com o Github Actions

O curso NextJS: CI e CD para Front-end com o Github Actions possui 139 minutos de vídeos, em um total de 38 atividades. Gostou? Conheça nossos outros cursos de Next.JS em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Entendendo CI e CD
• Começando com as GitHub Actions
• Indo além do CI e CD
• Automatizando testes
• GitHub Actions e CI/CD