Executando verificação de segurança...
7

As vezes, é necessário testar em produção.

Eu estava lendo um artigo que explicava o que aconteceu recentemente com a Cloudflare e condena testes em produção.

Enquanto eu concordo plenamente que este tipo de teste deve ser evitado, devemos entender que nem sempre o ambiente de teste é fidedigno ao ambiente se produção. Nem sempre podemos testar algo em um ambiente de testes.

O que eu escrevo a seguir é um pequeno contraponto. Um relato do meu ambiente de trabalho.


No meu trabalho, nos dizem para sempre testar nossas funcionalidades. Mas temos servidores diferentes com sistemas operacionais diferentes e versões diferentes. Nosso servidor de teste está usando um Ubuntu 24 (que eu mesmo atualizei da versão 18, porque ninguém mais teve a coragem de fazer), um de nossos servidores de produção está usando uma versão antiga do CentOS e outro está usando AlmaLinux. Uma vez, tivemos que atualizar para o PHP 8.3 e o CentOS ja não suportava a versão do PHP. Deu um trabalhão para atualizar, mas conseguimos.

Como estou encarregado das automações do sistema, posso dizer que apenas por usar distribuições Linux diferentes, você pode enfrentar problemas onde se precisaria testar em produção.

Por exemplo, no Ubuntu, o serviço http é chamado de apache2, enquanto no CentOS é httpd. Estamos planejando uma central de controle (uma ideia minha) que fica encarregada de listar, atualizar e analisar o status de cada projeto de cada cliente. Para se ter uma noção, para apenas atualizar o certificado SSL dos servidores, foi necessário normalizar as diferenças de cada servidor. Usamos o Proxy da Cloudflare, então o script desativa o proxy e chama a função do painel WHM de atualizar os certificados para finalmente ativar novamente o proxy em todos os servidores de produção.

Era uma tarefa simples, mas cada servidor tinha suas diferenças. Todos eles eram distros distintas. Um tinha 3 IPs fixos, o outro, por diferenças de distro tinha o nome de certo comando trocado, um terceiro não usava WHM nem cPanel (tendo que criar um fallback para este caso) e por fim tinha um caso que o servidor de testes era apenas acessivel localmente, dificultando a geração so certificado SSL. No fim eu fiz um Frankenstein para fazer algo simples.

Mas o fato esta dado. Devido a essas diferenças, eu não poderia simplesmente testar no ambiente de testes e esperar todos os servidores funcionando perfeitamente. Para descobrir que cada ambiente tinha estas diferenças específicas, eu fui obrigado a testar em produção. As vezes, porque lá atrás um ex-funcionário decidiu instalar sistemas diferentes, você terá que fazer testes em produção para "aparelhar" essas diferenças. Infelizmente, o mundo não é perfeito.


Por fim, alguém mais também teve que fazer testes em produção?

Carregando publicação patrocinada...
5

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.

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.

2

Isso infelizmente acaba acontecendo mais em sistemas legados, tipo os que usam .NET Framework 2.0 (2005), onde a empresa sempre priorizou adicionar mais tasks do que aumentar a qualidade e a DX (termo que surgiu na gringa em 2011).

1