Papers we love: pull-based software development

De paper van deze maand is weer een jonge paper — gepubliceerd in 2013 — en is afkomstig van SERG te Delft. Hij heet “An Exploratory Study of the Pull-based Software Development Model“. Centraal staat de manier van samenwerken die mogelijk gemaakt is door decentrale versie-beheersystemen zoals Git: pull-based development. Dit model, vaak gefacilliteerd door producten als Github, Gitlab of Bitbucket, stelt je in staat een complete eigen kopie te maken van de development repository. Changes aan de code-base kun je dan, eventueel gebundeld, aan de hand van een pull-request weer aanbieden aan de “upstream” eigenaar van het project.

Iedere kloon van de originele upstream repository zelf verantwoordelijk is voor de integratie van de door hen aangeboden changes in combinatie met het upstream development werk. Hierdoor is het een eenvoudige, overzichtelijke manier om werk — structureel dan wel incidenteel — te distribueren over verschillende onderliggende partijen. Wat betreft distributie wordt in dit paper wordt voornamelijk naar de pull-request implementatie van Github gekeken. Hier ben je ook nog in staat om, naast het mergen van de code, ook een code review uit te voeren en eventuele randzaken te bediscussiëren. Dit alles wordt geaggregeerd binnen een pull-request. De auteurs geven aan dat een pull-request als effectief beoordeeld kan worden als deze überhaupt gemerged wordt en efficiënt als de doorlooptijd ervan heel kort is. Deze paper focust zich hierop en probeert te definieren hoe populair de pull-request manier van werken is en welke factoren de effectiviteit en efficiëntie van individuele bijdragen beïnvloed.

Om deze vragen te beantwoorden wordt er een model ontwikkeld wat gebruikt kan worden om individuele pull-requests te beoordelen. Voor dit model zijn 12 karakteristieken geselecteerd die onder te verdelen zijn in drie groepen. Een van de eerste dingen die hiervan opvalt is dat het grootste gedeelte van de pull-requests binnen drie dagen is gemerged. Voor 30% is dit zelfs binnen een uur. Of een pull-request uit het team komt of uit de community heeft hier opvallend genoeg geen invloed op. Een andere verrassing, tevens strijdig met ander research werk, is of het accepteren van een pull request wordt versneld wanneer er test code is toegevoegd in de pull-request. Er is hier nagenoeg geen verband tussen te vinden.

Ook de overige conclusies zijn ook interessant. De belangrijkste drie factoren om een pull-request te mergen zijn a) hoe actief een stuk code is geweest in de afgelopen tijd (met t = 3 maanden), b) hoe groot het project totaal is en c) hoeveel bestanden er worden gewijzigd in de pull-request. Voor de tijdsduur zijn de drie belangrijkste factoren a) het aantal comments die een pull-request bespreken, b) de grootte van het project en c) de test-coverage van een project.

Kortom, de meest succesvolle pull-requests worden dus aangeboden in actieve stukken code van een groot project wat veel test coverage heeft en weinig discussie krijgt in de comments. Tot noch toe is dit geen rocket science. Meer genuanceerd wordt het als je de doorlooptijd vergelijkt met andere versiebeheersystemen die ook aangedragen patches accepteren en conditioneel opnemen in de codebase. Hierbij zie je dat de doorlooptijd bij een pull-request model significant korter is. Of, zoals de paper het benoemd, projecten met een pull-request development model hebben een hogere “turnover rate” met betrekking tot het mergen van patches.

Dit betekent dat het pull-request een laagdrempeliger model is voor het ontvangen van bijdragen. Het facilliteert zogenaamde “drive-by-commits”. Doordat het forken en aanbieden van een pull-request zo eenvoudig is zie je dat mensen snel geneigd zijn om, wanneer zij een defect ontdekken, ook even snel een patch in willen sturen ter verbetering. Een naïeve schatting op de dataset gebruikt in de paper geeft al dat er minimaal in zo’n 3.5% van de gevallen sprake is van zo’n “drive-by-commit”.

Een laatste effect is vooral belangrijk voor community projecten. Door de openbare discussies wordt het ook eenvoudiger voor de community van een project om zich te bemoeien met inhoudelijke zaken. Hierdoor is de transparantie erg groot en wordt de engagement vergroot. Er is er sprake van een democratisering van een project, waarbij iedereen de kans krijgt om bij te dragen. Het voordeel is dat de de eigenaar ervan de touwtjes niet uit handen hoeft te geven. Bijdragen zullen immers worden aangeboden met een pull-request, wat mergen zeer eenvoudig maakt.

In mijn ogen laat dit model zien hoe je succesvol met snel veranderende software om kunt gaan. In een open-source context is dit voordeel het meest voor de hand liggend. Hierbij wil je zo veel mogelijk betrokkenheid van een community om het project als geheel zo succesvol mogelijk te maken. Persoonlijk denk ik echter dat dit verder strekt dan alleen open source. Binnen (grote, corporate) organisaties spelen veel van dezelfde problemen. Andere teams, afdelingen of zelfs geografische locaties die aan compleet andere software werken zijn ook partijen die je in het dagelijks gebruik als upstream partij van een project kunt beschouwen. Vaak heb je hier wel mee te maken omdat je bijvoorbeeld gebruikt maakt van externe services, libraries of frameworks. Op het moment dat je fouten ontdekt in een project zou je ook graag een “drive-by-commit” aan willen kunnen bieden om een structurele verbetering uit te voeren. Daarnaast kan een discussie die ontstaat bij een pull-request zeer waardevol zijn voor de binding tussen de verschillende partijen.

Wanneer je het bovenstaande toepast in een grote organisatie die bijvoorbeeld met een microservices architectuur aan de slag wil, of wanneer er met complexe ketens van services wordt gewerkt dan is de meerwaarde snel gevonden. Idealiter maak je dan alle corporate software “open source”, waarbij je de code op een interne Github of iets vergelijkbaars aanbied. Zorg vervolgens dat alle engineers  hier bij kunnen. Wanneer nu een een engineer X van team A een fout in service Y van team B vind, kan hij eenvoudig weg dit project forken, een patch ontwikkelen, een pull-request maken van zijn patch en deze aanbieden aan team B. In dit scenario blijft team B in control van “hun” stukje software, terwijl team A, met specifiek engineer X, toch een structurele bijdrage kan leveren aan service Y. Het netto resultaat hiervan is een organisatie die overall beter is geworden, terwijl de doorlooptijd van de verbetering minimaal was. Wanneer (meer) bedrijven dit zouden omarmen zou dit ons leven een stuk eenvoudiger maken denk ik..


Over deze papers we love: binnen Sogyo hebben we de traditie dat we maandelijks een nieuwsbrief rondsturen. De nieuwsbrief gaat veel over interne feitjes, echter sinds februari 2015 verzorgd Kevin van der Vlist het topic: papers we love. Hij deelt met ons papers die interessant zijn om te lezen en ons kunnen inspireren. De topic is uitgegroeid tot een mooie verzameling die we ook graag hier willen delen.