Infraestrutura e deploy

1. Ambientes explícitos

Desenvolvimento, homologação e produção devem ter credenciais e endpoints distintos — mesmo que “por enquanto” sejam iguais. O mesmo artefato promovido entre estágios reduz surpresas do tipo “build diferente em cada máquina”.

Um arquivo .env.example versionado (sem segredos!) funciona como contrato do que a aplicação espera. Copie para .env localmente e preencha — nunca commite o arquivo com valores reais.

# .env.example — copie para .env e preencha os valores reais
# NUNCA commite o .env no repositório

# Banco de dados
DB_HOST=localhost
DB_PORT=5432
DB_NAME=nome_do_banco
DB_USER=usuario
DB_PASSWORD=          # preencher localmente

# API externa
API_BASE_URL=https://api.servico.com/v1
API_KEY=              # obter no painel do serviço

# Ambiente: development | staging | production
APP_ENV=development

# Logs: DEBUG | INFO | WARNING | ERROR
LOG_LEVEL=INFO

2. Pipeline de deploy

Um pipeline mínimo já bloqueia merges que não passaram por lint ou build. Em projetos ligados à Vercel, você pode disparar deploy na branch principal via CLI em CI — mantendo o mesmo fluxo Git que já usa no Azure DevOps para revisão de código.

O workflow abaixo é um ponto de partida: ajuste nomes de segredos (VERCEL_TOKEN, VERCEL_ORG_ID, VERCEL_PROJECT_ID) conforme o painel da Vercel e as boas práticas da sua organização.

# .github/workflows/deploy.yml
name: Deploy para Vercel

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Instalar Vercel CLI
        run: npm install -g vercel

      - name: Deploy producao
        run: vercel --prod --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

• Pré-deploy: smoke mínimo ou testes automatizados; bloqueie artefatos que falharam.
• Rollback: mantenha release anterior endereçável (tag, container ou deploy da Vercel com promoção reversível).
• Migrações: planeje compatibilidade entre versões antiga e nova do banco quando aplicável (expand/contract).

3. Monitoramento e alertas

Combine métricas (latência, erros 5xx, uso de CPU), logs centralizados e, quando o sistema crescer, tracing distribuído. Alertas devem ser acionáveis: indicar quem responde, um runbook curto e severidade clara — não adianta página às 3h se ninguém sabe o que reiniciar.

Um exemplo de regra simples em texto (adaptável ao seu provedor de métricas):

4. Segurança operacional

Rotação de chaves, menor privilégio em IAM, patches em SO e dependências: segredos nunca no Git — use cofre ou variáveis do provedor com escopo por ambiente. Backup sem teste de restauração é apenas esperança; agende restore parcial em homologação com periodicidade definida.

No front estático na Vercel, políticas de cache para assets imutáveis e cabeçalhos de segurança reduzem superfície de ataque sem alterar o HTML da página. O exemplo integra cleanUrls, redirecionamento de /index.html para /, headers globais e cache longo para /assets — alinhado ao que já uso na configuração do portfólio.

{
  "cleanUrls": true,
  "trailingSlash": false,
  "redirects": [
    {
      "source": "/index.html",
      "destination": "/",
      "permanent": true
    }
  ],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        {
          "key": "Referrer-Policy",
          "value": "strict-origin-when-cross-origin"
        }
      ]
    },
    {
      "source": "/assets/(.*)",
      "headers": [
        {
          "key": "Cache-Control",
          "value": "public, max-age=31536000, immutable"
        }
      ]
    }
  ]
}

5. Cultura de incidentes

Post-mortem blameless: linha do tempo factual, causa raiz e itens de ação com dono e prazo. Pequenas melhorias contínuas vencem reformas anuais de infraestrutura que ninguém mantém depois do grande dia.

Em times que já usam Azure DevOps para gestão de trabalho, associate incidentes a work items evita perder o aprendizado em chats soltos.

Checklist e erros comuns em deploy

Erros recorrentes e o impacto típico quando ignorados:

• Variável obrigatória ausente em produção — build passa, runtime falha na primeira requisição real.
• Migração de banco sem plano de rollback — downtime prolongado ou dados inconsistentes durante deploy longo.
• Logs apenas em stdout sem retenção — impossível reconstruir linha do tempo após reinício de instância.
• Alerta genérico (“servidor lento”) — on-call desiste de priorizar; incidente real mistura-se com ruído.
• Segredo commitado “por engano” — mesmo revertido, histórico público exige rotação imediata da credencial.
• Deploy sem smoke manual em uma URL crítica — erro 500 só aparece quando o cliente tenta checkout ou login.
• Falta de comunicação no canal de releases — suporte não sabe qual versão está no ar durante incidente.
• Dependência de uma única pessoa para liberar — gargalo humano vira SPOF tão grave quanto servidor único.

Use também uma checklist textual antes de encerrar o dia do deploy — pode viver no repositório como comentário em script ou em README:

# CHECKLIST POS-DEPLOY
# [ ] Smoke test: acessar páginas principais manualmente
# [ ] Verificar que variáveis de ambiente de produção estão ativas
# [ ] Confirmar que o deploy anterior ainda está acessível (rollback)
# [ ] Checar logs dos primeiros 10 minutos pós-deploy
# [ ] Verificar taxa de erro (5xx) no dashboard de monitoramento
# [ ] Notificar o time no canal de deploy com: versão, autor, mudança

Conclusão

Deploy previsível combina ambientes explícitos, pipeline repetível e observabilidade que responde “o que mudou?” antes de buscar culpados. Integrar Git, Azure DevOps e Vercel no mesmo hábito de releases pequenas reduz o drama dos deploys “big bang” e mantém o foco no usuário final.

O próximo passo natural é medir MTTR e taxa de rollback por quarter — números honestos guiam onde investir em testes automatizados ou em melhorias de observabilidade antes de escalar infraestrutura cara.

Para se aprofundar

• Documentação oficial da Vercel — projetos, domínios, variáveis e integrações com Git.
• GitHub Actions — guia de início — workflows, segredos e runners hospedados.
• The Twelve-Factor App (PT) — metodologia alinhada a apps cloud-native e deploy repetível.
• Google SRE Book — cultura de post-mortem — foco em aprendizado sem culpa individual.