Migratie broncode SVN naar GitLab

Migratie broncode SVN naar GitLab

Net als andere IT-bedrijven die webapplicaties ontwikkelen maken wij ook gebruik van een versiebeheersysteem. Hiermee wordt op een centrale plek alle broncode van webapplicaties bewaard. Handig als je met meerdere ontwikkelaars aan een project werkt of wilt zien hoe broncode door de jaren heen veranderd is. Daarnaast heb je meteen een back-up.

Jaren geleden heeft Sidekick-IT het versiebeheersysteem Subversion geïmplementeerd. Er is toen gekozen voor SVN vanwege de betrouwbaarheid en de uitstekende ondersteuning in ontwikkelomgevingen zoals Eclipse en Netbeans. Daarnaast was het ook nog eens erg populair.

Door de jaren heen bleek SVN goed te werken maar ontstonden er wel een aantal problemen. Een van die problemen was het samenvoegen van verschillende wijzigingen in de broncode. Een ander probleem was dat de snelheid soms ook tegenviel. Zo’n 6 jaar geleden hebben wij PHPStorm als ontwikkelingomgeving gekozen ondanks dat deze een wat minder goede ondersteuning voor SVN had in vergelijking met Eclipse. TortoiseSVN is een goed programma om met SVN te werken maar dat werkt alleen op Windows en bij ons is MacOs de standaard.

Eind 2017 is na 12 jaar gekozen om over te stappen op het versiebeheersysteem Git. Dit bestond toen ook al maar was veel minder popuplair dan SVN. Een serieuze concurrent had Mecurial kunnen zijn, maar dat wordt minder gebruikt bij de ontwikkeling van webapplicaties. Er is gekozen voor Git om de problemen, die zich voordeden bij SVN, te voorkomen.

SVN hebben we jarenlang intern op onze eigen servers gebruikt. Een paar jaar geleden zijn zoveel mogelijk eigen interne servers afgestoten. In 2015 zijn we daarom al overgestapt naar Microsoft Office 365. Om onderhoud en kosten te besparen is Git direct op een externe server te bewaren.

Git is alleen een VCS (versioning control system). Om nog meer uit Git te halen maken we gebruik van de externe servers van GitLab. Zij leveren een degelijke webinterface voor de browser waarmee je door alle versies van de code kan bladeren. GitLab biedt o.a. ook ondersteuning voor continuous development, continuous integration en een issuetracker.

Verschillen SVN en Git

Een verschil tussen SVN en Git is, dat SVN in onze setup is ingericht met 2 repositories waarin de broncode wordt bewaard. Vergelijk het met een grote map op een computer. Een voordeel was dat je hierdoor snel globale bewerkingen op alle broncode uit meerdere projecten kon uitvoeren. Git hanteert het principe van 1 repository per project waardoor globale bewerkingen niet zo eenvoudig meer uitgevoerd kunnen worden. Een ander verschil is dat bij een SVN commit, iets in SVN plaatsen, dit meteen zichtbaar was omdat dat direct op de server geplaatst wordt. Voor Git moet je na een commit ook nog een push doen om het echt bij de server, in ons geval GitLab, zichtbaar te krijgen. Dit vereiste van de programmeurs een nieuwe manier van werken. Met Git is het mogelijk om een groep commits in een keer op de server te plaatsen. En dat levert weer tijd op.

Best practice

De migratie had een doorlooptijd van ongeveer 3 maanden. In die tijd zijn er importscripts geschreven, testen gedaan en is de feitelijke migratie uitgevoerd. Voor de migratie is gebruik gemaakt van complexe Bash (shell) scripts. Daarom is intern de kennis en ervaring met shell scripts ook enorm uitgebreid. Andere aandachtspunten tijdens migratie waren de verschillen tussen SVN en Git. Zo kent SVN zogeheten “properties” zoals svn:externals wat bij Git weer submodules zijn en de svn:ignore property is bij Git een bestand genaamd .gitignore.

Tijdens het testen kwamen we er ook achter dat Git geen mappen wil toevoegen als er geen bestanden in zitten. Git voert namelijk geen versiebeheer uit op mappen maar wel op bestanden. De gebruikte bash scripts hebben we daarom zo aangepast dat iedere map die leeg was werd voorzien van een .gitkeep bestand. Dit .gitkeep bestand was gewoon een simpel leeg tekstbestand maar voldoende voor GIT om de map toe te voegen aan het versiebeheersysteem.

Ervaring

Inmiddels zijn we 3 tot 4 maanden verder en zijn we positief over GitLab. In de eerste dagen na migratie hadden wel wel performance problemen bij GitLab. Die zijn er nog steeds, maar wel een stuk minder. GitLab neemt deze problemen serieus en probeert deze zo snel mogelijk op te lossen. Voor de rest zijn er eigenlijk geen problemen ondervonden en wordt GitLab inmiddels door iedereen gebruikt.

Op dit moment maken we steeds meer gebruik van tickets om zo op een centrale plek een overzicht te krijgen van acties die nog verricht moeten worden. Ook zijn we meer aan het experimenteren met continuous integration en continuous development. Over deze drie onderwerpen vertellen we in toekomst meer in een nieuw blog.

 

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *