🍳 A cozinha de testes e a cozinha do restaurante aberto
Imagine um restaurante com duas cozinhas. Uma fica fechada pro público — é onde o chef testa um prato novo, erra a mão no sal, joga fora e tenta de novo, sem pressa e sem ninguém esperando o prato na mesa. A outra é a cozinha que está aberta agora, com clientes sentados esperando a comida. Ninguém em sã consciência testa uma receita nova na cozinha que está servindo clientes de verdade.
Novo aqui? Produção é o nome que se dá pro ambiente que está "no ar" de verdade — a automação rodando pra valer, mexendo em dados reais, enviando e-mails reais, executando ações que ninguém pode desfazer com um "ctrl+Z". É a cozinha aberta.
Novo aqui? Staging (também chamado de ambiente de dev, de "desenvolvimento") é a cozinha fechada: uma cópia da automação rodando separada, com dados de mentira ou dados de teste, onde você pode quebrar tudo sem que nenhum cliente de verdade sinta o impacto.
💡 Conceito Principal
Mesma automação, dois lugares diferentes rodando ela. Um é seguro pra errar, o outro não é.
- •Staging/dev: cozinha fechada, pode errar à vontade.
- •Produção: cozinha aberta, cliente sentado esperando o prato certo.
⚠️ Por que um bug em produção não é só feio
Se um site tem um errinho visual, você corrige e ninguém percebeu. Automação é diferente: ela age. Um bug numa automação rodando em produção pode mandar o mesmo e-mail duas vezes pra centenas de clientes reais, gravar o mesmo pedido duplicado no seu sistema, ou disparar uma cobrança que não deveria existir. Não dá pra "desfazer" um e-mail que já chegou na caixa de entrada de alguém.
Por isso a regra é simples e não tem exceção: toda mudança de código passa primeiro pelo ambiente de staging/dev, roda lá, é conferida, e só depois — com aprovação — vai pra produção. Testar direto em produção é como o chef experimentar a receita nova servindo direto pro cliente da mesa 4.
✗ Testar em produção
- ✗Um erro de lógica manda e-mail duplicado pra clientes de verdade
- ✗Um teste malfeito grava registro repetido no banco de dados real
- ✗Não tem como "desfazer" uma ação já executada no mundo real
✓ Testar em staging
- ✓O erro acontece, você vê o log, corrige, testa de novo
- ✓Nenhum cliente real percebeu que algo quebrou
- ✓Só sobe pra produção o que já foi conferido funcionando
⚠️ Atenção
Um bug em produção não é vergonhoso — acontece com qualquer time. O problema é não ter um staging pra pegar esse bug antes dele chegar no cliente. É essa rede de segurança que este módulo constrói.
🔍 Os dois ambientes por dentro
Na prática, "dois ambientes" não significa dois computadores diferentes fisicamente. É a mesma plataforma de execução na nuvem (o Trigger.dev do módulo 4.2) rodando o mesmo código duas vezes, cada uma com uma variável de ambiente diferente marcando qual é qual — uma espécie de crachá que diz "isto aqui é staging" ou "isto aqui é produção".
Legenda: o mesmo código sai do repositório e alimenta os dois ambientes — o que muda é a variável de ambiente que diz "estou em dev" ou "estou em produção", e os dados que cada um enxerga.
🔍 Por dentro
- Variável de ambiente: uma informação guardada fora do código (tipo um bilhete colado no painel), que diz ao programa "você está rodando em dev" ou "em produção" — sem precisar reescrever nada.
- Chave de API separada por ambiente: dev usa uma chave de teste, produção usa a chave de verdade — aprofundamos isso no módulo 4.4 (Segredos).
✓ Variável certa por ambiente
- ✓Dev lê
AMBIENTE=deve usa dados de teste - ✓Produção lê
AMBIENTE=producaoe usa dados reais
✗ Valor fixo no código (hardcoded)
- ✗O código sempre aponta pra produção, mesmo quando você só quer testar
- ✗Testar vira sinônimo de arriscar dado real, porque não dá pra "escolher" o ambiente
🔁 O fluxo de uma mudança, do código à produção
Quando o agente (Claude Code) muda algo na sua automação, esse código não pula direto pra produção. Ele passa por uma esteira com paradas — cada parada é uma chance de pegar erro antes que ele chegue no cliente.
Código muda
O agente escreve ou ajusta o TypeScript da automação (relembrando o módulo 4.2 — você lê e aprova, não escreve à mão).
Testado em dev
A automação roda apontando pro ambiente de staging, com dados de teste. Você observa o log e confere se o resultado é o esperado.
Aprovado
Você — a pessoa, não o agente — decide que o comportamento está correto e dá o sinal verde pra seguir adiante.
Promovido para produção
Só agora o mesmo código passa a rodar apontado pra produção, mexendo em dados reais de verdade.
💡 Conceito Principal
Repare que "testado" e "aprovado" são dois passos separados: passar no teste não significa que já foi promovido. A promoção é sempre uma decisão explícita sua.
🛠️ Construir: rodando a automação apontada pra dev
Novo aqui? CLI é a sigla pra "interface de linha de comando" — o programa que você chama pelo terminal digitando um comando, em vez de clicar em botões numa tela. O Trigger.dev tem uma CLI própria pra rodar suas tarefas.
Objetivo desta tarefa: pedir ao agente pra rodar a automação já apontada explicitamente pro ambiente de dev, nunca deixando isso "no automático". Peça algo como: "rode a task da automação de notificações apontando pro ambiente de dev, não pra produção". O comando por trás normalmente parece com isto:
AMBIENTE=dev npx trigger.dev@latest dev --env=staging \
--api-key=<isto voce troca>SUA_CHAVE_AQUI</isto voce troca>A variável AMBIENTE=dev e a flag --env=staging garantem que a automação só enxergue o mundo de teste. Nunca cole uma chave de API real num prompt ou num arquivo compartilhado — use sempre um placeholder como SUA_CHAVE_AQUI até o momento de configurar de verdade (módulo 4.4 explica onde essa chave realmente mora).
🔍 Como verificar
- 1. No painel do Trigger.dev, confira que a execução aparece listada sob o ambiente "Development"/"Staging" — não sob "Production".
- 2. Abra o log (a lista de eventos registrados durante a execução, aprofundada no módulo 4.7) e confirme que os dados usados são os de teste, não os reais.
- 3. Se a automação envia algo (e-mail, mensagem), confira que foi pra uma caixa de teste — nunca pro cliente de verdade.
🧭 Consolidar: o modo plano vale mais aqui do que em qualquer trilha anterior
Você conheceu o modo plano lá no módulo 0.5: o agente mostra o que pretende fazer antes de agir, e você aprova ou ajusta. Em nenhuma trilha anterior isso importava tanto quanto aqui — porque agora o "fazer" pode significar mexer em produção, com dados de clientes reais, sem botão de desfazer.
A regra prática pra fixar: sempre que pedir ao agente pra promover uma mudança pra produção, force o modo plano primeiro. Deixe ele te mostrar exatamente o que vai mudar, em qual ambiente, e só depois de ler você diz "pode ir".
🎯 Conceito Principal
- •Staging existe pra você errar sem custo — use-o sempre antes de mexer em produção.
- •Modo plano antes de qualquer promoção pra produção — sem exceção.
Checagem rápida (opcional): por que uma automação testa primeiro em staging antes de ir pra produção?