Ambientes, configuração e segredos

Três ambientes, um mesmo código

O mesmo código é executado em vários ambientes:

• dev (desenvolvimento): sua máquina, dados de brinquedo, tudo verbose.
• staging (pré-produção): cópia fiel da produção para testar antes de publicar. Aqui se caçam as falhas que dev não vê.
• prod (produção): o que as pessoas reais usam. Estabilidade e desempenho acima de tudo.

O que muda entre ambientes não é o código: é a configuração (URL do banco de dados, chaves de API, nível de logs...).

Variáveis de ambiente e 12-factor

A metodologia 12-factor propõe, entre outras coisas, separar a configuração do código e lê-la do ambiente. No Node isso é process.env:

const config = {
  porta: process.env.PORT || 3000,
  bancoDados: process.env.DATABASE_URL,
  ambiente: process.env.NODE_ENV || "development",
};

Assim o mesmo artefato (a mesma build) roda em dev, staging e prod só mudando as variáveis. Nunca coloque valores de produção embutidos no código.

Gestão de segredos

As chaves e senhas são segredos. Regras de ouro:

• Nunca no repositório (nem em um .env versionado). Um segredo no Git é um segredo vazado.
• Em produção, use um secret manager ou vault (AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, ou as "variáveis de ambiente criptografadas" do seu PaaS). O app pede o segredo na inicialização; nunca fica escrito em disco.
• Rotacione os segredos periodicamente e dê a cada serviço apenas os que ele precisa.

# .env fica IGNORADO pelo Git; versiona-se só o exemplo sem valores reais
echo ".env" >> .gitignore
git add .env.example   # documenta QUAIS variáveis são necessárias, não seus valores

Feature flags

Uma feature flag é um interruptor que ativa ou desativa uma funcionalidade sem fazer um novo deploy. Serve para lançar para uma porcentagem de usuários, fazer testes A/B ou desligar na hora algo que está falhando.

if (featureAtiva(flags, "novo-checkout", usuario)) {
  mostrarNovoCheckout();
} else {
  mostrarCheckoutClassico();
}