Sytse Sijbrandij is medeoprichter van Gitlab.com, samen met Gitlab-hoofdontwikkelaar Dmitriy Zaporozhets. Sinds een half jaar biedt dit Nederlandse bedrijf diensten aan rond de gelijknamige versiebeheeroplossing, waaronder Gitlab-hosting in Saas-vorm, supportcontracten voor interne Gitlab-servers, consultancy en trainingen.

29 March 2013

Bij softwareontwikkeling is samenwerking essentieel. Een belangrijke rol is hierbij weggelegd voor het versiebeheersysteem. De introductie van nieuwe systemen zoals Git en Gitlab heeft de manier van samenwerken veranderd. Het is nu mogelijk om vaker een versie uit te brengen, met kleinere veranderingen per keer. Dit zorgt voor minder verspilling en een voorspelbare planning, betoogt medeoprichter Sytse Sijbrandij van Gitlab.

Het is niet gek dat gebruikers van oude, centrale versiebeheersystemen slechts sporadisch een software-update uitbrengen, met grote veranderingen per keer. Bij systemen zoals CVS en Subversion is het namelijk niet eenvoudig om verschillende versies samen te voegen. Daardoor is het gebruikelijk dat alle ontwikkelaars in dezelfde versie werken. Dat maakt het echter een hele klus om de software helemaal correct en compleet te houden.

Deze tekortkoming van de oude versiebeheersystemen heeft ertoe geleid dat hun gebruik gepaard gaat met een tweedelige ontwikkelcyclus. De eerste fase is de integratie van nieuwe functionaliteit. Hierbij gaat de algemene kwaliteit van de software achteruit. De tweede fase is de zogeheten feature freeze, waarbij de boel wordt bevroren om de code weer correct en compleet te krijgen. Na elke cyclus volgt de uitgifte van de software aan de eindgebruikers.

Gitlab dashboard

Inmiddels zijn er nieuwe, decentrale versiebeheersystemen op de markt gekomen. Een bekende oplossing uit de opensourcewereld is Git, oorspronkelijk gemaakt voor de ontwikkeling van de Linux-kernel (zie kader). In tegenstelling tot CVS en Subversion leunt dit systeem niet op een centrale server, maar gaat het uit van lokale werkmappen die alle data plus een complete, volledig traceerbare bewerkingsgeschiedenis bevatten. Doordat verschillende versies eenvoudig zijn samen te voegen, kunnen een heleboel ontwikkelaars parallel aan hetzelfde softwareproject werken.

Ten grondslag aan deze verbetering ligt het feature branch-idee van software-expert Martin Fowler. Hierbij krijgt elke nieuwe functionaliteit een eigen vertakking in de versieboom. Pas op het moment dat de feature correct en compleet is, wordt hij middels een merge toegevoegd aan een release. Zo is er op elk moment een nieuwe softwareversie te maken.

Eén aanpak is om bij elke merge een update uit te brengen. Dit heet continuous delivery en vindt steeds vaker toepassing, bijvoorbeeld bij leveranciers van online softwareservices (Saas). Een andere mogelijkheid is om na een vaste periode een volgende release te doen. Zo komt de Linux-kernelgemeenschap elke twee maanden met een nieuwe versie.

Geautomatiseerde integratie

De combinatie van Git en e-mail is in principe voldoende voor modern versiebeheer. Efficiënt is echter anders. Daarom zijn er in de loop der tijd verschillende webinterfaces ontstaan die het samenwerken aan een stuk code eenvoudiger, overzichtelijker en sneller maken. De eerste was Gitweb, dat nog steeds wordt meegeleverd met Git.

In 2008 ontstond Github. Deze website ontketende een revolutie in het gebruik van Git, onder meer door de introductie van namespaces. Hiermee kan iedereen zijn eigen afgeleide (fork) maken. Door een pull request te verzenden, zijn wijzigingen weer terug te sturen naar de originele softwaretoepassing. Dit en de gratis abonnementen voor opensourceprojecten hebben Github gemaakt tot hét platform voor de ontwikkeling van deze projecten.

Gitlab projectboom

In 2011 zag Gitlab het levenslicht, met als doel iedereen in staat te stellen zelf een webinterface te draaien voor Git. Het project biedt een opensource en veilig alternatief voor dure en/of ingewikkelde commerciële oplossingen. Gitlab is een uitkomst voor bedrijven die hun code niet graag bij een externe partij stallen. Verder onderscheidt het zich onder meer door een geavanceerd rechtensysteem. Op dit moment hebben al meer dan tienduizend organisaties een interne Gitlab-server draaien.

Uiteraard biedt Gitlab ook uitgebreide functionaliteit voor het werken in aparte versies. Wie een branch wil samenvoegen, stuurt een merge request. Dat is gelijk een uitgelezen moment voor een codereview, waarbij de auteur zijn voorgestelde wijzigingen aanpast op basis van het commentaar dat hij krijgt van de andere ontwikkelaars in het project.

Een continuous integration-applicatie (CI) test de resulterende software. Een bekend voorbeeld van zo‘n applicatie is Jenkins. Onlangs heeft Gitlab ook een eigen CI-oplossing op de markt gebracht. Deze maakt het mogelijk om direct in de merge requests aan te geven of de tests nog steeds werken na een eventuele samenvoeging. Dan is het wel belangrijk dat die tests representatief zijn, wat te waarborgen is door handmatige tests zo veel mogelijk te vervangen door geautomatiseerde integratietests.

Gitlab projectmanager

Voorspelbare planning

Door pas tot samenvoeging over te gaan als alle betrokken ontwikkelaars en de tests akkoord zijn, is de code in een project relatief eenvoudig correct en compleet te houden. Een feature freeze voor uitgifte van de software is niet meer nodig. Dit maakt frequentere releases met kleinere wijzigingen mogelijk.

Het vaker uitgeven van software heeft drie voordelen. Ten eerste reduceert het de hoeveelheid code die nog niet in een release zit. Deze voorraad behoeft continue afstemming; wijzigingen van de ene ontwikkelaar kunnen gevolgen hebben voor een ander projectlid. Door de hoeveelheid nog niet gereleasete code te verkleinen, is ook minder afstemming nodig.

Ten tweede zijn productieproblemen beter traceerbaar. Er zijn minder veranderingen per release, dus de hooiberg om de fout in te zoeken, is ook kleiner. Daarnaast ligt de code waar het probleem zich voordoet vaak nog vers in het geheugen omdat er maar een korte periode zit tussen releases.

Ten derde is een meer voorspelbare planning mogelijk. Het gebruik van tijdgebaseerde releases zorgt ervoor dat iedereen weet wanneer een nieuwe versie uitkomt. In organisaties die werken in sprints ligt het voor de hand om de releases hierop af te stemmen.

Edited by Nieke Roos