Do código ao go-live: checklist completo para lançamento em produção

Código pronto ≠ produto no ar.

Realidade: 38% dos lançamentos sofrem incident crítico nas primeiras 72h (Datadog, 2025). Motivo: Falta de checklist de go-live.

O que separa deploy de sucesso de desastre:

• Testes de carga (simular 1000+ usuários)
• Monitoramento (detectar problemas em menor que 2min)
• Rollback automático (reverter em caso de falha)
• Checklist de segurança (OWASP Top 10)

Este artigo mostra checklist completo de go-live — do staging ao production, com ferramentas, scripts e casos reais de lançamentos que deram certo (e errado).

Pre-lançamento: semana antes do go-live

1. Testes de carga (load testing)

Objetivo: Garantir que sistema aguenta pico de usuários sem cair.

Ferramenta recomendada: k6 (open-source, easy to use).

Cenário típico (marketplace de serviços):

• 100 usuários simultâneos navegando
• 20 transações/min (agendamentos)
• 50 requisições/s no backend

Script k6:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // Ramp up para 100 usuários
    { duration: '5m', target: 100 }, // Mantém 100 usuários
    { duration: '2m', target: 200 }, // Spike para 200
    { duration: '3m', target: 0 },   // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)menor que 500'], // 95% requests < 500ms
    http_req_failed: ['ratemenor que 0.01'],   // menor que 1% error rate
  },
};

export default function () {
  // Simula busca de profissionais
  const searchRes = http.get('https://staging.exemplo.com/api/search?q=manicure');
  check(searchRes, {
    'search status 200': (r) => r.status === 200,
    'search fast': (r) => r.timings.duration < 300,
  });

  sleep(1);

  // Simula agendamento
  const bookingRes = http.post('https://staging.exemplo.com/api/bookings', JSON.stringify({
    professionalId: '123',
    date: '2026-08-20T14:00:00Z',
  }), {
    headers: { 'Content-Type': 'application/json' },
  });

  check(bookingRes, {
    'booking status 201': (r) => r.status === 201,
  });

  sleep(2);
}

Executar:

k6 run --vus 100 --duration 12m load-test.js

Métricas de sucesso:

• ✅ P95 latency menor que 500ms (95% das requests levam menor que 500ms)
• ✅ Error rate menor que 1%
• ✅ Throughput maior que 100 req/s
• ✅ Zero crashes (servidor não cai)

Se falhar:

• Otimize queries (índices no banco)
• Aumente recursos (scale up ou horizontal scaling)
• Adicione caching (Redis)

2. Testes de segurança (OWASP Top 10)

Checklist obrigatório:

A01: Broken Access Control

• Usuário A não acessa dados de usuário B (mesmo modificando ID na URL)
• APIs protegidas com autenticação
• Role-based access control (admin vs user)

Teste manual:

# Como user-A (ID 123)
curl -H "Authorization: Bearer token-user-a" \
  https://api.exemplo.com/users/456/profile

# Deve retornar 403 Forbidden (não 200)

A02: Cryptographic Failures

• Senhas com bcrypt/argon2 (nunca plain text)
• HTTPS obrigatório (redirect HTTP → HTTPS)
• Dados sensíveis criptografados no banco

Teste:

# Tentar acessar via HTTP
curl http://exemplo.com

# Deve redirecionar para https://exemplo.com

A03: Injection (SQL Injection)

• Usar ORM (Prisma, TypeORM) ou prepared statements
• Nunca concatenar strings em queries

Teste:

# Tentar SQL injection
curl "https://api.exemplo.com/search?q='; DROP TABLE users;--"

# Deve retornar erro 400 (não executar query)

A04: Insecure Design

• Rate limiting (max 100 requests/min por IP)
• CAPTCHA em forms públicos
• Validação de inputs (backend + frontend)

A07: Identification and Authentication Failures

• MFA disponível
• Lockout após 5 tentativas de login
• Session timeout (logout após 30min inativo)

Ferramenta automatizada: OWASP ZAP.

# Scan automático
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.exemplo.com

3. Testes de regressão (E2E)

Objetivo: Garantir que features antigas não quebraram.

Ferramenta: Playwright (melhor que Selenium).

Exemplo — Fluxo de agendamento:

import { test, expect } from '@playwright/test';

