Ontwikkelstraat – Versiebeheer (deel 2)

In het open source domein zijn diverse oplossingen beschikbaar voor versiebeheer. In dit artikel komen een drietal producten aan de orde die op verschillende leest zijn geschoeid.

bronco

Architectuur: Centraal of gedistribueerd
Allereerst zijn er twee verschillende architecturen. De eerste, klassieke, wijze is er een met één centrale repository, ookwel Central Version Control System (CVCS) . In deze centrale repository staan alle wijzigingen. Om gebruik te kunnen maken van deze repository moet men altijd een connectie tot stand kunnen brengen naar deze repository. Gebruikers downloaden een lokale kopie van alle sources en de wijzigingen worden weer direct in de centrale repository gezet. De bekendste voorbeelden van een CVCS zijn Subversion en CVS.

De tweede architectuur is de zogenaamde gedistribueerde architectuur (ookwel: Distributed Concurrent Versioning System, DCVS). Het belangrijkste verschil vanuit het perspectief van de ontwikkelaar is dat deze een eigen kopie van de repository heeft, een zogenaamde kloon. De consequentie hiervan is dat de ontwikkelaar deze complete history tot z’n beschikking heeft, ook als er geen connectie is naar de “centrale” repository. Dit heeft twee voordelen. Ten eerste kan je dus beter werken op afstand faciliteren. Ten tweede is het mogelijk om wijzigingen op sources eerste lokaal in te checken zonder dat andere gebruikers daar direct “last” van hebben. Op gezette tijden kan een ontwikkelaar er voor kiezen om de wijzigingen (de zogenaamde changesets) te uploaden naar de centrale repository. Het geeft de ontwikkelaar meer controle over het proces van wijzigingen inchecken en delen met de buitenwereld. De twee grootste DCVS’s zijn Git & Mercurial.

Door de flexibiliteit die een DCVS biedt voor de ontwikkelaar, maar ook voor het ondersteunen van teams en de mogelijkheden tot schaalbaarheid, is dit de voor de hand liggende keuze als een nieuw versiebeheer systeem moet worden geïmplementeerd. Daarnaast is DCVS’s eigenlijk de defacto standaard binnen de Open Source community. Daarom nemen we voor de rest van dit artikel een DCVS aan.

DCVS: de mogelijkheden
Zoals reeds gesteld is de flexibiliteit van de DCVS het grote pré. Het kunnen maken van een kloon van een repository, een kopie die op de hoogte is van zijn oorsprong, biedt zeer veel mogelijkheden. Onderstaand plaatje geeft een voorbeeld van wat één van die mogelijkheden is:5

Iedere rechthoek is een repository. Dit ziet er in eerste instantie gecompliceerd uit, maar is een oplossing om teams te ondersteunen. Een andere (eenvoudiger) mogelijkheid is één centrale repository en een kloon voor iedere ontwikkelaar. De essentie is dat de DVCS architectuur iedere configuratie mogelijk maakt, maar ook om deze in een later stadium aan te passen aan wijzigingen in de organisatie of voortschrijdend inzicht.

Tooling
Alle bovengenoemde VCS hebben standalone tooling. Naast de commandline tools is altijd wel een grafische interface beschikbaar. Het wordt echter pas echt efficiënt als een VCS naadloos integreert met bijvoorbeeld Eclipse (lees: PDSOE). Onderstaand figuur geeft weer hoe dit er uit ziet:
eclipse
Voor alle bovengenoemde VCS tools zijn er plugins beschikbaar voor Eclipse. Op deze wijze is er in de Project Explorer van PDSOE niet alleen te zien welke sources er in een directory staan maar ook wat hun (VCS) status is.

Implementatie
Een nieuw VCS implementeren is geen klusje voor een regenachtige zondagmiddag. Vooral voor degene die gewend zijn te werken met één centrale repository is het een behoorlijke mindshift voordat de werkwijze en de voordelen hiervan helder zijn. Een aantal aanbevelingen:

  • Kies een DCVS, Mercurial heeft mijn persoonlijke voorkeur boven bijvoorbeeld Git. Dit heeft er vooral mee te maken dat Mercurial iets eenvoudiger is in gebruik. Dit maakt adoptie makkelijker.
  • Leer deze VCS vanaf de commandline. Dit komt wellicht ouderwets over maar, zeker in het geval van Mercurial, maakt alle tooling gebruik van de commandline tools en verwerkt de informatie die deze commandline tools geven. Let hierbij op branching, merging, et cetera.
  • Bedenk hoe de ontwikkelteams nu werken of hoe ze zouden moeten werken.
  • Map deze werkwijze op de indeling van repositories & branches.
  • Zorg voor een enthousiaste expert user in het team, dit helpt om de initiële hobbel te slechten en anderen gemotiveerd te houden. Gebruikers die het door hebben willen niets anders meer (meestal).
  • Overweeg om niet alleen sources, maar ook .df files, buildscripts en dergelijke in het VCS te zetten. “Als het niet in het VCS zit bestaat het niet” (quote van de auteur).

Integratie
Mercurial, maar ook Git, sluit naadloos aan op (build)tools die later in deze serie aan bod komen. Een buildtool als Jenkins sluit direct aan op het VCS en maakt het mogelijk om iedere gewenste “branch” te bouwen. Tools als Git & Mercurial worden gebruikt als VCS voor Linux, Mozilla, et cetera. De consequentie van dit soort gebruikers is dat de tooling over het algemeen meer dan in orde is, alsook de integratie met andere producten (IDE’s, Continous Integration tools, Issue management)

Conclusie
Een modern VCS is een DCVS. Tools als Mercurial en Git hebben een enthousiaste community van gebruikers het integreert uitstekend met de rest van de ontwikkelstraat. De flexibiliteit van een DCVS maakt dat het ook in de toekomst uitstekend past in het ontwikkelproces. Daarnaast wordt de ontwikkelaar geholpen met een overzichtelijk beeld van de wijzigingen in de software. Een succesvolle implementatie van een VCS kan alleen door een gedegen kennis. De keuze voor een modern DCVS levert, in combinatie met de overige tooling die hiervan gebruik kan maken, een omgeving op waarmee jaren ontwikkeld kan worden.

In de volgende blog gaan we kijken naar de mogelijkheden om op basis van ANT alle sources te compileren en te packagen. Ook kijken we hoe alles gecombineerd kan worden tot een geoliede en geautomatiseerde bouwstraat. Dus hou dit blog in de gaten!

 

Links

- http://mercurial.selenic.com
- https://bitbucket.org
- http://git-scm.com
- https://github.com
- http://stackoverflow.com/questions/2479274/using-mercurial-in-a-large-organization
- http://www.google.nl