O que é staging e como ele evita surpresas em produção
Ter staging e não confiar nele custa mais do que não ter nenhum. A equipe monta o ambiente, ele fica com uma versão de banco diferente da de produção, dados de dois anos atrás e uma integração de pagamento desligada. Os testes passam, o deploy sai, e o defeito aparece justamente no pedaço que o staging não tinha. Resultado: horas de incidente e uma conta de servidor que pagou por uma falsa sensação de segurança.
$ ls ./neste-artigo
- Staging fica entre o seu código e o usuário
- Quanto custa manter um staging (e onde ele pesa)
- Montando o ambiente: os passos que costumam funcionar
- O que testar no staging antes de publicar
- Staging, homologação e preview: nomes diferentes para coisas parecidas
- Montagem enxuta de staging para um projeto pequeno
- Quando um time pequeno pode viver sem staging
- O erro a evitar a partir do próximo deploy
Staging (em português, homologação ou pré-produção) é uma cópia do ambiente de produção usada para testar a versão nova antes de ela ir ao ar. Ele só cumpre esse papel quando é parecido o bastante com produção para que um teste aprovado ali signifique algo.
Staging fica entre o seu código e o usuário
O caminho padrão de uma mudança é: desenvolvimento na máquina do dev, testes automatizados no CI, staging, produção. No staging a versão nova roda completa, com banco, fila, cache e integrações, e é ali que o QA, o product owner ou o próprio cliente validam se o comportamento está certo.
O que o staging responde: “esta versão, exatamente como vai para produção, funciona com a infraestrutura de produção?” Testes unitários não respondem isso; eles testam pedaços isolados.
Um ponto que pouca gente conta: o artefato testado em staging deve ser o mesmo que vai para produção. Se você gera uma imagem Docker para staging e depois faz um build novo para produção, o que foi aprovado não é o que foi publicado. O ideal é promover a mesma imagem, mudando só as variáveis de ambiente.
Quanto custa manter um staging (e onde ele pesa)
O staging é, na prática, um segundo conjunto de servidores. Os custos aparecem em quatro lugares:
| Item | O que forma o custo | Onde dá para economizar |
|---|---|---|
| Servidores e banco | Instâncias rodando 24 horas | Máquinas menores que as de produção; desligar à noite e no fim de semana |
| Serviços pagos de terceiros | Licenças, APIs cobradas por chamada | Usar o modo sandbox oferecido por gateways de pagamento e serviços de e-mail |
| Dados | Armazenamento e o trabalho de anonimizar cópias | Massa de teste menor, mas representativa |
| Tempo da equipe | Manter o ambiente atualizado e consertado | Criar o staging pela mesma automação (infraestrutura como código) que cria produção |
O que não convém cortar: as mesmas versões de software (sistema operacional, banco, runtime) e a mesma topologia (se produção tem balanceador e duas instâncias, staging deveria ter também, mesmo que menores). O tamanho pode ser menor; a forma, não.
Montando o ambiente: os passos que costumam funcionar
- Use a mesma receita de produção. Se produção é criada por Terraform, Docker Compose ou manifestos Kubernetes, staging sai da mesma fonte, só com parâmetros diferentes.
- Separe as credenciais. Staging nunca usa a chave de API ou a senha de banco de produção. Um erro de configuração não pode escrever no banco real.
- Isole o acesso. Proteja com senha, VPN ou lista de IPs, e bloqueie indexação com noindex. Já houve site de staging aparecendo no Google com conteúdo de teste.
- Prepare os dados. Cópia de produção anonimizada (nomes, CPFs e e-mails trocados) ou um script de seed que cria cenários realistas.
- Automatize o deploy. O pipeline publica em staging automaticamente após o merge; produção exige aprovação.
- Corte os efeitos externos. E-mails e SMS de staging vão para uma caixa de captura, não para clientes de verdade.
O passo 6 parece detalhe até o dia em que dez mil clientes recebem “TESTE TESTE favor ignorar”. Acontece mais do que se imagina.
O que testar no staging antes de publicar
Testes de unidade já rodaram no CI. Em staging, o foco é o que só aparece com o sistema inteiro de pé:
- fluxos completos de ponta a ponta: cadastro, login, compra, emissão de nota;
- migrações de banco, rodando sobre dados de volume parecido com o real;
- integrações com terceiros (pagamento, frete, autenticação) em modo sandbox;
- variáveis de ambiente e permissões novas que a versão exige;
- desempenho básico: a página que levava 300 ms não pode passar a levar 3 segundos;
- o rollback: voltar para a versão anterior funciona mesmo?
A migração de banco merece atenção dobrada. Um ALTER TABLE que roda em um segundo numa tabela de mil linhas pode travar uma tabela de vinte milhões durante minutos. Staging com volume de dados realista é o único lugar onde isso aparece antes da hora.
O capítulo de engenharia de release do livro de SRE do Google, disponível em sre.google, defende builds herméticos e reprodutíveis justamente para que o que foi testado seja idêntico ao que foi publicado.
Staging, homologação e preview: nomes diferentes para coisas parecidas
No Brasil, “homologação” é o termo mais usado em empresas tradicionais e no governo; “staging” domina em startups. Na maioria dos times, são a mesma coisa. Há ainda os ambientes de preview, criados automaticamente para cada pull request e destruídos depois do merge. Eles não substituem o staging; servem para revisar uma mudança isolada, enquanto o staging valida o conjunto que vai sair junto.
Ferramentas recentes têm aproximado esse ciclo, inclusive com versões imutáveis de fluxos, como mostramos no texto sobre versões e aliases no Amazon Connect.
Montagem enxuta de staging para um projeto pequeno
Para quem trabalha sozinho ou num time de duas ou três pessoas, um exemplo concreto ajuda. Imagine uma API em Node com PostgreSQL, publicada num único servidor virtual de produção. Um staging que cumpre o papel sem estourar o orçamento pode ser assim:
- um segundo servidor virtual, do menor plano que rode a aplicação, no mesmo provedor e com o mesmo sistema operacional;
- o mesmo docker-compose.yml de produção, apontando para um arquivo de variáveis próprio;
- subdomínio staging.seuprojeto.com.br com autenticação básica na frente;
- um script que, uma vez por semana, restaura o backup de produção, troca nomes, e-mails e CPFs por valores falsos e carrega no banco de staging;
- o gateway de pagamento configurado com as chaves de teste do próprio gateway.
Com isso, cada versão passa por um ambiente com a mesma forma de produção antes de ir ao ar. O custo mensal costuma ser uma fração do servidor principal, e o desligamento automático fora do horário comercial reduz ainda mais.
# exemplo: variáveis que mudam entre os dois ambientes
# .env.staging
APP_ENV=staging
DATABASE_URL=postgres://app:***@db-staging:5432/app
PAYMENT_KEY=chave_de_teste
[email protected]A última linha é a que salva do e-mail “TESTE TESTE”: toda mensagem enviada a partir do staging é desviada para uma caixa interna, qualquer que seja o destinatário original.
Quando um time pequeno pode viver sem staging
Existe, sim, quem publique sem staging com segurança: times com testes automatizados fortes, feature flags (a funcionalidade vai desligada para produção e é ligada aos poucos) e deploy gradual para uma fração dos usuários. Mas isso exige maturidade que a maioria dos projetos iniciantes não tem. Para um freelancer com um cliente e um site, um staging simples num subdomínio protegido já evita a maior parte dos sustos.
O erro a evitar a partir do próximo deploy
Não aceite um “passou em staging” se o staging estiver desatualizado. Antes de confiar no teste, verifique três coisas: a versão do banco é a mesma de produção, as variáveis novas foram configuradas lá e o artefato é o mesmo que vai ser publicado. Se algum desses termos ainda soa estranho, o glossário de termos de programação explica cada um em linguagem direta.
