Op donderdag 23 mei 2019 organiseerde we bij True een Masterclass voor Continuous Integration & Continuous Delivery. In deze sessie vertelden Marc Ypes, Software Engineer bij True, en John Zwarthoed, Scrum Master bij True, de ruim 18 aanwezige developers hoe zij kunnen starten met CI & CD met behulp van onder andere GitLab. Behalve theorie was er vooral tijd om aan de slag te gaan.
Bekijk onze Managed Azure dienst
Marc begon zijn talk met een introductie over zichzelf. Sinds 2015 is hij developer en ontwikkelt hij de interne systemen van True, zoals het ticketingsysteem TrueCare. Naast zijn werk bij True draagt Marc bij aan diverse open-source projecten. Zo is hij bijvoorbeeld een van de core-developers van CakePHP, een PHP-framework om snel en veilig kleine en complexe webprojecten te bouwen.
De noodzaak van CI/CD
Marc begon met korte introducties van de begrippen Continuous Integration (CI) en Continuous Delivery (CD).
Continuous Integration
Bij Continuous Integration integreer je continu de code van je team vanuit een gedeelde repository. Ontwikkelaars kunnen hun code in een Merge (Pull) Request zetten, waarde je pipelines kunt triggeren voor het bouwen, testen en valideren van nieuwe code voordat deze doorgevoerd worden in een release.
Marc:“De meeste ontwikkelaars zijn bezig met Continuous Integration omdat je hiermee zo vroeg mogelijk fouten kunt detecteren in je code, maar ook omdat je hiermee direct integratie-issues kunt reduceren. De code zit frisser in je hoofd, omdat je er niet twee weken geleden mee bezig was maar een paar seconden geleden.”
Continuous Delivery
Continuous Delivery is met name een ‘software engineering approach’. Marc: “Alle taken die onderdeel zijn van het releaseproces test je met Continuous Delivery. Je valideert je code en releases.” Je test dus ook of alle migratie’s en dergelijke die in productie nodig zijn werken.
Zelf is het development-team is bezig om via pipelines alles naar productie te deployen, al vinden er ook nog handmatige checks plaats in de acceptatie-omgeving.
Andere voordelen van Continuous Delivery is dat elke verandering releasable is, dat je een lager risico op fouten hebt per release, meer releases kunt doen en sneller feedback loops inbouwt. Dit maakt het een perfecte benadering voor ontwikkelaars die Agile-ontwikkelmethodieken hanteren zoals Scrum of Kanban.
Het roer om
Een jaar of drie geleden waren veel van de interne systemen bij True nog monolithische applicaties, waaronder ook TrueCare. Het roer moest om, dus besloot het developmentteam te gaan voor microservices. Er werd onder andere een vaste stack van frameworks (CakePHP, Angular 7) bepaald en een AppSkeleton ontwikkeld. Dit was gelijk ook het moment om de eerste grote stappen te zetten met Continuous Integration en Continuous Delivery.
Lees ook: De microservices-architectuur van TrueCare
Marc: “In die tijd gebruikte we Github voor onze code, Travis voor unit tests, Gitflow voor releases en Ansible voor de automatische deployments.”
Al snel bleek deze CI/CD-stack niet helemaal aan de wensen te voldoen en werd de overstap gemaakt naar GitLab. Dit had direct een aantal voordelen. “De code is te integreren met pipelines en je kunt van alles aan elkaar koppelen. Ook is het open-source met een zeer actieve community, en kun je ervoor kiezen om de software zelf te hosten op je server. Dat was voor ons als hostingprovider een belangrijk pluspunt.”
Marc noemde ook de schaalbaarheid van GitLab, een belangrijke factor omdat het developmentteam ook werkt met containers en Kubernetes, technologie die in staat moet zijn om snel te kunnen (auto)scalen als de applicatie daarom vraagt.
GitLab
Er volgde een introductie in Gitlab en hoe True zijn pipelines daarmee ontwikkelt. “Gitlab is eigenlijk een hele mooie API maar voor Gitlab CI/CD heb je ook nog een runner nodig. Die moet je los van een server installeren”, aldus Marc. Een GitLab Runner wordt gebruikt om jobs te runnen en de resultaten terug te sturen naar GitLab. Het wordt samengebruikt met een GitLab CI, de open-source service binnen GitLab dat de jobs coördineert (bron).
Om hiermee te starten heb je allereerst een .gitlabl-ci.yml bestand nodig die je toe kunt voegen aan de root directory van je repository. In deze YAML-file vertel je in feite wat de GitLab Runner moet doen. Een vaak gebruikte standaard bestaat meestal uit drie stages: build, test en deploy, maar je hoeft niet al deze stages te definiëren in de YAML-file.
Ook aan de slag met GitLab CI/CD? Bekijk dan zeker ook de handige documentatie van GitLab zelf .
Build Your own Pipeline (BYoP)
Na de break gingen de deelnemers zelf een aantal Gitlab jobs bouwen. Vooraf had iedere deelnemer Git al geïnstalleerd. John Zwarthoed, Scrum Master bij True: “Ze gingen in de workshop aan de slag met het bouwen van een eigen CI/CD pipeline. In drie stappen zijn de deelnemers van een hele simpele pipeline met 1 job naar een pipeline inclusief deployment naar een server gegaan.”
Bij de laatste stap werden de deelnemers extra gemotiveerd om de deployment voor elkaar te krijgen omdat aan de snelste deelnemers een aardigheidje werd beloofd.
Kennis delen
Op de middag kwam veel positieve feedback terug van de deelnemers. “Het was ontzettende leuk om kennis te delen met de aanwezige developers”, aldus John.
Een aantal van deelnemers heeft vervolgstappen ondernomen bij de implementatie van pipelines. John: “We zien bijvoorbeeld tickets binnenkomen met vragen over hoe ze het beste de gitlab-runners kunnen installeren en hoe ze de gitlab ssh key op productie kunnen zetten.”
True bedankt alle deelnemende bedrijven en wenst ze veel succes bij de verdere ontwikkeling van CI/CD-pipelines. De True Masterclasses zijn exclusief voor klanten die onderdeel zijn van het partnerprogramma. Meer informatie over het partnerprogramma.
