Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration
Diese empirische Studie analysiert 77.354 CI-Build-Fehler über sieben Apache-Projekte hinweg, um den von Entwicklern für nicht zusammenhängende Fehler verschwendeten Aufwand zu quantifizieren, und zeigt, dass halbüberwachte Positive-and-Unlabeled (PU)-Lernmodelle, die Merkmale wie CI-Latenz und Fehlermuster nutzen, solche nicht handlungsrelevanten Fehler effektiv vorhersagen können, um Entwicklern bei der Priorisierung ihrer Debugging-Bemühungen zu helfen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind ein Koch in einer sehr belebten, chaotischen Küche (dies ist die Continuous-Integration-Umgebung). Alle paar Minuten kommt eine neue Bestellung herein (ein Code-Push), und die Küche beginnt automatisch, ein Testessen zuzubereiten, um zu prüfen, ob die neuen Zutaten funktionieren.
Manchmal verbrennt das Testessen oder schmeckt schrecklich. Normalerweise bedeutet dies, dass der Koch, der gerade die neuen Zutaten hinzugefügt hat, einen Fehler gemacht hat. Aber manchmal geht der Feueralarm los, weil der vorherige Koch den Herd anlassen ließ, oder der Ofen defekt ist, oder jemand anders ein Tablett im nächsten Raum fallen ließ. Dies ist das, was die Arbeit als „unabhängiger Build-Fehler" bezeichnet.
Das Problem ist, dass der Koch, der gerade die neuen Zutaten hinzugefügt hat, nicht weiß, warum das Essen fehlgeschlagen ist. Er verbringt Stunden (die Arbeit gibt einen Median von 4 Stunden an) damit, fieberhaft seine eigenen Gewürze und Messer zu überprüfen, um zu beweisen: „Es war nicht ich!" Das kostet viel Zeit und verursacht Stress.
Was die Forscher taten
Die Autoren (ein Team von Forschern) beschlossen, dieses Küchenchaos zu untersuchen. Sie analysierten 77.354 „verbrannte Mahlzeiten" (Build-Fehler) aus 7 großen Open-Source-Softwareprojekten (wie Apache Hadoop und HBase).
- Die Detektivarbeit: Sie lasen manuell Tausende von Kommentaren durch, die von Entwicklern nach einem Fehler hinterlassen wurden. Sie suchten nach Phrasen wie „das hat nichts mit meiner Änderung zu tun" oder „unabhängig". Sie fanden etwa 10.300 Fälle, in denen Entwickler ausdrücklich sagten: „Dieser Fehler war nicht meine Schuld."
- Das Interview: Sie wählten eine kleinere, repräsentative Stichprobe von 371 dieser „nicht meine Schuld"-Fälle aus und analysierten sie wie ein Detektiv einen Tatort. Sie fragten: Warum sagten die Entwickler, dass dies nicht ihre Schuld war?
- Die Ergebnisse: Die häufigsten Gründe waren:
- Unabhängige Tests: Der fehlgeschlagene Test prüfte tatsächlich etwas aus einem anderen Teil der Küche, nicht die neue Zutat.
- Externe Einmischung: Etwas außerhalb der Küche änderte sich (wie ein Lieferant, der allen schlechtes Mehl liefert).
- Nicht reproduzierbar: Das Feuer passierte einmal, aber als sie versuchten, das Essen erneut zuzubereiten, war alles in Ordnung (vielleicht ein zufälliger Stromausfall).
- Die Gruppe „Nicht spezifiziert": In einem großen Teil (35 %) der Fälle sagten die Entwickler einfach „Es war nicht ich", ohne zu erklären, warum.
- Die Ergebnisse: Die häufigsten Gründe waren:
Die Lösung: Ein „Smarter Assistent"
Da Entwickler nicht immer sofort erklären können, warum ein Fehler unabhängig ist, stellten die Forscher einen Smarten Assistenten (ein maschinelles Lernmodell) her, um für sie zu raten.
Sie verwendeten eine spezielle Technik namens PU-Learning (Positive-Unlabeled Learning).
- Die Analogie: Stellen Sie sich vor, Sie versuchen, einem Hund beizubringen, eine bestimmte Art von Ball zu finden. Sie haben ein paar Bälle, von denen Sie wissen, dass sie die richtige Art sind (die positiven Beispiele). Aber Sie haben einen riesigen Haufen gemischter Bälle, bei denen Sie nicht wissen, welche die richtige Art sind und welche falsch (der unbeschriftete Haufen). Sie können nicht einfach sagen: „Alles andere ist ein falscher Ball", weil einige davon tatsächlich die richtige Art sein könnten, Sie sie nur noch nicht überprüft haben.
- Wie es funktionierte: Die Forscher fütterten ihr Modell mit den „bekannten unabhängigen Fehlern" und dem „unbekannten Haufen". Das Modell lernte, Muster zu erkennen, die darauf hindeuten, dass ein Fehler wahrscheinlich unabhängig ist, auch ohne ein klares Label.
Wie gut war der Assistent?
Das Modell wurde an denselben 7 Projekten getestet.
- Es war sehr gut bei der Präzision (wenn es sagte: „Das ist nicht Ihre Schuld", lag es meistens richtig, etwa 70 % bis 88 % der Zeit).
- Es war gut beim Recall (es fand die meisten unabhängigen Fehler, obwohl es einige verpasste).
- Es schnitt deutlich besser ab als zufälliges Raten oder einfache Regeln.
Die „Hinweise", die das Modell verwendete
Die Forscher fanden drei Hauptindikatoren, die dem Modell halfen zu entscheiden, ob ein Fehler unabhängig war:
- Die Zeitlücke (CI-Latenz): Wenn ein Entwickler Code gepusht hat und lange wartete, bevor er den Build ausgelöst hat, ist es wahrscheinlicher, dass jemand anderes in der Zwischenzeit die Küche kaputt gemacht hat.
- Der „Déjà-vu"-Fehler: Wenn die Fehlermeldung genau so aussieht wie eine, die kürzlich aufgetreten ist, ist es wahrscheinlich eine Wiederholung eines alten Problems und nicht eines neuen, das vom aktuellen Koch verursacht wurde.
- Das Geplauder: Wenn es viele Kommentare zum Problem gibt, bevor der Fehler aufgetreten ist, deutet dies darauf hin, dass das Problem komplex ist und wahrscheinlich die Arbeit anderer betrifft, nicht nur den aktuellen Push.
Das Fazit
Die Arbeit kommt zu dem Schluss, dass Entwickler durch die Verwendung dieses „Smarten Assistenten" einen schnellen Hinweis erhalten können: „Es besteht eine hohe Wahrscheinlichkeit, dass dieser Fehler nicht Ihre Schuld ist."
Das bedeutet nicht, dass sie das Problem ignorieren können, aber es sagt ihnen: „Verbringen Sie keine 4 Stunden damit, Ihren eigenen Code zu überprüfen. Prüfen Sie vielleicht den Ofen oder fragen Sie den anderen Koch." Dies hilft ihnen, Zeitverschwendung bei Fehlalarmen zu vermeiden und schneller wieder zum Kochen (Codieren) zurückzukehren.
Wichtiger Hinweis: Die Arbeit konzentriert sich ausschließlich auf die Identifizierung dieser Fehler in Softwareprojekten. Sie behauptet nicht, dass diese Methode für medizinische Diagnosen, den Finanzhandel oder andere Bereiche außerhalb der Softwareentwicklung funktioniert. Es ist strikt ein Werkzeug für Software-Teams, um ihr eigenes Küchenchaos zu bewältigen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.