MÓDULO 4.6

🚢 CI/CD e Deploy Profissional

Com vibe coding, CI/CD passa de conveniência para necessidade. Cada linha de código gerada por IA precisa passar por um pipeline de qualidade antes de chegar à produção — feature flags, rollback automático e monitoramento incluídos.

7
Tópicos
35
Minutos
Avançado
Nível
DevOps
Tipo
1

⚙️ Por que CI/CD é ainda mais importante com vibe coding

Em desenvolvimento tradicional, CI/CD captura bugs que humanos introduzem por descuido. Em vibe coding, CI/CD captura bugs que agentes introduzem por falta de contexto ou instrução ambígua. O pipeline é a verificação objetiva que o agente não consegue fazer por si mesmo — e sem ele, cada push é uma aposta.

✗ Sem CI/CD — o que pode acontecer

  • Agente faz push com TypeScript errors não percebidos
  • Testes quebram silenciosamente após refactoring
  • Vulnerabilidade de segurança vai direto para produção
  • Build falha em produção por falta de variável de ambiente
  • Bug sutil descoberto por usuário 3 dias após o deploy

✓ Com CI/CD — o que é capturado automaticamente

  • TypeScript errors e violações de lint no PR
  • Regressões detectadas antes do merge
  • Padrões de vulnerabilidade bloqueados pelo SAST
  • Build verificado em ambiente limpo e isolado
  • Deploy só ocorre após todos os gates passarem

📊 Taxa de Escape de Bugs — Com vs. Sem CI/CD em Projetos de Vibe Coding

Bugs que chegam à produção (sem CI/CD) 68%
Bugs que chegam à produção (com CI/CD básico) 22%
Bugs que chegam à produção (com CI/CD + SAST + cobertura) 8%

Estimativa baseada em análise de projetos com Claude Code (2025)

💡 O Pipeline como Segundo Revisor

Pense no CI/CD como um revisor de código que nunca cansa, nunca esquece um check e nunca aprova código que quebra testes. Para equipes de vibe coding, o pipeline é o segundo par de olhos mais confiável — diferentemente do humano, ele executa os mesmos checks toda vez, sem variação.

2

⚙️ GitHub Actions — workflow completo gerado por IA

O GitHub Actions é a ferramenta padrão de CI/CD para projetos de vibe coding por integrar nativamente com o repositório, ser gratuito para projetos privados (2.000 min/mês) e ser facilmente gerado por IA. Peça para o agente criar o workflow completo — de lint a deploy.

⚙️ Workflow Completo para Projeto de Vibe Coding

Lint + Type check + Testes + Cobertura + SAST + Deploy — tudo em um arquivo

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

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  # JOB 1: Qualidade de código
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'         # Cache de dependências — builds 3x mais rápidos

      - run: npm ci             # Instala dependências de forma determinística

      - name: Lint e formatação
        run: npm run lint        # ESLint + Prettier check

      - name: TypeScript type check
        run: npx tsc --noEmit    # Verifica tipos sem gerar arquivos

      - name: Testes unitários + integração
        run: npm run test:coverage
        env:
          DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}
          NODE_ENV: test

      - name: Upload cobertura para Codecov
        uses: codecov/codecov-action@v4
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          fail_ci_if_error: true   # Falha se cobertura abaixo do threshold

  # JOB 2: Segurança (roda em paralelo com quality)
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Semgrep SAST
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/owasp-top-ten
            p/javascript

  # JOB 3: Deploy (só roda se quality E security passarem)
  deploy:
    needs: [quality, security]    # Gates obrigatórios
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to Vercel (produção)
        run: npx vercel --prod --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

      - name: Notificar Sentry do novo deploy
        run: |
          curl -X POST "https://sentry.io/api/0/organizations/${{ secrets.SENTRY_ORG }}/releases/" \
            -H "Authorization: Bearer ${{ secrets.SENTRY_AUTH_TOKEN }}" \
            -d '{"version": "${{ github.sha }}", "projects": ["${{ secrets.SENTRY_PROJECT }}"]}'

📋 Prompt para Gerar Este Workflow

"Crie um GitHub Actions workflow completo para meu projeto.

Stack: Node.js 22 + TypeScript + Vitest + Vercel

Requisitos:
- Job 'quality': lint (ESLint), type check (tsc), tests com cobertura (Vitest),
  upload para Codecov
- Job 'security': Semgrep com p/security-audit, p/secrets, p/owasp-top-ten
- Job 'deploy': Vercel prod, só em push para main, requer quality E security
- Notificar Sentry de novo deploy após deploy bem-sucedido
- Cache de npm para builds rápidos
- Usar secrets para tokens e URLs de banco

