Ambientes compartilhados: o problema são as pessoas

Converse com qualquer pessoa da engenharia: devs, arquitetos, gestores. A resposta é sempre a mesma. Ninguém está feliz com os ambientes compartilhados. Dev, test, stage, demo, homolog. Não importa o nome. Ambientes não produtivos são universalmente ruins. Essa é a realidade da nossa indústria.

Eu nunca gostei de nenhum ambiente compartilhado em nenhuma empresa que trabalhei. E te faço a mesma pergunta: você já viu um ambiente não produtivo que funcionava bem?

Agora, a parte curiosa. Se você pergunta pra alguém qual é a solução, a resposta quase sempre é: “se a gente tivesse mais um ambiente, aí sim ia dar certo”. E a minha pergunta é: se não deu certo nos ambientes que já existem, por que daria certo no próximo?

Pra que servem ambientes?

Alguns argumentam que ambientes são necessários pra testar. Eu diria que esse é o tipo mais caro de teste que existe. Por que você precisa de um ambiente remoto compartilhado? Por que não pode testar na sua máquina? Por que não pode ter um mecanismo de teste mais barato?

Claro, alguns cenários são mais difíceis. Um sistema legado proprietário sem código fonte, por exemplo, é genuinamente complicado de testar localmente. Não é impossível, mas é mais trabalhoso.

O problema é que muita gente não conhece formas melhores de testar e assume que a única alternativa é ter um ambiente compartilhado. Boas engenheiras rodam tudo que podem nas próprias máquinas e evitam ambientes compartilhados a todo custo.

Alguém poderia argumentar que testes complexos e de longa duração exigem ambientes compartilhados. Mas se você consegue reproduzir esses cenários localmente, o ambiente compartilhado vira redundante. Pra Integração Contínua (CI), faz sentido ter um ambiente centralizado rodando testes continuamente. Mas isso é CI, não um playground coletivo.

E se não dá pra rodar local?

Então você tem algo genuinamente caro de testar. Mas antes de aceitar isso, pergunte: tem certeza que não existe um container Docker ou Podman que resolva? Muitas vezes a solução existe, só não está integrada no dia a dia da empresa, ou as pessoas não sabem como fazer essa mudança.

Pega a AWS como exemplo. Uma das coisas que mais me incomoda é que você precisa pagar pra aprender. Vários serviços simplesmente não rodam na sua máquina: Bedrock, SQS, agent-core. Você precisa de uma conta e vai pagar uma fatura só pra fazer um POC.

Mas engenheiras sempre encontram um jeito. Existe um projeto open source chamado LocalStack que uso há anos. Ele emula APIs da AWS localmente. Não é pra produção, é pra testes. E resolve o problema.

E se não tenho uma API?

É comum não ter APIs pra todos os “estados” que você precisa induzir num teste. Por exemplo: como simular que alguém comprou 300 iPhones num e-commerce pra testar um cenário de fraude? Se o serviço não expõe essa API, você cria uma interface de teste. Uma API que só existe em ambientes não produtivos, com o único propósito de criar o estado necessário pro teste.

Não ter uma API é um inconveniente, não um impedimento. Se você tem o código fonte, é só ir lá e adicionar a interface de teste que precisa.

E se não tenho o código fonte?

Digamos que é um sistema legado proprietário, sem APIs, só com uma interface gráfica. Mesmo que seja um software desktop, se existe uma UI onde você consegue criar o estado que precisa via cliques, você pode escrever software que faz esses cliques por você. É mais lento? Sim. Mas ainda é possível automatizar a criação do estado necessário.

Como melhorar

Algumas práticas que fazem diferença real:

• Automatize todos os testes. Se é manual, vai quebrar.
• Isole os testes. Um teste não pode depender do estado que outro deixou.
• Tenha CI de verdade. Pare de usar feature branches como muleta.
• Crie interfaces de teste nos serviços que não expõem APIs pra indução de estado.
• Priorize testes locais. Quanto mais barato o teste, mais você roda ele.
• Trate ambientes como imutáveis. Não faça deploy do seu branch no ambiente de dev. Não mexa manualmente em nada. Tudo via automação.
• Fale sobre comportamento. Se o time não discute como as pessoas usam os ambientes (geralmente em retrospectivas), não dá pra corrigir maus hábitos.
• Treine gestores pra identificar e corrigir comportamentos que degradam ambientes.

Pare de criar ambientes novos. Comece a mudar a cultura e o comportamento das pessoas que usam os que já existem.