Desenvolvimento, teste, desempenho, homologação, pré-produção, produção…
Tenho uma teoria (e também alguma experiência) de que ter menos ambientes no contexto de desenvolvimento de software é melhor do que ter mais deles.
É uma prática comum em vários projetos de software termos:
- O ambiente de desenvolvimento — também conhecido como o computador do/da desenvolvedor/desenvolvedora
- O ambiente integrado de desenvolvimento — um ambiente remoto utilizado por desenvolvedores e desenvolvedoras para que possam verificar se seu código, quando integrado ao de seus colegas quebrou algo, ou se o código de alguém quebrou o seu
- Os ambientes de teste — ambientes utilizados para testes manuais e/ou automatizados
- O ambiente de homologação — utilizado para testes de aceitação antes da implantação de novo código em produção
- O ambiente de pré-produção — um tipo especial de ambiente utilizado para testar novas funcionalidades com um grupo reduzido de usuários (comumente utilizado para testar novas funcionalidades internamente antes de chegar à uma audiência maior)
- O ambiente de produção — o ambiente que nossos usuários realmente usam
Algumas pessoas podem argumentar que ter todos esses ambientes é algo bom. Eu digo que não.
Quanto mais ambientes você tiver, com mais problemas terá que lidar.
Diga-me. Nunca aconteceu com você de um determinado bug acontecer somente em um ambiente particular, mas não acontecer nos outros?
E você já teve um problema causado devido a uma configuração incorreta em um ambiente específico, o qual você perdeu horas até descobrir?
Ou ainda, nunca aconteceu com você de certa funcionalidade da aplicação se comportar diferente em ambientes distintos, devido a testes manuais acontecendo aqui e ali, alterando o estado da aplicação de forma descontrolada?
Estes são só alguns exemplos de como as coisas podem piorar devido a diversos ambientes.
Em um de meus empregos anteriores, tínhamos somente três tipos de ambientes, e isso era incrível! Eles eram:
- O ambiente de desenvolvimento — também conhecido como o computador do/da desenvolvedor/desenvolvedora
- O ambiente de integração e entrega contínua — criado sob-demanda exclusivamente para a execução de testes automatizados e implantações de novas versões em produção. Estes ambientes eram automaticamente destruídos após o uso
- O ambiente de produção — o qual nossos reais usuários utilizam
O que era tão bom de ter apenas três ambientes?
Tínhamos muito menos problemas para lidar relacionados a diferentes ambientes estando configurados de forma diferente entre si, bugs não sendo reproduzíveis em alguns deles, e testes manuais interferindo no ciclo de desenvolvimento.
Lembro-me até mesmo de argumentar com nosso CEO de que devíamos ter um ambiente de homologação antes de produção, para que tivéssemos mais confiança antes de implantar código novo que poderia chegar aos nossos usuários finais, mas felizmente, ele conseguiu me fazer entender e me convenceu de que isso não era uma boa idéia.
Obviamente, ter menos ambientes vem com alguns desafios. Abaixo listo alguns deles.
- Ao termos somente três ambientes, algumas vezes iríamos introduzir bugs em produção pois não éramos capazes de os encontrar antes;
- Tínhamos que encontrar uma forma de “testar” mínimas funcionalidades viáveis (MFVs) com grupos menores de clientes, em produção;
- Testes de desempenho também teriam que ocorrer contra o ambiente de produção.
Na verdade, estes são bons problemas de se ter, e eles nos forçaram a implementar práticas modernas de desenvolvimento de software que nos levaram à inovação.
Quando você tem o risco de introduzir bugs em produção devido a falta de mais ambientes, você é forçado a possuir uma excelente cobertura de testes automatizados, de todos os tipos. Estes podem ser testes de unidade para o back-end, testes de unidade para componentes de front-end, testes de integração com outros serviços, testes de APIs, testes funcionais de ponta-a-ponta, testes de comparação de screenshots, testes de desempenho, e por aí vai.
Além disso, você deve possuir um mecanismo de re-implantar a aplicação à um estado conhecido e estável rapidamente.
Em um time em que trabalhei, éramos capazes de rodar em um tempo máximo de dez minutos milhares de testes de unidade, centenas de testes de integração e API, quase cem testes de ponta-a-ponta, e alguns testes de comparação de screenshots. E ainda mais importante do que isso, éramos capazes de voltar a aplicação a um estado conhecido com apenas dois cliques. Todo este processo também levava não mais do que dez minutos. Isso era integração e entrega contínua de verdade.
Em termos de testar MFVs com clientes e testadores beta, isso pode ser resolvido utilizando ferramentas de alternância de recursos (feature toggles) e sistemas de monitoramento. Você pode ter todo tipo de estratégia quando se trabalha com alternância de recursos se escolher a ferramenta certa. Algumas ferramentas permitem a criação de regras como:
- Ligue esta funcionalidade específica (ou grupo de funcionalidades) para 1% (ou n%) da base de usuários
- Ligue esta funcionalidade específica (ou grupo de funcionalidades) somente para este usuário (ou grupo de usuários)
- Ligue esta funcionalidade específica (ou grupo de funcionalidades) somente para este intervalo de IPs
- Ligue esta funcionalidade específica (ou grupo de funcionalidades) somente para esta região específica no globo
E a lista vai, com todas as combinação possíveis que você pode imaginar.
Uma ferramenta excelente que lhe permite fazer isso é o Unleash (sistema open-source de alternância de recursos e funcionalidades.)
É claro que ao utilizar tal abordagem monitoramento é essencial. Ainda assim, há beleza nisso, pois quando você descobre por meio de monitoramento que uma determinada funcionalidade (a qual está ativada por uma regra de alternância de recursos, para digamos, 5% da base de usuários) começa a causar estresse ao sistema e afetar diferentes partes da aplicação, você pode simplesmente desligá-la, e investigar e resolver o problema com calma.
Com relação aos testes de desempenho, há chances que seja possível executá-los contra o ambiente de produção em específicos momentos em que a aplicação não esteja recebendo tanto tráfico, de forma controlada, por exemplo.
É claro que, em alguns casos, isso pode não ser possível, e em certas excessões talvez seja válido criar e destruir (sob demanda) um ambiente específico para testes de desempenho.
Concluindo, ter menos ambientes torna o sistema mais resiliente e ajuda você (e sua empresa) a experimentar, falhar rápido, e aprender e melhorar rápido de verdade, habilidades as quais são essenciais para sobreviver neste “ambiente” caótico, onde novas tecnologias surgem todos os dias, novos concorrentes vem de todas as partes do mundo, e usuários estão dispostos a mudar para um software que lhes proporcione uma experiência melhor.
Este conteúdo foi originalmente publicado em Inglês em minha conta no Medium e você pode encontrá-lo através do seguinte link: https://bit.ly/2RN8bSh.
Além disso, recentemente dupliquei este mesmo conteúdo na Dev Community, para torná-lo ainda mais acessível, e daqui para frente, novos conteúdos em Inglês serão publicados lá.
TALKING ABOUT TESTING 