Boas práticas de separação de ambientes dev, staging e prod

1. Fundamentos da separação de ambientes

A separação adequada entre ambientes de desenvolvimento (dev), homologação (staging) e produção (prod) é um dos pilares da engenharia de software moderna. Cada ambiente possui um propósito específico:

  • Dev: ambiente para desenvolvimento ativo, onde código é criado, testado unitariamente e integrado. Aqui, a velocidade é prioridade, e falhas são esperadas.
  • Staging: réplica fiel de produção, usada para testes de integração, validação de performance e aprovação de releases. Deve ser o mais próximo possível de prod.
  • Prod: ambiente que atende usuários finais. Estabilidade, segurança e disponibilidade são os requisitos máximos.

Os riscos de ambientes mal segregados são severos: contaminação de dados de produção por testes, vazamento de chaves de API, falhas catastróficas por deploy de código não validado. O princípio da imutabilidade — onde artefatos são construídos uma vez e promovidos entre ambientes sem alterações — garante consistência e rastreabilidade.

# Exemplo de manifesto de ambiente (YAML conceitual)
environments:
  dev:
    purpose: "Desenvolvimento ativo"
    data: "Sintética"
    uptime_sla: 99%
    access: "Desenvolvedores + CI"
  staging:
    purpose: "Homologação e testes finais"
    data: "Mascarada de prod"
    uptime_sla: 99.5%
    access: "QA + DevOps + Revisores"
  prod:
    purpose: "Atendimento a usuários"
    data: "Real"
    uptime_sla: 99.99%
    access: "SRE + Suporte autorizado"

2. Configurações e variáveis de ambiente

Variáveis de ambiente são o mecanismo padrão para parametrizar aplicações sem hardcode. Conexões de banco, chaves de API, URLs de serviços externos — tudo deve ser injetado via variáveis.

# .env.dev
DB_HOST=localhost
DB_PORT=5432
DB_NAME=app_dev
API_KEY=dev_key_123
LOG_LEVEL=debug

# .env.staging
DB_HOST=staging-db.internal
DB_PORT=5432
DB_NAME=app_staging
API_KEY=staging_key_456
LOG_LEVEL=info

# .env.prod
DB_HOST=prod-db.internal
DB_PORT=5432
DB_NAME=app_prod
API_KEY=${VAULT_API_KEY}
LOG_LEVEL=warn

Para gerenciar segredos, utilize serviços como HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault. Nunca versionar arquivos .env com dados sensíveis. O versionamento deve conter apenas templates:

# .env.template (versionado)
DB_HOST=
DB_PORT=
DB_NAME=
API_KEY=
LOG_LEVEL=

3. Isolamento de infraestrutura e recursos

O isolamento pode ser físico (servidores dedicados) ou lógico (VPCs, namespaces Kubernetes, contêineres). A abordagem moderna favorece isolamento lógico com políticas de rede restritivas.

# Exemplo de isolamento com namespaces Kubernetes
kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace prod

# Política de rede: staging não acessa prod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-staging
  namespace: staging
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          environment: staging

O controle de acesso deve usar IAM/RBAC com papéis mínimos necessários. Desenvolvedores têm acesso total a dev, acesso restrito a staging (leitura de logs, execução de testes) e nenhum acesso direto a prod (apenas CI/CD automatizado).

4. Processos de deploy e promoção entre ambientes

Uma pipeline CI/CD robusta promove artefatos entre ambientes com gates de qualidade:

# Pipeline conceitual (GitLab CI)
stages:
  - build
  - test
  - deploy_dev
  - deploy_staging
  - deploy_prod

build:
  stage: build
  script:
    - docker build -t app:$CI_COMMIT_SHA .
    - docker push registry/app:$CI_COMMIT_SHA

deploy_dev:
  stage: deploy_dev
  script:
    - kubectl set image deployment/app app=registry/app:$CI_COMMIT_SHA -n dev
  environment: dev

deploy_staging:
  stage: deploy_staging
  script:
    - kubectl set image deployment/app app=registry/app:$CI_COMMIT_SHA -n staging
  environment: staging
  when: manual  # Gate manual

deploy_prod:
  stage: deploy_prod
  script:
    - kubectl set image deployment/app app=registry/app:$CI_COMMIT_SHA -n prod
  environment: prod
  when: manual
  only:
    - main

Estratégias como feature flags permitem ativar funcionalidades em prod sem deploy completo. Canary releases distribuem tráfego gradualmente. Rollbacks devem ser automatizados com versionamento semântico de artefatos.

5. Dados e testes em staging

Staging deve usar dados realistas, mas nunca dados reais de produção sem anonimização. Ferramentas como Delphix ou scripts customizados mascaram dados sensíveis:

# Script de mascaramento (pseudo-código)
UPDATE usuarios
SET cpf = CONCAT('***.', SUBSTRING(cpf, 5, 3), '.***-**'),
    email = CONCAT('user', id, '@test.com'),
    telefone = '999999999'
WHERE ambiente = 'staging';

Dados sintéticos (gerados por ferramentas como Faker) são ideais para testes de performance e carga. Subsets de produção com critérios de amostragem garantem representatividade sem volume total.

6. Monitoramento e observabilidade diferenciados

Cada ambiente deve ter métricas e alertas específicos. Em dev, logs verbosos e métricas de debug. Em staging, alertas simulados. Em prod, dashboards de SLA e SLO.

# Configuração de métricas por ambiente (Prometheus)
- job_name: 'app-dev'
  scrape_interval: 15s
  static_configs:
    - targets: ['app.dev.internal:9090']
      labels:
        environment: 'dev'
        severity: 'debug'

- job_name: 'app-staging'
  scrape_interval: 30s
  static_configs:
    - targets: ['app.staging.internal:9090']
      labels:
        environment: 'staging'
        severity: 'warning'

- job_name: 'app-prod'
  scrape_interval: 60s
  static_configs:
    - targets: ['app.prod.internal:9090']
      labels:
        environment: 'prod'
        severity: 'critical'

Logs centralizados (ELK, Loki) com tags de ambiente permitem filtrar rapidamente. Rastreamento de erros (Sentry, Datadog) deve segmentar por ambiente para evitar alarmes falsos.

7. Governança e documentação

Políticas claras de acesso e revisão de mudanças previnem desvios. Toda alteração em staging deve ser aprovada por pelo menos dois pares. Alterações em prod exigem revisão de segurança e compliance.

# Exemplo de política de acesso
POLÍTICA DE ACESSO A AMBIENTES
- Dev: acesso irrestrito a desenvolvedores via VPN corporativa
- Staging: acesso apenas durante janelas de teste (08-18h), com logging de sessão
- Prod: acesso exclusivo via bastion host, com aprovação do SRE líder
- Qualquer acesso a prod fora do horário comercial requer justificativa documentada

Documente a topologia completa: diagramas de rede, mapeamento de dependências, responsáveis por cada ambiente. Realize auditorias trimestrais de conformidade entre ambientes para garantir que configurações de segurança e isolamento estejam sincronizadas.

A separação de ambientes não é apenas uma prática técnica — é uma estratégia de negócio que reduz riscos, acelera entregas e protege a confiança dos usuários. Invista em automação, documentação e cultura de qualidade para colher os benefícios de ambientes bem segregados.

Referências