À medida que as empresas crescem, seus produtos se tornam cada vez mais complexos, tornando essencial a aplicação de testes rigorosos e a garantia da estabilidade. A Okta não é estranha a esse desafio. Executamos centenas de milhares de testes em cada alteração em nosso sistema de integração contínua (CI) para detectar problemas no início do ciclo de vida do desenvolvimento.
Nossa escala operacional é enorme, e nossos serviços recebem mais de 500.000 commits anualmente. No entanto, mesmo nós enfrentamos o problema da instabilidade dos testes em nossa base de código monolítica. Nossos commits da linha principal tinham uma taxa de aprovação de menos de 40% na primeira execução de um commit devido a testes instáveis. Precisávamos de um método confiável para descobrir quando um problema surgia, desbloquear outros engenheiros e entrar em contato imediatamente com as equipes correspondentes para investigar.
O processo manual
Historicamente, uma solução parcial para esse problema era ter um engenheiro de plantão observando se os commits em nossa branch principal passavam ou falhavam nos testes em nosso CI. Se um teste falhasse na principal, teríamos que analisar os logs e os rastreamentos de pilha para determinar a validade de uma falha e então consultar a equipe apropriada.
Toda segunda-feira, o engenheiro de plantão revisava as falhas da semana anterior, compilava manualmente uma lista de tickets do Jira, coletava dados para as falhas e enviava um e-mail para as equipes de engenharia. No entanto, essa abordagem tinha falhas óbvias.
- Uma falha pode ser perdida ou ignorada devido a um erro humano.
- Era demorado, pois o engenheiro tinha que descobrir a causa raiz e, em seguida, descobrir quem tinha o conhecimento e o contexto para ajudar a corrigir o problema.
- O engenheiro de plantão teve que passar muitas horas treinando. Desempenhar esta função nos custa quatro meses de tempo de engenharia a cada ano.
- Não era confiável ou escalável.
- É necessário muito conhecimento coletivo. Por exemplo, existem inúmeras consultas SQL legadas feitas manualmente para descobrir falhas
O que é uma falha urgente?
Para tornar este processo confiável, precisávamos de uma maneira estrita de determinar o que constituía uma quebra urgente ou não urgente. Estaremos nos referindo ao primeiro cenário como um P0. Você pode se perguntar por que não abordamos cada teste que falhou imediatamente no principal. Isso aconteceria em um ambiente ideal (ao qual estamos agora mais próximos), mas não é surpresa que, das centenas de milhares de testes que executamos, alguns testes falhem de forma inconsistente (diz-se que são “instáveis”). Seria irracional e impraticável dizer aos engenheiros de outras equipes para largar tudo e corrigir centenas de testes instáveis.
Nossa solução imediata foi encontrar P0s com base em um critério de porcentagem de frequência com que um teste falhou. No entanto, este é um indicador atrasado e um atraso significativo no relatório ocorreria se um teste fosse completamente interrompido. Precisávamos de uma maneira de detectar quebras reais imediatamente e resolver incrementalmente testes instáveis. Depois de criar um programa para executar inúmeras simulações, finalmente chegamos a uma solução.
Nossa solução inicial: registrar um ticket para um método de teste como P0 se ele falhar em duas confirmações nas últimas cinco execuções ou se falhar mais de 25% das vezes em pelo menos 100 execuções.
Agora que definimos claramente o escopo do problema, podemos finalmente automatizá-lo.
Apresentando o AutoGuardian
AutoGuardian é o nosso serviço que monitora periodicamente os testes para lidar com falhas. Abaixo, um gráfico exibe um breve resumo de suas responsabilidades.
Os benefícios do AutoGuardian têm sido transformadores, aprimorando significativamente o fluxo de trabalho diário de nossa equipe. Ele identifica e relata problemas, agiliza a comunicação e se conecta a um serviço separado que impede que nosso CI execute testes com falha para outros desenvolvedores.
A exclusão de testes é crucial para garantir que os desenvolvedores não sejam impedidos de fazer merge devido a testes quebrados e para nos ajudar a reduzir custos, evitando execuções desnecessárias em testes que já sabemos que são defeituosos. Em resumo, o AutoGuardian capacita nossa equipe a se concentrar no progresso em vez de se atolar na solução de problemas, tornando nosso processo de desenvolvimento mais eficiente e eficaz.
O AutoGuardian agora é um serviço crítico do qual dependemos, oferecendo uma economia de custos anual estimada em mais de US$ 1.000.000. Este foi apenas o projeto inicial. Desde então, aprimoramos ainda mais, adicionando agregação de problemas que agrupa problemas por rastreamentos de pilha semelhantes, restrição automática de critérios e relatórios de dados aprimorados. Como resultado, agora estamos detectando mais de 1900% mais testes instáveis em comparação com antes do AutoGuardian, aumentando nossa taxa de aprovação da linha principal para mais de 80%. Essa transformação agiliza o processo de desenvolvimento e ajuda a reduzir os tempos de execução do commit em 50%, permitindo que nossos engenheiros se concentrem na inovação em vez de solucionar problemas, promovendo uma experiência de desenvolvedor mais produtiva.
Revolucione seus processos com automação
A maioria das empresas de tecnologia tem alguma forma de processo de plantão, e fornecemos apenas um exemplo de por que você deve se esforçar para automatizar o máximo possível. Quando algo precisa ser feito manualmente, sempre pergunte a si mesmo e aos outros: “Por que?” Adotar a automação economiza tempo valioso do desenvolvedor e aprimora a resiliência, a confiabilidade e a segurança do seu produto.
Tem perguntas sobre esta postagem do blog? Entre em contato conosco em eng_blogs@okta.com. Explore mais Blogs de engenharia perspicazes da Okta para expandir seu conhecimento.
Pronto para se juntar à nossa equipe apaixonada de engenheiros excepcionais? Visite nossa página de carreiras.
