Visão Geral de Deploy

Estratégia de deploy multi-ambiente para o BITIO, cobrindo infraestrutura AWS, CI/CD e estratégias de rollback.

Arquitetura de Deploy

graph TB
    subgraph "Development"
        Dev[Desenvolvimento Local]
        Feature[Feature Branches]
    end
    
    subgraph "GitLab CI/CD"
        Pipeline[Pipeline GitLab]
        Artifacts[Artefatos]
    end
    
    subgraph "Staging"
        StagingS3[S3 Staging]
        StagingLambda[Lambda Staging]
        StagingRDS[RDS Staging]
    end
    
    subgraph "Production"
        ProdS3[S3 Production]
        ProdLambda[Lambda Production]
        ProdRDS[RDS Production]
        ProdWorker[Worker Production]
    end
    
    Dev --> Pipeline
    Feature --> Pipeline
    Pipeline --> Artifacts
    
    Artifacts --> StagingS3
    Artifacts --> StagingLambda
    Artifacts --> StagingRDS
    
    StagingS3 -.-> ProdS3
    StagingLambda -.-> ProdLambda
    StagingRDS -.-> ProdRDS
    Artifacts -.-> ProdWorker

Unidades de Deploy

1. Frontend (Next.js)

• Build: next build + export estático
• Deploy: AWS S3 + CloudFront
• Estratégia: Blue-green via invalidação do CDN
• Rollback: Redeploy da versão anterior

2. Lambda API (Node.js + TypeScript)

• Build: esbuild bundle + zip
• Deploy: AWS Lambda versioning + alias
• Estratégia: Canary deployment com weighted routing
• Rollback: Shift alias para versão anterior (instantâneo)

3. Worker (Node.js + Docker)

• Build: Docker image + ECR
• Deploy: EC2 systemd (inicial) → ECS Fargate (escala)
• Estratégia: Rolling update
• Rollback: Container anterior via tag SHA

4. Database (PostgreSQL)

• Migrations: Prisma migrate deploy
• Deploy: Sempre antes das aplicações
• Estratégia: Expand/contract pattern
• Rollback: Migrations compatíveis com versão anterior

---

Ambientes

Development

• Propósito: Desenvolvimento local
• Infraestrutura: Docker local + banco SQLite/Postgres local
• Deploy: Manual via npm run dev

Staging

• Propósito: Testes integrados, QA, preview
• Infraestrutura: Réplica reduzida da produção
• Deploy: Automático em push para develop
• Dados: Sintéticos/anonimizados

Production

• Propósito: Ambiente live para clientes
• Infraestrutura: Full AWS multi-AZ
• Deploy: Manual com aprovação em tags vX.Y.Z
• Dados: Dados reais, backup automatizado

---

Estratégias de Deploy por Componente

Frontend: Blue-Green via CDN

sequenceDiagram
    participant Dev as Developer
    participant CI as GitLab CI
    participant S3 as S3 Bucket
    participant CF as CloudFront
    participant User as Users

    Dev->>CI: Push to main + tag
    CI->>CI: Build Next.js
    CI->>S3: Sync new assets
    CI->>CF: Create invalidation
    CF->>User: Serve new version

Vantagens:

• Deploy atômico
• Zero downtime
• Rollback rápido

Lambda: Canary Deployment

