CI/CD na prática: como o pipeline de deploy da Nexus G garante que só código testado chega à produção

No artigo anterior, expliquei os quatro níveis de teste que sustentam a Nexus G unitário, integração, e2e e regressão de performance. Mas teste que só roda quando alguém lembra de rodar manualmente não protege nada de verdade. A peça que fecha esse ciclo é o pipeline de integração contínua: a automação que decide, sem depender de memória humana, se um código está pronto pra ir ao ar.

O princípio por trás de CI/CD é simples de enunciar e difícil de sustentar na prática: nenhuma mudança chega à produção sem antes passar, de forma automática, pelas mesmas verificações que qualquer outra mudança passou. Isso elimina a variação de "dessa vez eu testei com calma, da próxima eu tava com pressa e pulei uma etapa" o pipeline não sabe se você está com pressa, ele roda a mesma sequência de verificação sempre.

Na Nexus G, esse pipeline dispara a cada push pra branch principal e segue uma ordem específica, pensada pra falhar rápido no problema mais barato de corrigir antes de gastar tempo com o mais caro:

# .github/workflows/deploy.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main]

jobs:
  lint-and-typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck

  unit-and-integration-tests:
    needs: lint-and-typecheck
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test

  e2e-tests:
    needs: unit-and-integration-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run test:e2e

  lighthouse-check:
    needs: e2e-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - run: npx lhci autorun

  deploy:
    needs: lighthouse-check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - run: npm run deploy

Repare na ordem: lint e checagem de tipo vêm primeiro porque são os mais rápidos de rodar e pegam o erro mais barato um typo, uma tipagem quebrada antes de gastar tempo de máquina com qualquer coisa mais pesada. Testes unitários e de integração vêm em seguida, validando lógica isolada e a comunicação entre partes, incluindo as políticas de Row Level Security que detalhei no artigo sobre arquitetura de dados. Só depois disso os testes end-to-end sobem um ambiente completo e simulam o usuário navegando de verdade, porque são os mais lentos de executar. E a checagem de Lighthouse fecha a bateria de verificação, comparando as métricas de Core Web Vitals com o baseline aceitável antes de qualquer deploy se uma mudança derruba o LCP ou o INP, o pipeline barra ali, antes que o problema chegue ao usuário real.

Cada etapa depende do sucesso da anterior é o que o needs faz no pipeline acima então uma falha de lint nunca deixa passar pra rodar testes que vão custar mais tempo de máquina. E se qualquer etapa falhar, o deploy simplesmente não acontece: não existe deploy manual "por fora" que ignore essa verificação, porque o próprio processo de publicação está amarrado ao sucesso de tudo que veio antes.

O ganho real disso, na prática de manter um projeto sozinho, é psicológico tanto quanto técnico. Sem pipeline, cada mudança de código carrega uma dúvida: será que isso quebrou alguma coisa que eu não tenho como lembrar de checar manualmente? Com o pipeline rodando, essa dúvida vira uma resposta objetiva, visível antes mesmo do deploy o código passou ou não passou pela bateria completa de verificação. Isso é o que permite continuar publicando conteúdo, ajustando o Design System, e mexendo na estrutura de dados da Nexus G com confiança de que qualquer regressão será pega automaticamente, muito antes de virar um problema visível pra quem usa a plataforma.