Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration
Deze empirische studie analyseert 77.354 CI-buildmislukkingen in zeven Apache-projecten om de door developers bestede tijd aan niet-gerelateerde mislukkingen te kwantificeren en toont aan dat semi-supervised Positive and Unlabeled (PU)-leermodellen, die gebruikmaken van kenmerken zoals CI-latentie en foutpatronen, dergelijke niet-actievere mislukkingen effectief kunnen voorspellen om developers te helpen hun debuginspanningen te prioriteren.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een kok bent die werkt in een zeer drukke, chaotische keuken (dit is de Continuous Integration-omgeving). Om de paar minuten komt er een nieuwe bestelling binnen (een code push), en begint de keuken automatisch een proefmaaltijd te bereiden om te zien of de nieuwe ingrediënten werken.
Soms verbrandt de proefmaaltijd of smaakt hij vreselijk. Meestal betekent dit dat de kok die net de nieuwe ingrediënten heeft toegevoegd, een fout heeft gemaakt. Maar soms gaat het brandalarm af omdat de vorige kok het fornuis aan heeft laten staan, of de oven kapot is, of iemand anders een dienblad heeft laten vallen in de volgende kamer. Dit noemt het artikel een "Ongerelateerde Bouwfout".
Het probleem is dat de kok die net de nieuwe ingrediënten heeft toegevoegd, niet weet waarom de maaltijd mislukt is. Ze besteden uren (het artikel geeft een mediaan van 4 uur) aan het wanhopig controleren van hun eigen kruiden en messen, in een poging te bewijzen: "Het was niet mijn schuld!" Dit kost veel tijd en veroorzaakt stress.
Wat de Onderzoekers Dedden
De auteurs (een team van onderzoekers) besloten dit keukenchaos te onderzoeken. Ze keken naar 77.354 "verbrande maaltijden" (bouwfouten) uit 7 grote open-source softwareprojecten (zoals Apache Hadoop en HBase).
- Het Rechercheurwerk: Ze lazen handmatig duizenden opmerkingen die ontwikkelaars achterlieten na een fout. Ze zochten naar zinnen als "dit heeft niets te maken met mijn wijziging" of "ongerelateerd". Ze vonden ongeveer 10.300 gevallen waarin ontwikkelaars expliciet zeiden: "Deze fout was niet mijn schuld."
- Het Interview: Ze selecteerden een kleinere, representatieve steekproef van 371 van deze "niet mijn schuld"-gevallen en analyseerden ze als een rechercheur die een misdaadplek onderzoekt. Ze vroegen zich af: Waarom zeiden ontwikkelaars dat dit niet hun schuld was?
- De Bevindingen: De meest voorkomende redenen waren:
- Ongerelateerde Tests: De test die mislukte, controleerde eigenlijk iets uit een ander deel van de keuken, niet het nieuwe ingrediënt.
- Externe Interferentie: Iets buiten de keuken veranderde (zoals een leverancier die slechte bloem aan iedereen leverde).
- Niet-reproduceerbaar: Het vuur brak één keer uit, maar toen ze de maaltijd opnieuw probeerden te maken, was het in orde (misschien een willekeurige stroomstoring).
- De "Onbepaalde" Groep: In een groot deel (35%) van de gevallen zeiden ontwikkelaars gewoon "Het is niet mijn schuld" zonder uit te leggen waarom.
- De Bevindingen: De meest voorkomende redenen waren:
De Oplossing: Een "Slimme Assistent"
Omdat ontwikkelaars niet altijd direct kunnen uitleggen waarom een fout ongerelateerd is, bouwden de onderzoekers een Slimme Assistent (een machine learning-model) om voor hen te raden.
Ze gebruikten een speciale techniek genaamd PU Learning (Positive-Unlabeled Learning).
- De Analogie: Stel je voor dat je een hond leert een specifiek type bal te vinden. Je hebt een paar ballen waarvan je weet dat ze van het juiste type zijn (de Positieve voorbeelden). Maar je hebt een enorme stapel gemengde ballen waarbij je niet weet welke van het juiste type zijn en welke niet (de Ongelabelde stapel). Je kunt niet zomaar zeggen "alles anders is een verkeerde bal", omdat sommige daarvan misschien wel van het juiste type zijn, je ze gewoon nog niet hebt gecontroleerd.
- Hoe het werkte: De onderzoekers voerden hun model de "bekende ongerelateerde fouten" en de "onbekende stapel" toe. Het model leerde patronen te herkennen die suggereren dat een fout waarschijnlijk ongerelateerd is, zelfs zonder een duidelijke label.
Hoe Goed Was de Assistent?
Het model werd getest op dezelfde 7 projecten.
- Het was zeer goed in precisie (wanneer het zei "Dit is niet jouw schuld", had het meestal gelijk, ongeveer 70% tot 88% van de tijd).
- Het was goed in recall (het vond de meeste ongerelateerde fouten, hoewel het er sommige miste).
- Het presteerde aanzienlijk beter dan willekeurig gissen of simpele regels.
De "Sporen" die het Model Gebruikte
De onderzoekers vonden drie belangrijkste sporen die het model hielpen beslissen of een fout ongerelateerd was:
- Het Tijdsverschil (CI Latency): Als een ontwikkelaar code heeft aangeleverd en lang heeft gewacht voordat de build werd gestart, is het waarschijnlijker dat iemand anders ondertussen de keuken heeft verpest.
- De "Déjà Vu"-Fout: Als het foutbericht er precies hetzelfde uitziet als een fout die recentelijk is opgetreden, is het waarschijnlijk een herhaling van een oud probleem, niet een nieuw probleem veroorzaakt door de huidige kok.
- De Gepraat: Als er veel opmerkingen op het probleem staan voordat de fout optrad, suggereert dit dat het probleem complex is en waarschijnlijk het werk van anderen betreft, niet alleen de huidige push.
De Conclusie
Het artikel concludeert dat ontwikkelaars door gebruik te maken van deze "Slimme Assistent" een snelle hint kunnen krijgen: "Er is een grote kans dat deze fout niet jouw schuld is."
Dit betekent niet dat ze het probleem kunnen negeren, maar het vertelt hen: "Besteed geen 4 uur aan het controleren van je eigen code. Kijk misschien naar de oven of vraag het aan de andere kok." Dit helpt hen tijd te besparen op valse alarmen en sneller weer aan het koken (coderen) te slaan.
Belangrijke Opmerking: Het artikel richt zich uitsluitend op het identificeren van deze fouten in softwareprojecten. Het beweert niet dat deze methode werkt voor medische diagnose, financieel handelen of enig ander veld buiten softwareontwikkeling. Het is strikt een hulpmiddel voor softwareteams om hun eigen keukenchaos te beheren.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.