Hoe vaak wordt de constructie kapot gemaakt?

Ik heb gemerkt dat builds kapot zijn en dat tests veel vaker mislukken bij open source-projecten dan bij ‘werk’-projecten. Ik wist niet zeker hoeveel daarvan mijn perceptie versus de realiteit was, dus pakte ik de Travis CI-gegevens voor een paar populaire categorieën op GitHub.

Ter referentie: op elke plek waar ik heb gewerkt, zou een betrouwbaarheid van twee negens (99% uptime) van de build als slecht worden beschouwd. Dat zou betekenen dat de bouw ruim drie en een halve dag per jaar, oftewel zeven uur per maand, faalt. Zelfs drie 9’s (99,9% uptime) betekent ongeveer vijfenveertig minuten downtime per maand. Dat is best oké als er geen hard systeem is om te voorkomen dat mensen slechte code inchecken, maar het is nogal slecht voor een plek die serieus bezig is met werkende builds.

Daarentegen is de betrouwbaarheid van 2 9s ver boven het gemiddelde voor de projecten waarvoor ik gegevens heb verzameld – slechts 8 van de 40 projecten zijn zo betrouwbaar. Bijna twee keer zoveel projecten – 15 van de 40 – halen niet eens een 9 aan uptime. En mijn steekproef is sterk gericht op betrouwbare projecten. Er zijn projecten die bekend genoeg waren om te worden “uitgelicht” in een met de hand samengestelde lijst van GitHub. Dat vertekent de gegevens daar al. En daarna heb ik alleen maar gegevens verzameld van de projecten die genoeg om testen geven om TravisCI op te zetten, wat een nog sterkere bias introduceert.

Om er zeker van te zijn dat ik geen slechte voorbeelden pakte, heb ik alle aanvankelijke mislukte tests verwijderd (er zijn vaak veel mislukkingen als mensen Travis proberen in te stellen en het verkeerd configureren) en projecten die een ander systeem gebruiken voor het volgen van builds die alleen Travis als bijzaak hebben (zoals Rust).

Waarom mislukt de build niet altijd op het werk? Ingenieurs houden er niet van om te wachten tot iemand anders de build ongedaan maakt en managers kunnen de achterkant van de envelopberekening doen, die zegt dat N inactieve engineers * X uur kapot gaan van de build = $ Y verspild geld.

Maar diezelfde logica is van toepassing op open source-projecten! In plaats van dollars te verspillen, wordt de tijd van de bijdrager verspild.

Webprogrammeurs zijn zich er zeer van bewust hoe 100 ms extra latentie bij het laden van een webpagina een merkbaar effect heeft op de conversieratio. Welnu, wat is het effect op de conversieratio als een potentiële bijdrager aan uw project 20 minuten besteedt aan het installeren van afhankelijkheden en een uur aan het bouwen van uw project om vervolgens te ontdekken dat de build kapot is?

Ik zocht altijd door dit soort fouten heen om de bug te vinden, waarbij ik meestal aannam dat het een configuratieprobleem moest zijn dat specifiek was voor mijn machine. Maar na jarenlang te hebben gewerkt aan het debuggen van fouten waar ik tegenaan loop make check bij een schone build heb ik ontdekt dat het vaak komt doordat iemand slechte code heeft ingecheckt. Als ik er tegenwoordig aan denk om bij te dragen aan een project of een bug te repareren en de build werkt niet, ga ik verder met een ander project.

Het ergste van regelmatige build-fouten is dat ze gemakkelijk te voorkomen zijn. Graydon Hoare noemt het schoonhouden van een schone constructie letterlijk de ‘not rocket science rule’, en schreef een open source tool (bors) die iedereen kan gebruiken om aan not-rocket-science te doen. En toch hebben de meeste open source-projecten nog steeds te lijden onder kapotte en mislukte builds, samen met de daarmee gepaard gaande kosten van verloren ontwikkelaarstijd en verloren ontwikkelaars-‘conversies’.

Lees niet te veel in de individuele gegevens in de grafiek. Ik vind het interessant dat DevOps-projecten doorgaans betrouwbaarder zijn dan talen, die doorgaans betrouwbaarder zijn dan webframeworks, en dat ML-projecten overal voorkomen (maar meestal betrouwbaar zijn). Maar als het om individuele projecten gaat, kunnen allerlei zaken ervoor zorgen dat een project slechte cijfers heeft.

Met dank aan Kevin Lynagh, Leah Hanson, Michael Smith, Katerina Barone-Adesi en Alexey Romanov voor commentaar.

Ook een compliment aan Michael Smith van Puppetlabs voor een vriendelijke ping en het doornemen van de buildgegevens voor de puppet om er zeker van te zijn dat er geen bug in mijn scripts zat. Dit is een van mijn meest verguisde blogposts omdat niemand wil geloven dat de build voor hun project vaker kapot gaat dan de build voor andere projecten. Maar hoewel het slechts ongeveer een minuut duurt om de gegevens voor een project op te halen en deze te controleren met behulp van de links in dit bericht, heeft slechts één persoon de gegevens daadwerkelijk met mij doorgenomen, terwijl een aantal mensen mij vertelden dat het overduidelijk onjuist moest zijn zonder ooit de gegevens te hebben gecontroleerd.

Dit wil niet zeggen dat ik geen bugs heb. Dit is een snelle hack die waarschijnlijk bugs bevat en ik ben altijd blij met bugrapporten! Maar sommige niet-bugs die herhaaldelijk zijn gemeld, zijn het verkrijgen van gegevens van alle branches in plaats van de hoofdbranch, het verkrijgen van gegevens voor alle PR’s en niet alleen code die daadwerkelijk is ingecheckt in de hoofdbranch, en het gebruik van het aantal mislukte builds in plaats van de hoeveelheid tijd dat de build niet beschikbaar is. Ik ben er vrij zeker van dat je kunt controleren of al deze beweringen vals zijn in ongeveer dezelfde tijd die nodig is om de bewering te doen, maar dat weerhoudt mensen er niet van om de bewering te doen.