Introductie tot Continuous Integration

Softwareontwikkeling en IT-operations (DevOps) zijn cruciale praktijken voor een effectieve software development life cycle (SDLC) en voor producten van hoge kwaliteit. Continuous Integration (CI) is een praktijk binnen de softwareontwikkeling waarmee een team zijn wijzigingen continu kan integreren, zelfs meerdere keren per dag. Idealiter wordt elke integratie automatisch gebouwd en getest om integratieproblemen te detecteren en te voorkomen. Deze strategie verkleint de kans dat je meerdere en omvangrijke code-conflicten tegelijk moet oplossen. In dit artikel beschrijf ik hoe je Continuous Integration kunt inschakelen met behulp van een Jenkins-server.

De snelle groei van techbedrijven en de toenemende omvang en complexiteit van softwareoplossingen hebben bijgedragen aan de behoefte aan CI en CD binnen softwareontwikkelteams. Zonder CI gebeurt de integratie handmatig, vaak met meerdere procedures die in workflows zijn gedefinieerd, waardoor Integration Engineers het grootste deel van hun werktijd met deze taken bezig zijn. Dit leidt tot een lagere efficiëntie van engineers, omdat het een doorlopend proces is en onvergelijkbaar veel langer duurt dan het ontwikkelen en onderhouden van geautomatiseerde CI.

De voorgestelde strategie is om een automatiseringsserver te gebruiken, met pipelines die de workflowprocedures in de broncode weerspiegelen. Automatiseringsservers zijn een veelgebruikte oplossing vanwege hun flexibiliteit om zich aan meerdere workflows aan te passen, en ze kunnen zowel eigen als externe tools gebruiken, zoals Python-, Bash- en Perl-scripts.

Software Development Life Cycle

Voordelen van Continuous Integration

Door Continuous Integration-praktijken in de SDLC op te nemen, kun je je ontwikkelproces drastisch verbeteren en het aantal bugs en fouten in de uiteindelijke release verminderen. Continuous Integration biedt daarnaast de volgende voordelen:

Verbetert de codekwaliteit door defecten zo vroeg mogelijk in de ontwikkelcyclus op te sporen.
Verhoogt de productiviteit van developers door het testproces te automatiseren en nieuwe functies sneller op te leveren.
Behoudt consistentie tussen builds door inconsistenties vroeg in het proces te identificeren en op te lossen.
Biedt een helder audittraject van de gehele ontwikkelcyclus.

Een CI-server opzetten met Jenkins

De eerste stap is het installeren van Jenkins op de machine waarop je de buildprocessen gaat uitvoeren. Er zijn verschillende gratis en commerciële opties beschikbaar, waaronder Jenkins Community Edition, Jenkins Enterprise en Jenkins X (voorheen bekend als CloudBees Jenkins). Ongeacht welke optie je kiest, kun je de onderstaande basisstappen volgen om je CI-server te installeren en te configureren. Zodra het is geïnstalleerd, pas je de standaardinstellingen aan op je specifieke eisen. Je kunt de standaardgegevens voor je CI-server configureren via de admin-pagina van Jenkins. Raadpleeg voor aanvullende details de officiële documentatie.

Zodra je de initiële installatie hebt voltooid en een pipeline-plug-in hebt geïnstalleerd, kun je je eerste project aanmaken en er testjobs aan toevoegen. Maak een Jenkinsfile aan in je Git-repository, of schrijf een declaratief pipelinescript in de Jenkins-jobconfiguratie van jouw keuze. Vervolgens kun je ook een build-trigger of een cron-job aanmaken en zo inplannen dat deze met regelmatige tussenpozen draait. De build kan dan automatisch worden uitgevoerd telkens wanneer je wijzigingen naar je repository pusht. Je kunt ook zoveel pipelines aanmaken als je wilt en er verschillende projecten aan toewijzen, zodat afzonderlijke teams dezelfde CI-server kunnen gebruiken zonder dat pipelines elkaar overlappen.

Dashboard van de Jenkins-automatiseringsserver

Een pipeline maken in Jenkins

Zodra je Jenkins-server is geïnstalleerd en ingesteld, kun je geautomatiseerde buildprocessen en taken aanmaken en beheren met de Pipeline-functie van Jenkins.

Elke pipeline vereist:

Steps, oftewel afzonderlijke taken, bijvoorbeeld het in de wachtrij plaatsen van een test. Ze maken deel uit van een reeks die bepaalt wat er op dat specifieke moment moet gebeuren. Steps kunnen ook parallel werken.
Een Node, die beschikbare executors op een agent gebruikt. De gebruiker kan bijvoorbeeld een agent zijn, maar de beste praktijk is om een agent op te zetten met rechten om pipeline-steps uit te voeren, omdat de volledige workflowautomatisering geïsoleerd moet zijn. De node creëert een geïsoleerde werkruimte die slechts gedurende de looptijd van een pipeline bestaat, om de prestaties te waarborgen. De node plant ook de steps in die in de pipeline-broncode zijn gedefinieerd door ze aan de buildwachtrij toe te voegen; zodra een agent vrij is om te werken, begint deze met het uitvoeren van de gedefinieerde steps.
Stages, die meerdere steps kunnen bevatten en worden gebruikt om de pipeline-syntax op te bouwen.

Afhankelijk van de workflow en de vereiste acties maakt de pipeline het ook mogelijk om het volgende te implementeren:

Een extra werkruimte die nog een executor in beslag neemt, wat vooral nuttig is wanneer er verwerkingsintensieve taken zijn die parallel kunnen draaien.
Het definiëren van functies die meerdere keren kunnen worden gebruikt om de broncode beter leesbaar te maken, het gebruik van ingebouwde Groovy-functies, bijvoorbeeld om reguliere expressies te matchen, en conditionals zoals “when” en “if/else”. Omdat Java de grondslag vormt van de programmeertaal Groovy, is ook het “try/catch/finally”-blok beschikbaar.
Indien nodig kunnen de standaard omgevingsvariabelen voor specifieke steps worden gewijzigd, wat bijvoorbeeld kan worden gebruikt om de buildtool aan te passen.
Pipelines stellen engineers in staat om buildparameters te implementeren voor variabelen en conditionals die van build tot build kunnen veranderen.

Het is belangrijk te vermelden dat deze oplossingen eerst ontwikkeld moeten worden om geautomatiseerde builds en tests in de pipeline te kunnen gebruiken. Veelgebruikte tools voor buildautomatisering zijn Gradle en Maven, terwijl voorbeelden van tools voor testautomatisering LambdaTest, Katalon Studio en Kobiton zijn. De keuze hangt af van de techstack en de business rules van het project.

Voorbeeld van een workflow die kan worden geautomatiseerd met de Jenkins-automatiseringsserver

Voordelen van CI ten opzichte van het traditionele QA-proces

In tegenstelling tot traditionele QA-processen, die zich richten op het handmatig testen van afzonderlijke functies, richt Continuous Integration zich op het testen van de volledige applicatie telkens wanneer er een wijziging wordt doorgevoerd. Met deze aanpak kunnen developers eventuele bugs die ze ontdekken snel identificeren en oplossen voordat de code naar productie wordt uitgerold. Door het risico op het uitbrengen van defecte applicaties te elimineren, verhoogt Continuous Integration de productiviteit van het team en levert het op tijd software van hoge kwaliteit op.