Crie o arquivo em .github/workflows/ci.yml"
3

🔍 SAST no pipeline — análise de segurança em cada PR

SAST (Static Application Security Testing) no pipeline transforma segurança de uma fase final para um processo contínuo. Código gerado por IA pode replicar padrões inseguros conhecidos — SAST os detecta antes de qualquer código chegar à produção.

🔍 Adicionando Snyk + Semgrep ao Pipeline

  # Adicione ao job 'security' no ci.yml existente:

  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Semgrep: padrões de código inseguro (OWASP, secrets)
      - name: Semgrep SAST
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/owasp-top-ten
            p/javascript
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

      # Snyk: vulnerabilidades em dependências (npm packages)
      - name: Snyk — dependências vulneráveis
        uses: snyk/actions/node@master
        with:
          args: --severity-threshold=high  # só bloqueia HIGH e CRITICAL
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      # CodeQL: análise profunda de fluxo de dados (GitHub nativo, gratuito)
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript-typescript
          queries: security-extended
      - uses: github/codeql-action/analyze@v3

📊 O Que é Detectado em Cada Estágio

Ferramenta Detecta Quando
ESLint + no-eval, no-new-func Uso de eval(), injeção via string Em cada PR (job quality)
Semgrep p/secrets API keys, tokens hardcoded no código Em cada PR (job security)
Semgrep p/owasp-top-ten SQLi, XSS, path traversal, SSRF Em cada PR (job security)
Snyk CVEs em dependências npm Em cada PR (job security)
CodeQL Fluxos de dados inseguros entre arquivos No merge para main

⚠️ Não Bloqueie Deploys com Falsos Positivos

SAST tem falsos positivos. Se você configurar todas as ferramentas como bloqueadoras estritas, sua equipe vai começar a suprimir alertas em massa — destruindo o valor do sistema. Estratégia recomendada:

  • Semgrep p/secrets: sempre bloqueador — segredos hardcoded são inaceitáveis
  • Snyk HIGH/CRITICAL: bloqueador — dependências com CVE grave não devem ir para prod
  • CodeQL e Semgrep geral: alertas visíveis, mas não bloqueadores no PR — revise semanalmente
4

🚀 Deploy automático com Vercel/Railway

Vercel e Railway são as plataformas de deploy padrão para projetos de vibe coding por sua integração nativa com GitHub, zero configuração de infraestrutura e deploy automático a cada push. Cada merge em main dispara deploy automático — sem intervenção humana.

Vercel — 3 Passos para Deploy Automático

1

Conectar repositório

vercel.com → "Add New Project" → selecionar repo GitHub → Next.js/Vite detectado automaticamente

2

Configurar variáveis de ambiente

Settings → Environment Variables → adicionar DATABASE_URL, NEXTAUTH_SECRET, etc. para Production e Preview

3

Deploy automático ativado

Cada push para main = deploy de produção. Cada PR = preview deploy com URL única para revisão.

Railway — 3 Passos para APIs e Workers

1

Criar projeto com template

railway.app → "New Project" → Deploy from GitHub repo → Railway detecta Node.js e cria Dockerfile automaticamente

2

Adicionar PostgreSQL e Redis

New Service → PostgreSQL → Railway injeta DATABASE_URL automaticamente no ambiente. Redis da mesma forma.

3

Configurar health check

Settings → Deploy → Health Check Path: /health. Railway valida que app está saudável antes de trocar o tráfego.

📊 Vercel vs. Railway — Quando Usar Cada Um

Critério Vercel Railway
Melhor para Frontend, Next.js, Edge Functions APIs Node.js, workers, microserviços
Banco de dados Use Supabase/Neon externo PostgreSQL + Redis nativos
Preview deploys Automático por PR — cada PR ganha URL Configurável por ambiente
Processos long-running Não (serverless apenas) Sim, containers persistentes
Plano gratuito Hobby: 100GB banda/mês Trial: $5 crédito único
Custo estimado (produção) $20/mês (Pro) $5-15/mês (Hobby/Pro)
5

🚩 Feature flags — liberando código de IA gradualmente

Feature flags permitem deploar código de IA em produção mas ativá-lo apenas para subconjuntos controlados de usuários. Se algo der errado, você desliga o flag sem rollback de código. É a estratégia de release mais segura para vibe coding — especialmente para features críticas.

🚩 Implementação de Feature Flag em TypeScript

// src/lib/feature-flags.ts
type UserId = string;

