Recentelijk is er binnen Recognize een migratie uitgevoerd van BitBucket naar GitHub in combinatie met Advanced Security. Tijdens zo’n migratie loop je tegen verschillende problemen aan, die je zoveel mogelijk voor wilt zijn om zo het ontwikkelproces zo soepel mogelijk te laten verlopen. Maar wat zijn de systemen, en waarom en hoe heeft deze migratie plaatsgevonden?
Geschreven door Bart Wesselink, Head of Development
Voor het opslaan van code wordt veelal Git gebruikt, een zogeheten versiebeheer systeem (ookwel VCS). Met een kun je ervoor zorgen dat ontwikkelaars op meerdere plekken tegelijk aan dezelfde code werken. Alle wijzigingen die ze doen worden bijgehouden en vastgelegd in een zogeheten commit, die vastlegt wie welke wijzigingen heeft gedaan. Deze wijzigingen kunnen uitgevoerd worden in verschillende branches (takken) van je code, waarbij deze uiteindelijk in de hoofdbranche weer bij elkaar komen en zo samengevoegd kunnen worden met de aanpassingen van mede-ontwikkelaars. Wijzigingen worden gepusht naar een centrale server (zoals bijvoorbeeld GitHub, GitLab of Bitbucket), zodat anderen deze kunnen inzien.
Tegenwoordig wordt versiebeheer voor veel meer gebruikt dan alleen voor het opslaan van code. Het is de basis van je code, je infrastructuur (middels het Infrastructure as Code principe) en je release proces. Dat laatste wordt gedaan met Continuous Integration (CI). Door een CI-proces in te richten op basis van je code, kun je ervoor zorgen dat automatische testen uitgevoerd worden op elke commit die gedaan wordt, om zo de kwaliteit van je product te waarborgen. Daarnaast kan CI gebruikt worden om automatische releases naar de cloud te doen op basis van de juiste commit. Zo kan code eenvoudig door een ontwikkel-, test-, acceptatie- en productiestraat heen.
Binnen Recognize hebben we jaren gebruik gemaakt van BitBucket als centraal systeem voor versiebeheer van code. Projecten werden gereleased en getest middels BitBucket Pipelines (het continuous integration systeem van BitBucket). Deze pipelines definieer je als script stappen die op een machine moeten uitgevoerd worden (denk daarbij aan het bouwen van je applicatie, het starten van je testen of het updaten van een omgeving).
Het laatste jaar hebben we aantal tekortkomingen gemerkt aan BitBucket, waardoor we verder zijn gaan kijken naar alternatieven en al vrij snel uitkwamen op GitHub. Hoewel de twee systemen in de basis niet extreem van elkaar verschillen, het hoofdproces is relatief gelijk, was er op het moment van kiezen een belangrijk verschil tussen de twee systemen. Binnen GitHub is het mogelijk om een extra tooling af te nemen, namelijk Advanced Security.
Binnen Advanced Security zijn erop verschillende niveau’s mogelijkheden om nog dichter op je code grip te krijgen op mogelijke veiligheidsirico’s, en hier snel op te handelen. De tooling biedt mogelijkheden om alle extern gebruikte bibliotheken te scannen en te controleren of er ergens kwetsbaarheden bekend zijn, en kan deze indien beschikbaar zelfs automatisch verhelpen. Daarnaast biedt Advanced Security mogelijkheden om kwetsbaarheden op code niveau te vinden met CodeQL. In een grote bibliotheek, beheerd door het securityteam van GitHub & mensen uit de open-source community, staan een hele boel bekende beveiligingsproblemen beschreven, waarop de code van een project dan gecheckt wordt, voordat dit ooit op een omgeving terechtkomt.
Met deze extra tooling willen we bij Recognize nog een extra stap zetten op het gebied van veiligheid.
Omdat BitBucket zo’n belangrijk onderdeel van het ontwikkelproces was binnen de organisatie, is er veel tijd gestoken in een proces waarbij projecten automatisch gemigreerd konden worden van BitBucket naar GitHub. Hoewel automatisch migreren het uitgangspunt was, bleek al snel dat een volledig automatische migratie niet reëel is, daarvoor zijn er te veel verschillen.
Het overzetten van het belangrijkste onderdeel, de code, is een vrij standaard proces. De code wordt vanuit de oude locatie, BitBucket, opgehaald en daarna weer op de nieuwe locatie weg te schrijven. Het meest lastige onderdeel van de migratie van een project, was het omzetten van de BitBucket Pipelines naar de variant die GitHub aanbiedt, namelijk GitHub Actions.
Het probleem van het migreren van dit CI-proces zit met name in een aantal verschillen qua werking en structuur. Daar waar BitBucket een enkele definitie van pipelines kent, splitst GitHub deze op in zogeheten workflows die (automatisch) gestart kunnen worden. Deze wijzigingen zijn nog eenvoudig te splitsen, maar waar het proces lastiger wordt, is bij secrets (geheime sleutels om bij bijvoorbeeld omgevingen te komen). In BitBucket zijn er ook variabelen die niet geheim zijn, maar enkel configuratie. In GitHub dienen deze volledig uitgeschreven te worden in een bestand. Door code slim te scannen op het gebruik van deze variabelen, konden deze op verschillende plekken worden weggeschreven.
Daarnaast zijn secrets versleuteld in zowel BitBucket als GitHub, waardoor deze niet zomaar uit te lezen zijn. Door een speciale beveiligde tunnel op te zetten tussen de twee systemen konden deze op een juiste manier uit BitBucket gehaald worden door een speciale pipeline te starten, waarna ze weggeschreven konden worden naar het juiste project in GitHub.
Hoewel het uitgangspunt inderdaad was om alles mogelijk automatisch in een enkele keer goed te migreren, bleek dat dat niet realistisch was. Voor 90% van de projecten konden pipelines helemaal omgeschreven worden naar werkende Actions in GitHub, maar voor enkele projecten diende een kleine manuele wijziging gedaan te worden. Er zitten altijd kleine verschillen in de 2 omgevingen en de manier waarop scripts worden uitgevoerd waardoor het vrijwel onmogelijk is om die op een automatische manier te verhelpen. Echter, door alles wat mogelijk was automatisch klaar te zetten, was het aantal manuele ingrepen minimaal.
Doordat versiebeheer van code een belangrijk onderdeel is in de ontwikkeling van een softwareproject, is ervoor gekozen om alle migraties per team te doen, en deze in het weekend uit te voeren om ervoor te zorgen dat processen konden doorlopen. Door team voor team te migreren, konden er gedurende de hele migratie kleine verbeteringen in het migratieproces worden aangebracht.
Ondertussen is de migratie succesvol afgerond en werken onze softwareontwikkelteams die met BitBucket werken ondertussen op GitHub. Benieuwd naar meer technische details? Neem gerust contact op!
Benieuwd naar wat we voor jou kunnen betekenen? Of kun je iets voor ons betekenen? Dan horen we graag van je! Bel of mail gerust. We komen graag langs om kennis te maken. En natuurlijk staan onze deuren op de zevende verdieping van de Javatoren in Almelo ook altijd voor je open.
