Welkom bij weer een nieuwe blog over Coqfoss, ons interne project waar we nieuwe dingen te leren door samen te werken. In deze reeks blogs nemen we je mee in de technieken die we gebruiken en delen we inzichten die we opdoen. In deze blog gaan we verder met het neerzetten van onze Walking Skeleton. We gaan de CI pipeline in Gitlab neerzetten.
In de vorige blog hebben we gezien hoe we de opzet van het project hebben gedaan. We hebben licht de structuur aangepast met de splitsing tussen een root en web module en we hebben de juiste Docker build plugin uitgezocht. Als resultaat hebben we nu een manier om makkelijk met een mvn install een Docker image te maken.
In het wild zijn we vaak Jenkins tegen gekomen als oplossing voor CI/CD. Tegenwoordig zijn er veel andere gratis oplossingen om makkelijk een CI pipeline neer te zetten. In dit geval kijken we naar een CI pipeline in Gitlab. Om een CI pipeline neer te zetten in Gitlab hoef je eigenlijk maar een ding te doen: een gitlab-ci.yml aan je project toevoegen. In die .yml geef je aan welke stages jouw build kent en geef je aan wat er in elk van die stages uitgevoerd moet worden. We gaan voor nu alleen een build stage definieren, waarin we een Docker image laten bouwen en die vervolgens in de container registry van Gitlab zetten.
Configureren van de build
We beginnen met het maken van de gitlab-ci.yml in de root van het project. We zetten daar neer op basis van welk image we de pipeline willen definieren. Alle Gitlab builds worden in Docker containers gedaan, waardoor we geen last hebben van builds die elkaar in de weg zitten met testen. Omdat we een Kotlin applicatie op de JVM willen maken, kiezen we voor de maven: 3.6.3-jdk-11 image als basis. Vervolgens geven we voor nu in een stages blok aan, dat we een stage ‘build’ willen definiëren. Daaronder doen we dat dan ook daadwerkelijk. Omdat we met de JIB Maven plugin werken kunnen we met een mvn install de Docker image maken.
Om vervolgens de image naar de container registry van Gitlab te pushen, hoeven we alleen maar het password en username van de registry mee te geven aan onze Maven build. Bij Gitlab hebben ze besloten zo lief te zijn om in de default environment variabelen van de build ook een username en password voor de container registry op te nemen. Daardoor kunnen we zonder verdere configuratie de container naar de registry laten pushen.
Onder de default environment variabelen in de build zitten ook nog andere waardes die voor de Docker image erg handig zijn. Een daarvan is de git commit hash. Met een OCI label kunnen we nu makkelijk aangeven van precies welke commit een container gebouwd is. Dat is erg makkelijk als we ons ooit afvragen wat er nou precies ergens draait. Daarnaast kunnen we de image taggen met een verkorte versie van die hash, als ook de branchnaam. Die tags maken het weer makkelijker om een specifieke versie van de container aan te wijzen als we straks gaan deployen.
Caching
Een andere fijne feature aan Gitlab CI is de support voor caching. In de yml kunnen we met een cache blok aangeven welke paden van de container gecached moeten worden. Door ook de MAVEN_OPTS environment variabele in de yml te setten, zorgen we er voor dat Maven naar een gecachede locatie kijkt voor dependencies. In 5 regels configuratie hebben we zo caching voor elkaar. Nice!
Notificaties in Teams
Het laatste wat overblijft is het maken van een mechanisme waarmee we op de hoogte blijven van onze pipeline. Bij CodeSquad maken we gebruik van de inmiddels velen welbekende Office 365 suite van Microsoft. Onderdeel van die suite is Microsoft Teams, waar wij intern over communiceren. Een integratie tussen Gitlab en Teams is vrij makkelijk gemaakt. Eerst enabelen we in Teams onder Apps een Incoming Webhook. Als we het kanaal, de naam van de webhook en een mogelijke afbeelding hebben geconfigureerd kopieren we de webhook URL. In Gitlab kunnen we onder integration bij settings vervolgens het Microsoft Teams Notification scherm vinden. Daar plakken we de URL weer in het juiste veld, en selecteren we de noticaties die we willen ontvangen. Klaar is kees!
We hebben nu met relatief weinig werk een complete CI pipeline die grotendeels onder versiecontrole valt. We kunnen nog veel meer features aan de pipeline hangen, maar voor nu is het belangerijkste neergezet. De volgende keer gaan we deze pipeline compleet maken met een stukje Continuous Deployment naar de cloud, met opnieuw minimale moeite. Tot dan!
