Pular para o conteudo principal

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

Andrews Ribeiro

Founder & Engineer

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 machine não descreve uma maquina especial. Descreve um processo que ainda deixa contexto demais escondido.

Resumo rápido

O que vale manter na cabeça

Checklist de pratica

Use isto ao responder

Você concluiu este artigo

Próximo artigo Containers e orquestração Artigo anterior Variaveis de Ambiente, Secrets e Configuração

Continue explorando

Artigos relacionados