Como lidiar com ambientes: desenvolvimento, staging e produção

Publicado em 2026-09-12 por frfrand

Para qué sirve cada uno, qué tienen que compartir y qué nunca, cómo tener staging sin pagar un segundo servidor, y el error con los datos que se comete siempre.

"Ambiente" soa a gíria e descreve algo bastante simples: uma cópia do sistema rodando com outra configuração e outros dados, para responder a uma pergunta diferente.

Qual pergunta cada um responde

Desenvolvimento responde "isso que estou escrevendo funciona?". Roda na sua máquina, reinicia em segundos, tem os logs no máximo e os dados são falsos. Foi pensado para quebrar o tempo todo.

Staging responde "isso vai funcionar lá?". É o ensaio geral: configurado o mais parecido possível com a produção, com as mesmas versões e as mesmas variáveis. É onde se testam as migrações antes de tocarem dados reais.

Produção responde "os usuários estão bem?". É o único que realmente importa.

Quando alguém pula o staging, não está economizando um passo: está movendo a pergunta "isso vai funcionar lá?" para a produção, com usuários dentro.

A regra que não se negocia

Os bancos de dados são separados. Sempre.

Parece óbvio até aparecer a tentação concreta: "para testar bem preciso dos dados reais, aponto o staging para o banco de produção por um tempinho". E então uma migração de teste roda sobre dados reais, ou um script de limpeza apaga o que não deveria.

Se for preciso testar com dados parecidos com os reais, a resposta é uma cópia anonimizada, não o banco vivo. Custa uma tarde para montar o script que a gera e se amortiza no primeiro dia que evita um desastre.

O que sim deveria ser igual

Isso é o que torna o staging útil, e onde costuma falhar:

• As mesmas versões. De linguagem, de banco de dados, de dependências. Um staging com outra versão do Postgres não testa nada sobre as migrações.
• A mesma forma de configurar. Se a produção lê variáveis de ambiente, o staging também, com outros valores.
• O mesmo caminho de implantação. Se o staging é enviado manualmente e a produção por um pipeline automático, o staging não está testando a implantação, que é exatamente uma das coisas que mais quebram.

Não é preciso pagar dois servidores

Uma ideia que se repete é que ter staging implica duplicar a infraestrutura. Para a maioria dos projetos, não.

Basta, no mesmo VPS:

• Duas pastas, uma por ramo.
• Dois serviços de systemd, com portas diferentes.
• Dois domínios ou subdomínios (app.meudominio.com e staging.meudominio.com).
• Dois bancos de dados no mesmo mecanismo.

Cada push para a ramo de desenvolvimento atualiza o staging; cada push para a ramo de produção atualiza o site real.

A única coisa que não é compartilhada é a base. Isso não é negociável nem aqui.

Duas precauções que evitam sustos

Que se note onde você está. Uma barra de cor, um prefixo no título, algo visível. Editar dados acreditando que está no staging é um clássico, e é barato de prevenir.

Que no se pueda indexar ni notificar. Staging con un archivo robots que bloquee todo, y con el envío de correos apagado o redirigido. Mandarle um e-mail real a um cliente a partir de um teste é uma anedota que ninguém acha graça.

Quando chega com dois

Para um projeto de uma pessoa com poucos usuários, desenvolvimento e produção podem ser suficientes. Staging começa a fazer sentido quando há mais de uma pessoa mexendo no código, quando há migrações frequentes, ou quando uma queda tem custo real.

No ArduMaker o mesmo repositório pode ser implantado duas vezes no mesmo VPS, cada implantação com sua ramificação, seu domínio e seu serviço. É literalmente a configuração acima, sem precisar montá-la manualmente.