test('fluxo completo de agendamento', async ({ page }) => {
  // 1. Login
  await page.goto('https://staging.exemplo.com/login');
  await page.fill('input[name="email"]', 'teste@exemplo.com');
  await page.fill('input[name="password"]', 'senha123');
  await page.click('button[type="submit"]');

  // 2. Busca
  await page.goto('https://staging.exemplo.com/search');
  await page.fill('input[name="query"]', 'manicure');
  await page.click('button:has-text("Buscar")');

  // 3. Seleciona profissional
  await page.click('text=Maria Silva'); // Nome do profissional

  // 4. Agendar
  await page.click('text=Agendar');
  await page.selectOption('select[name="time"]', '14:00');
  await page.click('button:has-text("Confirmar")');

  // 5. Validar
  await expect(page.locator('text=Agendamento confirmado')).toBeVisible();
});

Executar:

npx playwright test --project=chromium

Mínimo obrigatório:

• Happy path (fluxo ideal funciona)
• 2-3 edge cases (ex: agendar horário já ocupado)

4. Performance: Core Web Vitals

Métricas Google (afetam SEO):

LCP (Largest Contentful Paint): menor que 2,5s

• Maior elemento visível da página
• Otimização: lazy load, CDN, imagens otimizadas

FID (First Input Delay): menor que 100ms

• Tempo até página responder a interação
• Otimização: menos JavaScript, code splitting

CLS (Cumulative Layout Shift): menor que 0,1

• Elementos que “pulam” durante carregamento
• Otimização: definir width/height de imagens

Ferramenta: Google PageSpeed Insights.

# Testar
https://pagespeed.web.dev/

# Ou via CLI
npm install -g lighthouse
lighthouse https://staging.exemplo.com --view

Meta: Score maior que 90 (mobile e desktop).

Go-live: dia do lançamento

Fase 1: Deploy em staging (08h)

Checklist:

• Merge de todas as branches para main
• CI/CD roda testes (unit + E2E)
• Deploy automático para staging
• Smoke test manual (testar 5-10 fluxos críticos)

Fase 2: Backup e preparação (09h)

Backup completo:

# PostgreSQL
pg_dump -U postgres -d production > backup-$(date +%Y%m%d).sql

# Upload para S3
aws s3 cp backup-$(date +%Y%m%d).sql s3://backups/

Preparar rollback:

# Tag da versão atual (antes do deploy)
git tag -a v1.4.2 -m "Pre-launch backup"
git push origin v1.4.2

Fase 3: Deploy em produção (10h)

Opção 1: Blue-Green Deployment

Como funciona:

• Blue (versão atual rodando)
• Green (nova versão em paralelo)
• Testa Green
• Se OK, troca tráfego Blue → Green
• Se falha, mantém Blue

Implementação (AWS com Load Balancer):

# 1. Deploy nova versão (Green)
aws ecs update-service --cluster prod --service api-green \
  --force-new-deployment

# 2. Aguarda health check passar
aws elbv2 wait target-in-service --target-group-arn arn:...

# 3. Redireciona tráfego (gradual: 10% → 50% → 100%)
aws elbv2 modify-listener --listener-arn arn:... \
  --default-actions TargetGroupArn=arn:green,Weight=10

# Aguarda 10min monitorando erros

# 4. Se OK, 100%
aws elbv2 modify-listener --listener-arn arn:... \
  --default-actions TargetGroupArn=arn:green,Weight=100

Opção 2: Canary Release (mais seguro)

Como funciona:

• Deploy para 5% dos usuários
• Monitora métricas por 30min
• Se OK, 25% → 50% → 100%
• Se falha, rollback para 0%

Implementação (Vercel):

# Deploy com alias customizado
vercel --prod --alias canary.exemplo.com

# Configura edge routing (5% tráfego)
# (Vercel UI → Settings → Canary)

# Monitora Sentry, Datadog
# Se error rate menor que 1%, aumenta para 25%

Fase 4: Monitoramento ativo (10h-18h)

Dashboards obrigatórios:

1. Métricas de infra (Datadog, New Relic):

• CPU usage (menor que 70%)
• Memory usage (menor que 80%)
• Request latency (P95 menor que 500ms)
• Error rate (menor que 0,5%)

2. Métricas de negócio (Mixpanel, Amplitude):

• Conversão (cadastros/hora)
• Transações completadas
• Revenue/hora

3. Logs em tempo real (Sentry):

• Errors por minuto (menor que 5)
• Tipos de erro (500s, crashes)

Alertas automáticos:

# Sentry: Alert rules
- condition: error_count > 50 in 5 minutes
  action: notify Slack #incidents
  severity: critical

- condition: p95_response_time > 1000ms
  action: notify Slack #performance
  severity: warning

Fase 5: Rollback (se necessário)

Triggers de rollback:

