30 de Abril de 2025
Como Evitar "Works on My Machine"
Como reduzir a distancia entre ambiente local, pipeline e produção para que a mesma mudança não se comporte como tres sistemas diferentes.
Andrews Ribeiro
Founder & Engineer
3 min Intermediario Sistemas
O problema
Tem frase que parece piada, mas na prática custa caro:
“Aqui funciona.”
Quando ela aparece, quase nunca significa que o código esta bom.
Normalmente significa que:
- o ambiente local diverge do resto
- a configuração relevante esta implícita
- a dependência instalada não bate
- a validação não passou pelo mesmo caminho da execução real
Works on my machine não e um problema isolado.
E um sintoma de sistema de entrega pouco coerente.
Modelo mental
O objetivo não e fazer laptop, CI e produção serem clones perfeitos.
O objetivo e garantir equivalencia suficiente nos pontos que mudam comportamento relevante:
- versão de runtime
- dependências
- comandos de build e teste
- configuração principal
- serviços auxiliares importantes
Em linguagem simples:
o mesmo código não deveria depender de sorte para se comportar igual em cada etapa.
Quebrando o problema
Diferença de versão
Uma causa classica:
- Node diferente
- pacote resolvido em versão diferente
- biblioteca nativa variando
As vezes a mudança parece pequena.
Mas basta um detalhe de runtime ou resolução de dependência para o comportamento divergir.
Configuração escondida
Outro caso comum:
- env local tem chave que ninguém sabe
- flag esta ligada só em um ambiente
- endpoint local aponta para serviço diferente
Se a configuração real não esta clara, o time testa comportamentos diferentes sem perceber.
Processo manual demais
Quando setup depende de memória humana, a inconsistência cresce.
Exemplos:
- “roda esse comando antes”
- “apaga essa pasta se der erro”
- “no meu caso precisei mudar isso aqui”
Esse tipo de ritual não escala.
Script e automação existem justamente para reduzir variação humana.
CI precisa ser um espelho útil, não decoração
Se local faz uma coisa e a pipeline valida outra, o time ganha falsa segurança.
CI boa ajuda a responder:
- o comando principal e o mesmo?
- a dependência foi instalada de forma reproduzivel?
- o artefato saiu do mesmo caminho esperado?
Não precisa ser copia exata do laptop.
Mas precisa ser coerente o bastante para achar problema cedo.
Exemplo simples
Imagine uma API que funciona no notebook, mas quebra no deploy.
Investigando:
- local usa Node 22
- CI usa Node 20
- produção usa imagem antiga com Node 18
- um pacote depende de comportamento novo do runtime
O problema não era “sorte ruim”.
Era um fluxo que deixava tres realidades coexistirem.
Outro exemplo:
- local aponta para banco seedado
- CI usa banco limpo
- produção exige migration que não rodou
De novo: o bug não era misterioso.
O ambiente e que estava contando historias diferentes.
Erros comuns
- Confiar em setup verbal e informal.
- Aceitar versões divergentes de runtime sem perceber impacto.
- Validar localmente com comando diferente da pipeline.
- Esconder configuração relevante em arquivo pessoal.
- Tratar reproduzibilidade como burocracia em vez de economia de tempo.
Como um senior pensa
Quem tem mais experiência costuma ouvir “funciona só na minha maquina” e traduzir assim:
“Temos uma diferença de contexto que o sistema ainda não tornou visível.”
Essa leitura e forte porque tira a conversa da culpa pessoal e leva para desenho de entrega.
Menos “quem errou?”.
Mais “qual parte do fluxo permite realidades diferentes demais?”.
O que o entrevistador quer ver
Em entrevista, esse tema testa maturidade operacional.
O avaliador quer ver se você entende que problema de ambiente também e problema de engenharia.
Você sobe de nivel quando:
- fala de versão, dependência e configuração
- menciona automação e comando padrão
- conecta local, CI e produção como etapas coerentes
- evita a resposta preguiçosa de “usa container em tudo” como slogan pronto
Uma resposta forte costuma soar assim:
“Eu tentaria reduzir variação entre local, CI e produção nos pontos que realmente mudam comportamento: runtime, dependências, comandos e configuração principal. O objetivo e tornar o setup reproduzivel, não depender de ritual manual.”
Works on my machinenão descreve uma maquina especial. Descreve um processo que ainda deixa contexto demais escondido.
Resumo rápido
O que vale manter na cabeça
- Works on my machine costuma apontar para inconsistencias entre ambiente local, pipeline e produção.
- Quanto mais reproduzivel for o setup de dependência, comando e configuração, menor a surpresa ao promover mudança.
- O objetivo não e ter ambientes identicos em tudo, e sim equivalentes no que afeta comportamento relevante.
- Documentação mínima, scripts claros e validação cedo reduzem atrito muito mais do que heroismo manual.
Checklist de pratica
Use isto ao responder
- Consigo explicar quais diferencas de ambiente mais costumam gerar esse problema?
- Sei dizer como script, automação e configuração ajudam a reduzir variação?
- Consigo defender por que local, CI e produção precisam ser coerentes em pontos criticos?
- Sei falar de dependências, versões e setup sem cair em conselho genérico?
Você concluiu este artigo
Próximo passo
O que Acontece do Commit até Produção Próximo passo →Compartilhar esta página
Copie o link manualmente no campo abaixo.