graph LR
    subgraph "API Gateway"
        Route[Route /api/*]
    end
    
    subgraph "Lambda Versions"
        V1[Version 1<br/>90% traffic]
        V2[Version 2<br/>10% traffic]
    end
    
    Route --> V1
    Route --> V2
    
    V2 -.-> V1
    
    style V2 fill:#e1f5fe
    style V1 fill:#f3e5f5

Processo:

1. Deploy nova versão
2. Direcionar 10% do tráfego
3. Monitorar métricas por 5-10 minutos
4. Se OK: promover para 100%
5. Se erro: rollback instantâneo

Worker: Rolling Update

EC2 (Fase inicial):

# Via SSM, sem SSH
aws ssm send-command \
  --targets "Key=tag:Role,Values=bitio-worker" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["systemctl restart bitio-worker"]'

ECS (Fase de escala):

• Atualizar task definition
• Rolling update automático
• Health checks obrigatórios
• Drain connections antes de parar

---

Pipeline de Qualidade

Gates Obrigatórios

Stage	Gate	Bloqueia Deploy?
Lint	ESLint, Prettier, TypeCheck	✅ Sim
Unit Tests	Jest/Vitest >80% coverage	✅ Sim
Integration	API + DB tests	✅ Sim
Security	npm audit, SAST	⚠️ Warning
E2E	Playwright (staging only)	✅ Sim (staging)

Exemplo de Gate

quality_gate:
  stage: test
  script:
    - npm run lint        # ESLint + Prettier
    - npm run type-check  # TypeScript
    - npm run test:unit   # Jest com coverage
    - npm audit --audit-level high
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

---

Monitoramento de Deploy

Métricas Críticas Pós-Deploy

Métrica	Threshold	Ação
Lambda Error Rate	> 1% em 5 min	Rollback automático
Response Time p95	> 3s	Investigação
Frontend 5xx	> 0.5%	Verificar S3/CloudFront
Worker Health Check	Fail por > 2 min	Restart automático

Dashboard de Deploy

// Exemplo de métricas a monitorar
interface DeployMetrics {
  timestamp: Date;
  version: string;
  environment: 'staging' | 'production';
  
  // Lambda
  lambdaErrors: number;
  lambdaLatencyP95: number;
  lambdaColdStarts: number;
  
  // Frontend
  cloudFrontCacheHitRate: number;
  s3Errors: number;
  
  // Worker
  workerHealthy: boolean;
  workerCpuUsage: number;
  workerMemoryUsage: number;
  
  // Database
  rdsConnections: number;
  rdsLatency: number;
}

---

Rollback Procedures

Rollback Automático

Lambda: Configurado no alias weighted routing

# Se error rate > threshold por X minutos
aws lambda update-alias \
  --function-name bitio-api \
  --name prod \
  --function-version $PREVIOUS_STABLE_VERSION

Rollback Manual

Frontend:

# 1. Checkout da tag anterior
git checkout v1.2.3

# 2. Redeploy
npm run build
aws s3 sync dist/ s3://bitio-frontend/ --delete
aws cloudfront create-invalidation --distribution-id $CF_ID --paths "/*"

Worker:

# 1. Via SSM
aws ssm send-command \
  --targets "Key=tag:Role,Values=bitio-worker" \
  --parameters 'commands=["docker run -d --name bitio-worker $ECR_REPO:$PREVIOUS_SHA"]'

Rollback Database

Princípio: Migrations devem ser sempre backward compatible

-- ❌ Quebra compatibilidade
ALTER TABLE users DROP COLUMN old_field;

-- ✅ Compatível (expand/contract)
-- Deploy 1: Adicionar nova coluna
ALTER TABLE users ADD COLUMN new_field VARCHAR(255);

-- Deploy 2 (após migrar aplicação): Remover antiga
-- ALTER TABLE users DROP COLUMN old_field;

---

Segurança de Deploy

IAM Roles (Least Privilege)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LambdaDeploy",
      "Effect": "Allow", 
      "Action": [
        "lambda:UpdateFunctionCode",
        "lambda:PublishVersion",
        "lambda:UpdateAlias"
      ],
      "Resource": "arn:aws:lambda:sa-east-1:*:function:bitio-*"
    },
    {
      "Sid": "S3Deploy",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::bitio-frontend/*",
        "arn:aws:s3:::bitio-frontend"
      ]
    }
  ]
}

Branch Protection

• main: Requer PR + aprovação + status checks
• develop: Auto-deploy para staging
• Tags vX.Y.Z: Deploy manual para produção

Secrets Management

# GitLab CI Variables (Protected + Masked)
variables:
  AWS_ROLE_ARN: "arn:aws:iam::123456789:role/GitLabCIRole"
  DATABASE_URL_STAGING: $DATABASE_URL_STAGING  # Protected
  DATABASE_URL_PROD: $DATABASE_URL_PROD        # Protected + Masked
  SLACK_WEBHOOK: $SLACK_WEBHOOK                # Masked

---

Disaster Recovery

RTO/RPO Targets

Componente	RTO (Recovery Time)	RPO (Data Loss)
Frontend	< 5 minutos	0 (estado stateless)
Lambda API	< 2 minutos	0 (estado stateless)
Worker	< 10 minutos	< 15 minutos
Database	< 30 minutos	< 5 minutos

Backup Strategy

• RDS: Backup automático + snapshots manuais
• S3: Cross-region replication (opcional)
• Configurações: Infrastructure as Code (Terraform)
• Dados críticos: Export regular para S3

---

Checklist de Deploy

Pré-Deploy

• Testes passando em staging
• Migrations testadas
• Rollback plan definido
• Monitoramento configurado
• Comunicação aos stakeholders

Durante Deploy

• Monitorar métricas em tempo real
• Verificar logs de erro
• Confirmar health checks
• Testar funcionalidades críticas

Pós-Deploy

• Smoke tests automáticos
• Verificação manual de funcionalidades
• Monitoramento estendido (15-30 min)
• Comunicar sucesso/falha
• Documentar issues encontradas

Este processo garante deploys seguros, monitrados e com rollback rápido para todos os componentes do sistema.