• Error rate maior que 5%
• P95 latency maior que 2s
• maior que 10 crashes em 10min
• Funcionalidade core quebrada (ex: pagamentos)

Procedimento (Vercel):

# Listar deployments recentes
vercel ls

# Promover deployment anterior
vercel promote deployment-url-anterior --prod

Procedimento (AWS):

# Voltar para tag anterior
git checkout v1.4.2

# Redeploy
git push -f origin main

# Ou via Docker
docker pull exemplo/api:v1.4.2
aws ecs update-service --force-new-deployment

Tempo ideal de rollback: menor que 5 minutos.

Post-lançamento: primeiras 72h

Dia 1 (primeiras 24h)

Monitoramento 24/7:

• On-call engineer (plantão)
• Alertas via Slack/PagerDuty
• Dashboard aberto em TV

Checklist a cada 2h:

• Error rate (menor que 1%)
• Latency (P95 menor que 500ms)
• Conversão (esperado vs real)
• Feedback de usuários (Intercom, e-mails)

Dia 2-3 (ajustes finos)

Análise de performance:

-- Queries lentas (PostgreSQL)
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
WHERE mean_exec_time > 100 -- maior que 100ms
ORDER BY mean_exec_time DESC
LIMIT 20;

Otimizações comuns:

• Adicionar índices
• Cache de queries frequentes (Redis)
• Aumentar pool de conexões do banco

Correções de bugs:

• Deploy de hotfixes (sem esperar sprint)
• Prioridade: bugs que impedem uso (P0)

Semana 1 (retrospectiva)

Métricas de sucesso:

Métrica	Meta	Real	Status
Uptime	maior que 99,5%	99,8%	✅
Error rate	menor que 1%	0,4%	✅
P95 latency	menor que 500ms	320ms	✅
Conversão (sign-up)	maior que 3%	4,2%	✅
NPS (primeiros usuários)	maior que 30	42	✅

Post-mortem (se houve incidents):

## Incident: API down por 12min (Dia 1, 14h20)

**Root cause**: Pool de conexões do Postgres esgotou (max 20, pico de 35 requisições simultâneas)

**Timeline**:
- 14:20: Alertas de timeout no Sentry
- 14:22: Identificado: PG connection pool
- 14:25: Aumentado max_connections de 20 → 50
- 14:32: Serviço normalizado

**Impact**: 38 usuários afetados, 0 transações perdidas

**Ações**:
- [ ] Aumentar pool para 100 (permanente)
- [ ] Adicionar alerta se pool > 80%
- [ ] Load test com 500 usuários (prevenir recorrência)

Ferramentas essenciais

Monitoramento de erros

Sentry (recomendado):

• R$ 0 (5K events/mês)
• R$ 120/mês (50K events)
• Stacktraces, breadcrumbs, user context

Setup (Next.js):

// sentry.client.config.ts
import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1, // 10% das transações
  environment: process.env.NODE_ENV,
});

Monitoramento de performance

Vercel Analytics (Next.js):

• R$ 0 (10K pageviews/mês)
• Core Web Vitals automático
• Real User Monitoring (RUM)

Datadog (enterprise):

• R$ 750/mês (5 hosts)
• APM, logs, infra em 1 lugar
• Alertas customizados

Uptime monitoring

Better Uptime (recomendado):

• R$ 0 (10 monitors)
• Checa site a cada 30s
• Alerta via Slack/SMS se cair

Configuração:

Monitor 1: https://api.exemplo.com/health
  - Check interval: 30s
  - Timeout: 5s
  - Expected: 200 OK

Monitor 2: https://exemplo.com
  - Check interval: 60s
  - Expected: keyword "OrientMe"

Checklist final de go-live

1 semana antes:

• Load test (100+ usuários simulados)
• Security scan (OWASP ZAP)
• E2E tests (Playwright)
• Performance audit (Lighthouse score maior que 90)

1 dia antes:

• Backup completo do banco
• Tag de rollback no Git
• Alertas configurados (Sentry, Better Uptime)
• Canary ou Blue-Green setup

Go-live (dia D):

• Deploy em staging (08h)
• Smoke test manual (09h)
• Deploy em produção (10h)
• Monitoramento ativo (10h-18h)
• Plantão on-call (24h)

Post-lançamento:

• Monitoramento 24h (dia 1)
• Ajustes de performance (dia 2-3)
• Retrospectiva (semana 1)
• Post-mortem se houve incidents

Lançar produto sem checklist = 40% de chance de incident crítico. Com checklist completo = menor que 5%.

Deploy bem-sucedido não é sorte. É preparação.