Na minha experiência atual, na empresa em que trabalho, desenvolvemos primeiro na dev e depois passamos para staging, que é uma réplica menor do ambiente de produção. Acho que isso resolveria os problemas que você citou, como diferenças de distribuições Linux, nomes diferentes de serviços, múltiplos IPs, ausência de WHM/cPanel em alguns servidores e acesso limitado do servidor de teste. Com um ambiente de staging bem configurado, seria possível testar todas essas variações sem precisar mexer diretamente em produção, mas concordo que no fim, o teste de fogo final sempre é na prod mesmo.
Em resposta a As vezes, é necessário testar em produção.
5
1
Daria pra simular o ambiente de produção via docker, se tivesse tempo para configurar. Mas o ideal mesmo sempre foi tentar deixar os servidores o mais parecido o possível.
1
Desculpa a demora pra responder 😅
Concordo contigo a solução ideal nunca é nunca vai ser “simular” ambiente e partir para uma abordagem de Infra como Código, usando Terraform ou Pulumi. Assim dev, staging e prod nascem do mesmo código, mudando só variáveis, o que elimina boa parte desses problemas de diferença entre servidores e reduz o risco de surpresa na produção.
Pra quem estiver lendo esse comentário, uma dica: não se empolga e sai mudando tudo agora. Isso é algo pra ser pensado com calma e de preferência, já nascer assim desde o início do projeto. Muitas empresas mantêm sistemas legados há anos, e essa migração pode não ser viável no seu contexto. O ideal é avaliar o cenário e decidir o que realmente faz sentido pra você 😉