Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration
Este estudo empírico analisa 77.354 falhas de build de CI em sete projetos Apache para quantificar o esforço do desenvolvedor desperdiçado em falhas não relacionadas e demonstra que modelos de aprendizado semi-supervisionado de Positivo e Não Rotulado (PU), utilizando características como latência de CI e padrões de erro, podem prever efetivamente tais falhas não acionáveis para ajudar os desenvolvedores a priorizar seus esforços de depuração.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você é um chef trabalhando em uma cozinha muito movimentada e caótica (este é o ambiente de Integração Contínua). A cada poucos minutos, um novo pedido chega (um push de código), e a cozinha automaticamente começa a preparar uma refeição de teste para verificar se os novos ingredientes funcionam.
Às vezes, a refeição de teste queima ou tem gosto terrível. Geralmente, isso significa que o chef que acabou de adicionar os novos ingredientes cometeu um erro. Mas, às vezes, o alarme de incêndio dispara porque o chef anterior deixou o fogão ligado, ou o forno quebrou, ou alguém deixou cair uma bandeja no quarto ao lado. Isso é o que o artigo chama de "Falha de Build Não Relacionada".
O problema é que o chef que acabou de adicionar os novos ingredientes não sabe por que a refeição falhou. Eles passam horas (o artigo diz que a mediana é de 4 horas) verificando freneticamente seus próprios temperos e facas, tentando provar: "Não fui eu!". Isso desperdiça muito tempo e causa estresse.
O que os Pesquisadores Fizeram
Os autores (uma equipe de pesquisadores) decidiram investigar esse caos na cozinha. Eles analisaram 77.354 "refeições queimadas" (falhas de build) de 7 grandes projetos de software de código aberto (como Apache Hadoop e HBase).
- O Trabalho de Detetive: Eles leram manualmente milhares de comentários deixados por desenvolvedores após uma falha. Procuraram frases como "isso não está relacionado à minha alteração" ou "não relacionado". Encontraram cerca de 10.300 casos em que os desenvolvedores afirmaram explicitamente: "Essa falha não foi culpa minha".
- A Entrevista: Selecionaram uma amostra menor e representativa de 371 desses casos de "não foi culpa minha" e os analisaram como um detetive analisando uma cena de crime. Perguntaram: Por que os desenvolvedores disseram que não foi culpa deles?
- As Descobertas: As razões mais comuns foram:
- Testes Não Relacionados: O teste que falhou estava, na verdade, verificando algo de uma parte diferente da cozinha, não o novo ingrediente.
- Interferência Externa: Algo fora da cozinha mudou (como um fornecedor entregando farinha ruim para todos).
- Não Reprodutível: O incêndio aconteceu uma vez, mas quando tentaram preparar a refeição novamente, estava tudo bem (talvez uma sobrecarga elétrica aleatória).
- O Grupo "Não Especificado": Em uma grande fatia (35%) das vezes, os desenvolvedores apenas diziam "Não fui eu" sem explicar o porquê.
- As Descobertas: As razões mais comuns foram:
A Solução: Um "Assistente Inteligente"
Como os desenvolvedores nem sempre podem explicar por que uma falha é não relacionada imediatamente, os pesquisadores construíram um Assistente Inteligente (um modelo de aprendizado de máquina) para adivinhar por eles.
Usaram uma técnica especial chamada Aprendizado PU (Positive-Unlabeled Learning).
- A Analogia: Imagine que você está tentando ensinar um cachorro a encontrar um tipo específico de bola. Você tem algumas bolas que sabe serem do tipo certo (os exemplos Positivos). Mas você tem uma pilha enorme de bolas misturadas onde não sabe quais são do tipo certo e quais estão erradas (a pilha Não Rotulada). Você não pode simplesmente dizer "tudo o mais é uma bola errada" porque algumas delas podem, na verdade, ser do tipo certo; você apenas ainda não as verificou.
- Como funcionou: Os pesquisadores alimentaram o modelo com as "falhas não relacionadas conhecidas" e a "pilha desconhecida". O modelo aprendeu a identificar padrões que sugerem que uma falha é provavelmente não relacionada, mesmo sem um rótulo claro.
Quão Bom Foi o Assistente?
O modelo foi testado nos mesmos 7 projetos.
- Foi muito bom em precisão (quando dizia "Não foi culpa sua", geralmente estava certo, cerca de 70% a 88% das vezes).
- Foi bom em revocação (encontrou a maioria das falhas não relacionadas, embora tenha perdido algumas).
- Superou significativamente o chute aleatório ou regras simples.
As "Pistas" que o Modelo Usou
Os pesquisadores encontraram três pistas principais que ajudaram o modelo a decidir se uma falha era não relacionada:
- O Intervalo de Tempo (Latência de CI): Se um desenvolvedor enviou código e esperou muito tempo antes de acionar a build, é mais provável que alguém mais tenha quebrado a cozinha no meio tempo.
- O Erro "Deja Vu": Se a mensagem de erro parece exatamente com uma que aconteceu recentemente, provavelmente é uma repetição de um problema antigo, não um novo causado pelo chef atual.
- A Conversa: Se há muitos comentários no problema antes da falha acontecer, isso sugere que o problema é complexo e provavelmente envolve o trabalho de outras pessoas, não apenas o push atual.
A Conclusão
O artigo conclui que, ao usar esse "Assistente Inteligente", os desenvolvedores podem obter uma dica rápida: "Há uma alta chance de que essa falha não seja culpa sua."
Isso não significa que eles podem ignorar o problema, mas diz a eles: "Não gaste 4 horas verificando seu próprio código. Talvez verifique o forno ou pergunte ao outro chef." Isso ajuda a parar de desperdiçar tempo com falsos alarmes e voltar a cozinhar (codificar) mais rápido.
Nota Importante: O artigo foca inteiramente na identificação dessas falhas em projetos de software. Não afirma que esse método funciona para diagnóstico médico, negociação financeira ou qualquer outro campo fora do desenvolvimento de software. É estritamente uma ferramenta para equipes de software gerenciarem seu próprio caos de "cozinha".
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.