interface FeatureFlags {
  newCheckoutFlow: boolean;
  aiRecommendations: boolean;
  betaDashboard: boolean;
}

// Flags simples por variável de ambiente (rollout global on/off)
export const flags: FeatureFlags = {
  newCheckoutFlow: process.env.FF_NEW_CHECKOUT === 'true',
  aiRecommendations: process.env.FF_AI_RECS === 'true',
  betaDashboard: process.env.FF_BETA_DASHBOARD === 'true',
};

// Flags com rollout percentual (por userId)
export function isInRollout(userId: UserId, flagName: string, percent: number): boolean {
  // Hash determinístico: mesmo user sempre cai no mesmo grupo
  const hash = userId.split('').reduce((acc, c) => acc + c.charCodeAt(0), 0);
  return (hash % 100) < percent;
}

// Uso no componente / handler
export function getCheckoutComponent(userId: UserId) {
  if (flags.newCheckoutFlow && isInRollout(userId, 'newCheckout', 25)) {
    return NewCheckout;  // 25% dos usuários veem o novo checkout
  }
  return OldCheckout;
}

📋 Prompt para Adicionar Feature Flags a uma Feature Existente

"Adicione feature flag para o novo fluxo de checkout.

@src/pages/checkout.tsx
@src/lib/feature-flags.ts

Requisitos:
- Flag chamado FF_NEW_CHECKOUT (variável de ambiente booleana)
- Rollout percentual por userId (começa em 10%)
- Se flag desligado, usa OldCheckout sem nenhuma mudança de comportamento
- Adicione log de analytics quando usuário entra no grupo de teste
- NÃO modifique OldCheckout — apenas envolva com o flag"

💡 Estratégia de Rollout Gradual para Código de IA

Código gerado por IA pode ter bugs sutis que só aparecem com dados reais de produção. O rollout gradual limita o blast radius:

1%
Equipe interna (dogfood)
10%
Usuários beta voluntários
50%
Release parcial + monitoramento 24h
100%
Release completo (48h estável)

✗ Não faça com features de IA

  • Deploy de 100% de uma vez sem teste gradual
  • Feature flag que muda schema do banco (irreversível)
  • Remover o código antigo antes de validar o novo
  • Feature flag que afeta fluxos de pagamento sem revisão manual

✓ Boas práticas com feature flags

  • Rollout gradual com métricas monitoradas em cada etapa
  • Flags sempre reversíveis sem novo deploy
  • Remova flags antigos após 100% de rollout estável
  • Documente cada flag com data de criação e propósito
6

⏪ Rollback automático — revertendo quando métricas degradam

Rollback automático é a capacidade de reverter um deploy quando métricas de saúde do sistema degradam além de um threshold. Em projetos de vibe coding, onde código gerado pode ter bugs sutis que só aparecem em produção com dados reais, rollback automático é a última linha de defesa.

🌲 Árvore de Decisão para Rollback Automático

!
Taxa de erro HTTP 5xx > 2% → rollback imediato (baseline esperado: <0.1%)
!
Latência P99 > 3s → rollback imediato (baseline esperado: <500ms)
?
Taxa de conversão caiu > 15% vs. média 7 dias → alerta + avaliação manual (pode ser sazonalidade)
?
Erros JS no browser > 5% → alerta + investigação (pode ser browser específico)

Health Check Endpoint — Base para Rollback Automático

// src/routes/health.ts
import { Router } from 'express';
import { db } from '../lib/database';

const router = Router();

router.get('/health', async (req, res) => {
  try {
    // Verifica conexão com banco
    await db.$queryRaw`SELECT 1`;

    res.json({
      status: 'ok',
      timestamp: new Date().toISOString(),
      version: process.env.npm_package_version,
      uptime: process.uptime(),
    });
  } catch (error) {
    // Retorna 503 — Railway/Vercel detectam e param o tráfego
    res.status(503).json({
      status: 'degraded',
      error: 'Database connection failed',
    });
  }
});

export default router;

Rollback no Vercel

# Via CLI — rollback para deployment anterior
vercel rollback [deployment-url]

# Listar deployments disponíveis
vercel ls --prod

Vercel mantém histórico de deployments. Rollback é instantâneo — apenas aponta DNS para deployment anterior sem rebuild.

Rollback no Railway

# Railway Dashboard:
# Deployments → selecionar deploy anterior
# → "Rollback to this deployment"

# Ou via Railway CLI:
railway rollback [deployment-id]

Railway usa containers — rollback reativa o container anterior. Configure health check em Settings → Deploy para validação automática.

