← todos os posts
Dores 5 min de leitura

"Dev e produção separados: por que testar no mesmo lugar onde o cliente usa é o erro que aparece na sexta"

"Você mexe pra testar e o cliente vê — porque testar e usar são o mesmo lugar. Como saber em qual ambiente você está e o que fazer hoje."

Sexta, cinco da tarde. Você abre o app pra testar uma bobeira — mudar a cor de um botão, acrescentar um campo. Mexe, recarrega, olha de novo. E o telefone toca: um cliente dizendo que a tela dele ficou estranha, ou que um dado que estava lá sumiu.

Você não publicou nada. Só estava testando. Mas o lugar onde você testou é o mesmo lugar onde o cliente estava, naquele exato momento, usando.

Esse é o erro que quase ninguém vê chegando, porque ele não dá sintoma enquanto você está sozinho no app. Ele espera o primeiro cliente de verdade. E costuma aparecer na pior hora.

Dois apps que parecem um só

Todo profissional trabalha com, no mínimo, dois ambientes. Ambiente é só o nome do lugar onde o app roda e guarda os dados. Tem o ambiente de produção — o que o cliente usa, com os dados reais dele — e o ambiente de teste (às vezes chamado de dev, de desenvolvimento), onde você quebra à vontade, porque ali não tem cliente nenhum pra machucar.

A ideia é simples: você só mexe no app do cliente depois de ver a mudança funcionar num lugar onde errar não custa nada.

O problema é que, pra quem não é da área, esses dois lugares chegam fundidos num só. A plataforma usa a mesma palavra pra tudo, e o padrão de fábrica da maioria é um banco de dados só (o que é isso) — o mesmo banco pro app que você testa e pro app que o cliente usa. Não é descuido seu. Vem assim de origem, e ninguém te avisou que "testar" e "o cliente usa" eram o mesmo endereço.

Pior: essa separação, onde existia, anda sendo desligada. A documentação do Lovable avisa que, em 23 de outubro de 2026, a ferramenta aposentou a divisão entre ambiente de teste e de produção: "a partir dessa data, todo projeto no backend embutido roda num banco de dados só". O que sobrou pra ver uma mudança antes de publicar são os rascunhos, e a mesma página é franca: "rascunhos não oferecem um segundo banco de dados". Rascunho mostra como a tela vai ficar; não é um lugar separado pros dados.

Como saber em qual ambiente você está

Antes de qualquer coisa, descubra onde você está agora. É um teste de duas perguntas. Se a resposta for "sim" pra qualquer uma, você está em produção — mexendo no app do cliente:

  1. Se eu apagasse tudo o que estou vendo nesta tela agora, sumiria dado de algum cliente de verdade?
  2. O endereço aberto no meu navegador é o mesmo que eu já mandei pra alguém de fora?

Se as duas forem "não", você está sozinho e pode experimentar sem medo. Se qualquer uma for "sim", cada tecla que você aperta está caindo na vida de outra pessoa.

O que fazer hoje

A ação depende de uma pergunta só: já tem gente de fora usando?

Caso A — ninguém de fora usa ainda. Você está construindo. Um banco só não é problema, porque não existe cliente pra atingir. A regra aqui é uma: nunca cadastre dado de verdade enquanto testa. Use dado de mentira com a palavra TESTE no nome — assim você acha e apaga depois, e nenhum dado real entra num app que ainda nem tem dono.

Caso B — já tem cliente de verdade, com dado que não pode sumir nem vazar. Aí você precisa de um segundo lugar pra experimentar, e ele não vem de graça. O jeito que funciona em qualquer ferramenta é criar um segundo projeto, só pra teste, com banco próprio:

  • Se o seu banco é no Supabase, a documentação deles descreve os branches: cada um ganha a própria instância e as próprias credenciais, e os branches persistentes servem exatamente pra ambientes de teste e desenvolvimento.
  • Se é no Firebase, a recomendação oficial é usar um projeto separado por ambiente — e a própria doc diz que o ambiente de teste não deve ter dado real de usuário.
  • Se a sua plataforma passou a ter banco único (como o Lovable agora), o caminho é criar um segundo projeto dela apontando pra um segundo banco, e tratar esse como o seu ambiente de teste.

A regra que vale pra todos os casos é a mesma, e cabe numa frase: a primeira vez que uma mudança roda, ela roda num lugar que, se explodir, não explode nenhum cliente. Só depois de ver funcionar ali é que você leva pro app de verdade.

Era uma parede de várias

Separar teste de produção é um dos quatro itens do portão da fase que eu chamo de Construa — e, até hoje, era o único que ainda não tinha tutorial próprio aqui. Agora tem este. Os vizinhos dele na mesma fase são o código rodando na sua máquina, o banco no seu nome e o ponto de retorno pra voltar pra ontem quando algo quebra.

Repare que os quatro andam juntos: ambiente de teste sem ponto de retorno ainda deixa você sem saída quando o teste dá errado; ponto de retorno num banco que não é seu não volta o dado. É por isso que eles formam um portão só, e têm ordem. Resolver um de cada vez, no seu app, na sequência certa, é o que não cabe num post — mas cabe numa tela, com alguém olhando junto.

Fontes