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.