O que é ambiente de produção e por que ele separa de dev e staging

“Posso testar direto no servidor, é só uma mudancinha?” Não. A resposta curta é essa, e o resto deste texto explica por quê. Ambiente de produção é onde o sistema atende usuários reais, com dados reais e dinheiro real. Qualquer erro ali deixa de ser um problema seu e vira um problema do cliente.

Por isso as equipes separam o caminho do código em etapas: desenvolvimento, homologação (ou staging) e produção. Cada uma tem uma função e regras próprias. Entender essas regras é uma das coisas que mais diferenciam um dev júnior que inspira confiança de um que ainda precisa de supervisão.

Qual a diferença entre desenvolvimento, homologação e produção?

Pense no mesmo sistema em três endereços diferentes:

Algumas empresas têm mais etapas (um ambiente de QA separado, um de testes de carga), outras têm menos. A lógica é sempre a mesma: o código só avança quando passou pela etapa anterior.

Por que não dá para ter só produção e pronto?

Porque o custo de um erro cresce à medida que ele chega mais perto do usuário. Um bug achado na sua máquina custa minutos. O mesmo bug em produção pode significar pedidos perdidos, cobrança duplicada ou dados corrompidos que exigem restauração de backup.

Imagine uma loja virtual em plena Black Friday. Um desenvolvedor altera a regra de frete grátis e, por um sinal invertido, o frete passa a ser cobrado de todo mundo. Em produção, cada minuto até alguém perceber são vendas abandonadas. Em homologação, o mesmo erro teria aparecido no primeiro teste de carrinho.

Os ambientes precisam ser iguais?

Quanto mais parecidos, melhor. A metodologia Twelve-Factor App, referência de boas práticas para aplicações web, dedica um fator inteiro a isso, a paridade entre desenvolvimento e produção. A recomendação é reduzir três distâncias: de tempo (código vai rápido para produção), de pessoas (quem escreve acompanha a publicação) e de ferramentas (mesmo banco, mesma versão).

O exemplo clássico de falta de paridade: usar SQLite no desenvolvimento e PostgreSQL em produção. Funciona até o dia em que uma consulta se comporta diferente nos dois bancos. Containers ajudam muito aqui, porque você roda localmente a mesma versão de banco que está no servidor.

Como o código sabe em qual ambiente está?

Pela configuração, não pelo código. A prática recomendada é guardar tudo o que muda entre ambientes (endereço do banco, chaves de API, nível de log) em variáveis de ambiente, e não escrito no código.

// errado: a URL de produção está no código
const db = connect("postgres://admin:senha@prod-db:5432/loja");

// certo: cada ambiente define a sua
const db = connect(process.env.DATABASE_URL);

Assim o mesmo código roda em dev, homologação e produção, só mudando as variáveis. E, de quebra, a senha de produção não fica no repositório, que é onde muito vazamento começa.

Quem pode mexer em produção?

Em times organizados, pouca gente, e quase nunca à mão. O normal é que a publicação seja feita por um pipeline automatizado de CI/CD, disparado depois de um pull request aprovado. Plataformas como o GitHub permitem configurar ambientes com regras de proteção, exigindo aprovação de uma pessoa específica antes de qualquer deploy em produção.

Como júnior, é comum você não ter acesso direto ao servidor de produção. Não leve para o lado pessoal: é proteção para você também.

Quais regras valem para quem vai publicar algo no ar?

As que mais aparecem em times brasileiros, de startup a banco:

• Nada vai para produção sem passar por homologação. Nem a “mudancinha”.
• Toda publicação tem um plano de volta (rollback): a versão anterior precisa estar pronta para ser restaurada.
• Evite deploy na sexta à tarde ou véspera de feriado. Se der problema, ninguém estará por perto.
• Migrações de banco são revisadas à parte, porque apagar uma coluna não tem desfazer.
• Depois de publicar, observe: logs, taxa de erros e métricas por alguns minutos.
• Não consulte dados pessoais de produção por curiosidade. A LGPD trata acesso indevido como incidente.

Sobre o último item: dados de clientes não devem ser copiados crus para dev ou homologação. Use dados anonimizados ou fictícios.

Um deploy em produção visto de perto

Para tirar o conceito do abstrato, acompanhe o caminho de uma correção simples, como ajustar o cálculo de desconto de um cupom, num time de porte médio:

1. Você cria uma branch, corrige o cálculo e escreve um teste que reproduz o erro.
2. Abre o pull request; o CI roda os testes automaticamente e um colega revisa.
3. Depois do merge, o pipeline publica a versão em homologação sozinho.
4. A pessoa de QA, ou você mesmo, aplica o cupom em alguns carrinhos de teste e confere o total.
5. Alguém com permissão aprova a promoção para produção, de preferência num horário de movimento baixo.
6. Nos minutos seguintes, o time acompanha o painel de erros e o volume de pedidos.

Parece muita cerimônia para mudar uma linha. Mas é exatamente a linha “simples” que ninguém testa que costuma derrubar o checkout. O processo existe para que nenhuma mudança dependa só da atenção de uma pessoa num dia cansado.

Produção não é o lugar de descobrir se o código funciona. É o lugar de confirmar que ele continua funcionando.

E quando a correção é urgente?

Existe o hotfix: uma correção que pula etapas para resolver um problema grave já em produção. Mesmo nele, a maioria dos times mantém dois passos mínimos, a revisão de outra pessoa e o registro do que foi feito. Pular tudo porque “é urgente” é como muitos incidentes pequenos viram grandes.

E se eu derrubar produção sem querer?

Avise imediatamente. Parece óbvio, mas o instinto de tentar consertar sozinho, em silêncio, é o que transforma um incidente de dez minutos num de duas horas. Equipes maduras tratam falhas com post-mortem sem culpados: o foco é descobrir qual processo deixou o erro passar, não quem apertou o botão.

O roteiro básico:

1. avise o canal do time ou o responsável pelo plantão;
2. se houver rollback simples, proponha fazê-lo antes de investigar a causa;
3. anote o que você fez e em que horário;
4. depois que tudo voltar, participe da análise do que aconteceu.

Onde produção aparece no dia a dia de quem está começando

Em mensagens como “subiu pra prod?”, “isso está em homolog” ou “não roda isso em produção”. Também aparece nas notícias: muitos alertas de segurança que o buildbase publica, como o de correção da falha no kernel Linux, são, no fundo, sobre como atualizar servidores de produção sem derrubar o serviço.

Se o próximo termo estranho for staging, rollback ou deploy, o glossário do buildbase tem cada um explicado. E a regra para levar daqui é simples: na dúvida sobre mexer em algo que está no ar, pergunte antes.