Local
Laboratório no seu computador. Serve para quebrar, aprender, reiniciar e repetir sem usuário, dinheiro ou reputação em jogo.
LABbaixo risco
Errar é de graça: no Local
Antes da gente falar de qualquer comando, de qualquer setup, de qualquer configuração de DevOps, eu preciso que tu entenda uma coisa: o ambiente Local existe pra tu errar. É o teu laboratório. É o teu computador. Erra muito ali, porque sem consequência o aprendizado é grátis. Essa é a filosofia que o Pedro repete sempre, e ele tem razão. O Pedro fala assim, com todas as letras: "sempre a pessoa que erra mais vezes e mais rápido aprende mais do que a pessoa que tenta fazer uma coisa perfeita." Isso muda completamente o jogo. Porque o medo de errar é o que faz a galera ficar olhando o Cloud Code rodar, paralisada, conferindo cada caractere. E aí não erra, e também não aprende. Ambiente Local não tem usuário do outro lado. Não tem consequência financeira. Não tem twitter postando print. Erra à vontade. A regra geral é simples: se o erro pode quebrar alguma coisa real, ele precisa ter passado por Staging antes. Se o erro só quebra o teu computador, é só restart. Local é onde tu compra coragem barata.
3ambientes para proteger o aprendizado
0usuários reais no Local
1guardião do deploy: DevOps
Mapa da aula
Use este mapa para entender a sequência da aula antes de entrar nos detalhes.
Legenda de coresO que cada cor sinaliza nesta aula
Erro baratoo que deve nascer no Local, sem usuário real e sem dano de negócio
Validação realistao que precisa passar por Staging antes de chegar no público
Publicação governadamudança promovida por DevOps depois dos gates certos
Risco de misturabanco compartilhado, push direto ou Production usado como laboratório
Lei do operadorescolher o ambiente pelo custo do erro, não pela pressa
Regra que precisa colarErrar rápido é virtude no Local. Errar rápido em Production é incidente. A maturidade está em saber onde cada erro pode acontecer.
A ordem que não se pula
1. LocalQuebra barato, aprende rápido, testa sem usuário real.
2. StagingValida em ambiente parecido com Production, mas ainda controlado.
3. ProductionSó recebe o que passou pelos gates. Aqui existe usuário, dado e dinheiro real.
Os três ambientes: Local, Staging, Production
Cada ambiente tem um papel diferente. Não dá pra confundir.
Local é o teu computador: laboratório onde pode errar. Staging é o teu computador na nuvem pra testar: mesmo ambiente de Production, mas só pra você e teu time. Production é o que os usuários acessam. Essa sequência tem uma ordem inegociável: o que sai de Local vai pra Staging, e só depois pode subir pra Production. Quem pula essa ordem vira a piada de "subiu direto produção, deu merda, ninguém viu". Pensa no jogo que faz beta: o estúdio libera primeiro pra um grupo pequeno de Beta Testers. Eles entram no jogo, jogam, reportam bugs. Quando o jogo aguenta a galera de beta, aí sim ele abre pra todo mundo. Staging é isso. Production é todo mundo.
Staging
Ensaio parecido com Production. Serve para validar fluxo, dado realista e comportamento antes de expor o usuário.
REHEARSALgate
Production
Ambiente do usuário. Serve para entregar valor real, com banco isolado, deploy governado e rollback pensado antes.
LIVEDevOps
Onde essa mudança deve rodar primeiro?
Decida o ambiente pelo custo do erro, não pela pressa de ver no ar.
Local
É experimento, teste ou quebra reversível só na sua máquina?
signal
Staging
Passou no Local e precisa de validação realista antes de publicar?
bench
↓ ↓ ↓
Production
Tem usuário real, dado real ou dinheiro do outro lado?
pain
↓ ↓ ↓
Você consegue reverter sem o usuário sentir?
Se não consegue, ainda não é hora de Production.
Rode no Local. Erre à vontade, é de graça e ninguém real depende.É experimento, teste ou quebra reversível só na sua máquina?
Suba pra Staging. É o ensaio antes da estreia.Passou no Local e precisa de validação realista antes de publicar?
Só via @devops, depois dos gates. Aqui o erro tem nome e rosto.Tem usuário real, dado real ou dinheiro do outro lado?
Banco de dados também tem três ambientes
Código separado sem banco separado vira ilusão de segurança.
Tem um erro muito comum que destrói projeto inteiro: separar o código em três ambientes e deixar todo mundo conectando no mesmo banco. Aí basta um migration mal escrita rodando em Local pra arrastar dados de Production junto. Banco de dados segue a mesma lógica que o código: dev tem banco próprio, staging tem banco próprio, production tem banco próprio. Nunca compartilhe. Se tu está usando Supabase: que é o stack que a gente recomenda muito no AIOX: o Supabase tem essa função de Branch. Usa. Cada branch é um banco isolado, com schema próprio, dados próprios, RLS próprio. Tu consegue dar push da migration em Staging, validar, e só depois subir pra Production. Isso evita o caso clássico do "rodei o migration em prod sem querer". Com Branch, tu literalmente não consegue rodar em prod sem mudar de branch consciente. O @devops é o guardião disso. Ele cuida do teu Local pra tu ter Docker Desktop, MCPs, tudo configurado. Ele cuida do Staging pra teu time validar. Ele cuida do Production pra o usuário ter experiência boa. Três ambientes, três bancos, um guardião.
código separado com banco compartilhado ainda é risco
1
Código Local
Você testa no computador.
2
Banco Local
Dados descartáveis, schema livre para quebrar.
3
Banco Staging
Dados realistas e validação antes de usuário real.
4
Banco Production
Isolado, protegido, alterado só com deploy governado.
Ilusão de segurança
- Três branches de código apontando para o mesmo banco.
- Migration testada direto no banco real.
- Staging sem dados parecidos com Production.
- Qualquer agente podendo mexer em deploy.
Segurança operacional
- Um banco por ambiente.
- Migration passa por Local e Staging antes de Production.
- Supabase Branch ou equivalente quando disponível.
- DevOps como guardião de push e deploy.
Versionamento: três números que mudam tudo
Patch, Minor, Major: Pedro explica a regra que ele demorou pra entender.
O Pedro conta essa história aberta, ele ficava na dúvida de fazer versionamento. "Isso aqui é 2.0? Isso é 2.0.1?" Aí ele descobriu que existe uma metodologia: Semantic Versioning, semver, e ela é simples: três números, sempre. Tipo 1.1.2. A regra do Pedro, na linguagem dele: "Patch é mudança pequenininha. Minor é incremento de feature. Major é mudança agressiva, vira 2.0.0." Quando muda só o último número (1.1.2 → 1.1.3), tu está dizendo: "consertei bug, comportamento é o mesmo." Quando muda o do meio (1.1.2 → 1.2.0): "adicionei feature, nada quebra." Quando muda o primeiro (1.x.y → 2.0.0): "mudei coisa séria, prepare-se." Isso importa porque o AIOX usa semver no próprio framework. Quando o Pedro fala que "o AIOX estava no 2.3 e agora a gente está no 3.11", ele está te contando uma história de evolução. O @devops cuida desse versionamento via comando version-check antes do release.
Quando cada número muda
PPatch: último número (1.1.2 → 1.1.3)Mudança pequenininha. Bug fix. Comportamento externo idêntico. Quem já usa não precisa adaptar nada.
mMinor: número do meio (1.1.2 → 1.2.0)Incremento de feature. Adicionou capacidade nova sem quebrar nada. Quem já usa pode atualizar sem medo.
MMajor: primeiro número (1.x.y → 2.0.0)Mudança agressiva. Quebrou contrato, mudou API, virou outra coisa. Quem já usa precisa ler o changelog e adaptar.
Docker Desktop: sem ele, o teste local não roda
Por que o @devops exige Docker Desktop ligado durante os ciclos de teste.
Antes de qualquer push, o @devops faz uma sequência de testes: lint, testes unitários, verificação de tipos, build. Em muitos desses passos ele usa o Docker Desktop pra simular Production no teu Local: cria um container, sobe a aplicação, roda os testes, mata o container. Tudo sem tu ver. Por isso quando tu roda o environment-bootstrap, uma das obrigatoriedades é Docker Desktop instalado. E não basta instalado - precisa estar aberto. O Pedro fala: "Ele tem que estar com ele aberto no computador para que o agente possa ir lá e fazer os testes sem nem você saber." Se tu esquece de abrir, o build falha sem explicação óbvia. Detalhe de governança: Story termina no QA. Deploy é do @devops. Tu não dá push direto. Tu pede pro @devops empurrar. Essa separação não é capricho. É a mesma lógica de ter @db-sage pra banco e @architect pra arquitetura: cada agente tem autoridade exclusiva sobre o que governa. Push pertence ao @devops, ponto.
o que acontece antes do push
1
Docker aberto
Permite simular parte do ambiente real no computador.
2
Testes locais
Lint, types, unit tests e build rodam antes de qualquer subida.
3
Story fecha no QA
A validação técnica aprova a entrega, mas ainda não publica.
4
DevOps publica
Push, PR, CI/CD e deploy pertencem ao agente com autoridade.
Sinal de alertaSe o seu fluxo atual permite subir direto para Production sem Staging, sem banco isolado e sem DevOps, você não tem velocidade. Você tem sorte temporária.
O erro que precisa morrer no Local
A diferença entre Local, Staging e Production fica óbvia quando você pensa no custo do erro em cada ambiente.
Todo aluno entende a ideia dos três ambientes quando escuta a definição. O problema é que, na prática, muita gente ainda trata Local, Staging e Production como nomes bonitos para a mesma coisa. Aí o erro barato vira incidente caro. O modelo mental correto é simples: Local é onde eu posso quebrar sem vergonha. Staging é onde eu provo que a mudança se comporta parecida com Production. Production é onde existe usuário, dado, reputação e dinheiro real. A mesma falha muda completamente de gravidade conforme o ambiente onde acontece.
Erro barato vira regra
Um ajuste que quebra no Local ensina; o mesmo ajuste quebrando em Production vira crise.
Começou comoUma mudança simples que parecia pronta.
VirouUma checagem de ambiente antes de publicar.
ProvaQuando o aluno sabe dizer onde pode errar, ele para de testar em cima de usuário real.
LiçãoAmbiente não é detalhe técnico; é gestão de risco.
1LocalQuebra livre, sem usuário, sem dado real.
2StagingValidação parecida com Production, mas ainda sem risco de negócio.
3ProductionSó entra depois de QA e DevOps, porque aqui o erro custa caro.
- Quando o aluno sabe dizer onde pode errar, ele para de testar em cima de usuário real.
- Ambiente não é detalhe técnico; é gestão de risco.
- Você amadurece quando escolhe o ambiente pelo custo do erro.
- Local: Quebra livre, sem usuário, sem dado real.
- Staging: Validação parecida com Production, mas ainda sem risco de negócio.
- Production: Só entra depois de QA e DevOps, porque aqui o erro custa caro.
Como converter erro em governança
1. Quebre no LocalUse o computador como laboratório. Errar aqui é barato e didático.
2. Repita no StagingConfirme se a mudança se comporta parecida com o real.
3. Publique com DevOpsProduction só recebe o que passou por gate e dono correto.
Mapeie os três ambientes do teu projeto atual
Exercício curto pra sair da teoria: pega um projeto teu e responde as cinco perguntas.
Pega um projeto que tu está tocando agora. Não inventa um: usa um que tu realmente conhece. Responde as cinco perguntas abaixo por escrito. Se tu não souber a resposta de alguma, esse já é o primeiro diagnóstico do que falta no teu setup de DevOps.
Sequência para auditar ambientes
Use antes de considerar qualquer projeto pronto para usuário real.
local→staging→production→banco→devopsLocal— Onde posso quebrar sem afetar usuário?Staging— Onde valido parecido com Production?Production— Onde existe usuário, dado e dinheiro real?Banco— Os bancos estão isolados por ambiente?DevOps— Quem tem autoridade para publicar?
Exemplo preenchido: auditoria de um SaaS B2B em estágio inicial
LocalDocker Desktop instalado, mas fechado entre sessões. Banco local em container. Schema sincroniza por migration manual.
StagingNão existe. O time testa direto em Production com uma flag improvisada. Risco alto de dado de teste aparecer para usuário real.
ProductionAtende usuários pagantes. Banco principal isolado, mas sem checklist de backup e sem caminho documentado de rollback.
VersãoPróxima mudança troca gateway de pagamento. Isso é major se quebra contrato existente, minor se adiciona opção sem quebrar fluxo atual.
DeployFounder publica direto do laptop sem agente intermediário. Não há @devops definido. Falta governança de publicação.
DecisãoCriar Staging via Supabase Branch + Vercel preview. Atribuir @devops. Documentar checklist de promoção Local->Staging->Production.
Portão da aulaVocê entendeu quando consegue apontar Local, Staging, Production, banco de cada ambiente e quem publica sem misturar aprendizado com risco real.
- Local: Qual é o teu ambiente Local? Tem Docker Desktop instalado e aberto? Tem banco de dados local rodando?
- Staging: Tu tem Staging? Onde fica? Quem mais acessa? Se não tem, qual seria o caminho mais barato pra criar: Supabase Branch, Vercel preview, Railway staging?
- Production: Production atende quantos usuários hoje? O banco de Production é completamente isolado dos outros dois?
- Versão: Em qual versão semver tu está? A próxima mudança que tu vai fazer é patch, minor ou major? Justifique em uma linha.
- Deploy: Quem aperta o botão de push pra Production no teu fluxo atual? Se a resposta não é '@devops', tem um gap de governança pra arrumar.
Bloco de código: mapa de ambientes
O aluno precisa enxergar a separação de risco em formato copiável.
01local:02risco: "baixo"03uso: "errar, testar e aprender"04staging:05risco: "médio"06uso: "validar parecido com produção"07production:08risco: "alto"09uso: "usuário, dado e dinheiro real"