Processos automatizados nos ajudam a entregar software com qualidade e agilidade, e um desses processos é o CI/CD. Neste texto, pretendo detalhar como implementei esse processo no meu portfólio.
Problemas
Anteriormente, eu tinha integrado o repositório diretamente com a Vercel. No entanto, enfrentei alguns problemas:
- O deploy era realizado sempre que a branch era atualizada, mesmo quando os testes falhavam.
- Não tinha muito controle sobre quando o deploy era realizado, pois sempre ocorria quando a branch main era atualizada.
PS: Talvez houvesse algumas configurações na Vercel que pudessem corrigir esses pontos. No entanto, optei por implementar o CI/CD para explorar essa funcionalidade no GitHub e também como objeto de estudo.
Solução
Para solucionar esses problemas, acabei criando dois fluxos de trabalho no GitHub:
- CI (Continuous Integration): Nesta etapa, serão executados builds de testes e linters para verificar a integridade e qualidade do projeto. A ideia aqui é receber um feedback rápido sobre as modificações enviadas para a branch principal, evitando possíveis falhas.
- CD (Continuous Delivery): Esta etapa estende a CI e tem a responsabilidade de implementar o software em diferentes ambientes. O objetivo é garantir que o software esteja pronto para ser implementado rapidamente.
A seguir, vou detalhar a implementação de cada um. Para saber mais sobre como implementar fluxos de trabalho no GitHub, você pode consultar diretamente a documentação.
CI
No CI, acabo executando 2 jobs em paralelo:
- Lint e Unit Tests: Executa o lint no projeto e falha se encontrar alguma inconsistência. Também executa os testes unitários.
- Lighthouse: Executa o Lighthouse em diferentes browsers e falha se a pontuação for baixa.
Futuramente, pretendo adicionar testes de integração também.
O trigger para esse fluxo de trabalho é acionado a cada pull request enviada para a branch main ou sempre que a branch main é atualizada.
Você pode verificar o código desse fluxo de trabalho aqui.
CD
Para implementar o fluxo de trabalho de CD, tive um pouco de dificuldade, pois desejava que esse fluxo fosse executado somente após o CI ser concluído com sucesso. Após algumas buscas na internet, acabei implementando da seguinte forma:
- Adicionei um trigger que é executado sempre que o CI é executado na branch main.
on:
workflow_run:
workflows: ["CI"]
branches: [main]
types:
- completed
- Dentro do job, adicionei uma condição que verifica se o fluxo de trabalho do CI foi concluído com sucesso.
jobs:
Deploy-Preview:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
No step de deploy utilizei o Vercel CLI para fazer o deploy na deploy, segue o exemplo:
steps:
- uses: actions/checkout@v3
with:
ref: ${{ github.event.pull_request.head.sha }}
- name: Use Node.js 20.x
uses: actions/setup-node@v3
with:
node-version: 20.x
- uses: pnpm/action-setup@v2
with:
version: 8
- name: Install Vercel CLI
run: npm install --global vercel@latest
- name: Pull Vercel Environment Information
run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
- name: Build Project Artifacts
run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
- name: Deploy Project Artifacts to Vercel
run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
Você pode verificar o código completo desse fluxo de trabalho aqui.
Futuramente pretendo criar workflows de deploy para ambientes de preview e de produção.
Conclusão
Como mencionado anteriormente, a implementação de workflows no GitHub proporciona um maior controle sobre nossos processos de CI/CD. Dessa maneira, podemos configurá-los de forma a otimizar sua eficácia e atender às nossas necessidades de maneira mais eficiente.
THAT`S ALL FOLKS