⚠️ Migrations de Banco e Rollback — O Ponto Crítico

Rollback de código é trivial. Rollback de schema de banco é perigoso. Se um deploy incluiu uma migration que removeu uma coluna ou tabela, reverter o código sem reverter o banco causa erros imediatos no código antigo.

Regra: sempre use migrations expansivas (additive only) com vibe coding. Adicione nova coluna, migre dados, só então remova a antiga em um deploy posterior. Nunca remova e adicione no mesmo deploy.

7

📡 Monitoramento pós-deploy — Sentry, analytics e alertas

Código gerado por IA pode ter bugs que passam por todos os checks mas só aparecem com tráfego real e dados de produção. Monitoramento pós-deploy é o último guardrail do processo de vibe coding profissional — e o que garante que você saiba antes dos usuários.

📊 Ferramentas de Monitoramento — Stack Recomendado

Ferramenta Detecta Custo Prioridade
Sentry Erros runtime, exceções não tratadas, performance issues Grátis até 5K erros/mês Obrigatório
Vercel Analytics Web Vitals (LCP, CLS, FID), performance por página Incluso no plano Pro Recomendado
Railway Metrics CPU, memória, latência HTTP, container health Incluso no Railway Recomendado
PostHog Analytics de produto, funis, feature flag analytics, sessões Grátis até 1M eventos/mês Opcional
Pino.js + LogTail Logs estruturados, rastreamento de requests LogTail grátis até 1GB/mês Opcional

Adicionando Sentry em um Prompt

"Adicione Sentry ao projeto Next.js.

Requisitos:
- Instale @sentry/nextjs
- Configure captura de erros em client e server
- Remova dados sensíveis (senha, cartão)
  antes de enviar para o Sentry
- Adicione SENTRY_DSN ao .env.example
- Crie sentry.client.config.ts e
  sentry.server.config.ts conforme docs

@package.json @next.config.ts"

Sentry Configurado com Privacidade

// sentry.config.ts
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1, // 10% das transações
  beforeSend(event) {
    // Remove dados sensíveis
    if (event.request?.data) {
      delete event.request.data.password;
      delete event.request.data.creditCard;
    }
    return event;
  },
});

Configuração de Alertas Essenciais no Sentry

Alerta crítico — Slack imediato

Novo erro nunca visto antes (first seen) + taxa > 10 ocorrências/min

Alerta de regressão — Email

Erro resolvido que voltou a ocorrer (regression) em até 24h após deploy

Digest diário — Email

Resumo dos 10 erros mais frequentes das últimas 24h — para priorização

💡 O Que Monitorar Especificamente em Código Gerado por IA

Código gerado por IA tem padrões de falha distintos do código humano. Foque o monitoramento em:

  • Edge cases de dados reais: o agente testou com dados mockados — monitore erros com dados reais de produção nas primeiras 48h
  • Performance em escala: algoritmos corretos mas ineficientes aparecem quando há volume. Monitore queries lentas e memory usage
  • Erros de tipo em runtime: TypeScript estrito no build, mas dados externos (APIs, banco) podem surpreender. Monitore TypeErrors especificamente
  • Mudanças de comportamento sutis: a feature "funciona" mas a taxa de conversão caiu. PostHog com funis é essencial para detectar isso

Resumo do Módulo 4.6

CI/CD é mais crítico com IA — sem pipeline, bugs escapam 8x mais. O pipeline é a verificação objetiva que o agente não faz por si mesmo.
Workflow completo gerado por IA — Lint + Type check + Testes + Cobertura + SAST + Deploy. Jobs paralelos, deploy só após todos os gates.
SAST inteligente — Semgrep (secrets + OWASP), Snyk (dependências), CodeQL (fluxo de dados). Não bloqueie deploys com falsos positivos.
Vercel vs. Railway — Vercel para frontend/Next.js + preview deploys por PR. Railway para APIs + banco nativo + workers.
Feature flags para release seguro — rollout gradual 1% → 10% → 50% → 100%. Flags reversíveis sem novo deploy.
Rollback automático — 5xx > 2% ou P99 > 3s = rollback imediato. Atenção: migrations de banco não revertem com o código.
Stack de monitoramento — Sentry (obrigatório) + Vercel Analytics + Railway Metrics. Monitore TypeErrors e performance nas primeiras 48h de cada deploy.

Próximo Módulo:

4.7 — 🤖 Agentes Autônomos e Multi-Agent: orquestração de agentes, paralelismo e o futuro do desenvolvimento de software em 2026