Wist je al dat Tosca....met CI pipelines kan werken?

CI/CD: Wat is het, hoe gebruik je het?

De meesten onder ons hebben wel eens van CI/CD gehoord. CI staat voor “Continuous Integration” en CD staat voor “Continuous Deployment” of “Continuous Delivery”. Kort samengevat is “CI”, een geautomatiseerd softwareontwikkelproces, dat alle wijzigingen (changes) samenvoegt, integreert en test, zodra ze zijn vastgelegd. Veel IT-bedrijven gebruiken CI/CD als bouwsteen voor (een) development (team) om productontwikkeling sneller te laten verlopen. Ondanks dat het in “IT” een relatief ingeburgerd begrip is, wordt CI/CD lang niet altijd goed begrepen en bovendien op uiteenlopende manieren geïmplementeerd.

Laten we allereerst teruggaan in de tijd. Naar het jaar 1989 om precies te zijn. Het jaar van de val van de Berlijnse muur, maar ook het jaar waarin de PTT werd geprivatiseerd (nu KPN en PostNL). Verder werd in dat jaar, tijdens een IT-conferentie in Orlando, voor het eerst de term “Continuous Integration” gebruikt. Dit naar aanleiding van een onderzoek over “integration test management”, zie hiervoor de site van IEEE.org. Met eXtreme Programming (XP) kwam CI (onder de term “Continuous Process”) verder duidelijker in beeld als een manier om softwareontwikkeling verder efficiënter in te richten. Een legacy systeem in die tijd zoals TFS (Team Foundation Server) kennen “oudgedienden” onder ons, als één van de eerste moderne SCM (Source Code Management) tools voor het beheren en organiseren van software. Het allesomvattende proces van “Branching” was nog geen gemeengoed in die tijd.

In de praktijk

Vanuit die gedachte start ik met een voorbeeld uit de praktijk. Als ontwikkelaar wil je een kopie maken van de broncode vanuit een interne netwerk “storage” richting je lokale pc. Dit doe je normaal gesproken door gebruik te maken van een zogenaamde “Version Control System” (VCS) repository om een specifieke versie uit te checken. Alle broncode van een project wordt in deze repository bewaard. Om het voor alle collega’s duidelijker te maken, wordt verder de huidige toestand of versie van een project “Master” of “Main” genoemd. Vanuit je “werkkopie” voer je je taken uit, zoals het aanpassen van de code, het refactoren van je functies of het automatiseren van je (unit) tests. Als je klaar bent, voer je een “geautomatiseerde build” uit op je lokale pc: de broncode van je werkkopie wordt gecompileerd en vervolgens wordt een geautomatiseerde (unit) test uitgevoerd. Indien foutloos en ge-(peer-)reviewed, wordt dit ingecheckt (ge-commit) in de “Master”.

Een potentieel probleem dat hierbij kan opduiken is natuurlijk dat collega’s tussentijdse wijzigingen aan de “Master” kunnen aanbrengen. Dan moet de “werkkopie” vervolgens worden ge-update aan de hand van tussentijdse wijzigingen en tenslotte weer worden herbouwd. Als tussentijdse wijzigingen botsen met jou wijzigingen (zogenaamde conflicts), en dan zal dit bij het opnieuw compileren of testen een groot aantal fouten produceren. In dat geval is het je verantwoordelijkheid als ontwikkelaar om dit op te lossen: updates en checks zonnodig herhalen totdat je “werkkopie” goed gesynchroniseerd is met de “Master” (build). Dit is helaas een foutgevoelig en intensief ontwikkelproces! Gelukkig hebben we daarvoor moderne CI-tools...Overigens maakt een “commit” je werk niet af. Er is ook zoiets als een “integratie build”, maar daar ga ik niet dieper op in.

In de derde reeks van “Wist je dat Tosca...” ga ik een specifieke CI-tool onder de loep nemen. Laten we beginnen met een 3-tal populaire tools binnen het “DevOps” wereldje. Stel dat je GitHub gebruikt als “cloud repo”, Azure DevOps als CI-tool en Tosca voor het automatiseren van je tests. Om het verder praktischer te maken, gebruik je je lokale pc als agent voor het runnen van zogenaamde “jobs”. Hoe implementeer je het geheel dan als een CI-pipeline? Dat is een hele goeie vraag!

Azure DevOps voor versiebeheer

Voor degene die nog niet bekend zijn met de termen “cloud repo”, VCS en/of GIT, is het handig om bijvoorbeeld “git” te googlen. Daarnaast is het praktisch om je te laten registreren bij één van de bekende “cloud-based git repo hosting” aanbieders, in ons geval is dit GitHub (zie link/URL onderaan de pagina). Het is een gratis “cloud service”, en je zit niet vast aan verplichtingen. Na het registreren van je gratis account bij GitHub, is je volgende stap registratie bij Azure DevOps (zie link/URL onderaan de pagina). Azure DevOps is volgens Google een (cloud) server voor versiebeheer, geautomatiseerde builds en testen, en bovendien voor releasemanagement. Wij focussen ons op builds en testen. Het registratieproces via “Azure” is heel eenvoudig en al gauw kom je bij je persoonlijke dashboard (zie figuur hieronder).

Figuur 1. Azure DevOps

Voor het kunnen uitvoeren van je “CI jobs” heb je een “CI agent” nodig. Je volgende stap is dus het downloaden en installeren van de agent op je lokale machine, een zip-bestand van ongeveer 150 MB. Dit gaat via “Organization Settings” en “Agent pools”. Maak vervolgens een geschikte directory aan voor deze “Azure agent”, in mijn geval is dit locatie “C:\agent”. Start vervolgens Powershell op en voer de commando uit die in figuur 2 wordt weergegeven. Figuur 3 geeft de eindsituatie weer na de installatie.

Figuur 2. Powershell commando voor de agent

Figuur 3. Inhoud map agent na installatie

Daarna is het de bedoeling om je lokale “Azure agent” te laten communiceren met de Azure DevOps server. Dit doe je door allereerst het batch-bestand “config.cmd” op te starten (zie ook figuur 3). In het interactieve scherm dat daarna wordt weergegeven, wordt o.a. naar je token gevraagd (zie voor meer info link/URL onderaan). Als het configuratieproces succesvol is verlopen, dan verschijnt de agent op het “Default” overzicht van de Agent pools (zie figuur 4).

Figuur 4. Agent toegevoegd in de Agent pools

Vervolgens start je batch-bestand “run.cmd” op, om de agent op te starten (status “online”). Als je inmiddels een GitHub-account hebt en een GitHub-repository hebt aangemaakt (zie link/URL onderaan), dan is het tijd om dit te koppelen aan je Azure DevOps account. Dit gaat weer via de “Project settings”, waarbij je optie “GitHub connections” moet selecteren. Als je alle stappen succesvol hebt doorlopen, dan wordt je GitHub repo zichtbaar in Azure DevOps (zie figuur 5).

Figuur 5. GitHub connections

De volgende stap: Tosca Commander

Tot zover hebben we nog niets met Tosca Commander gedaan. Nu is het dus tijd voor Tosca! In de installatie-map van Tosca bevind zich een map “ToscaCI” (zie figuur 6). Wat doen we daarmee?

Figuur 6. Map “Tosca CI”

In sub-map “Client” zit de ToscaCI client (een executable) dat werkt als een trigger voor het uitvoeren van de Tosca tests zonder dat “user” interactie nodig is. Bovendien kan ToscaCI communiceren met externe CI tools, in ons geval Azure DevOps. Om ToscaCI te kunnen laten praten met je Tosca workspace, dien je “ToscaCIClient.exe.config”, een xml bestand, te openen en de locatie van je Tosca workspace mee te geven (zie figuur 7).

Figuur 7. ToscaCIClient.exe.config

Als het bovenstaande is geconfigureerd, dan dien je in Tosca Commander een 2-tal “Test Configuration Parameters” (TCP) toe te voegen. In de “Execution” map van je workspace voeg je op “ExecutionLists”-niveau en op “ExecutionList”-niveau, respectievelijk TCP “ContinuousIntegrationBuildRootFolder” en TCP “ContinuousIntegration”, zie hiervoor figuur 8.

Figuur 8. Test Configuration Parameters (TCP)

Beide TCP “Values” dienen op “True” te staan. Zodra de parameters zijn ingesteld, sluit je je Tosca workspace af en sluit je Tosca Commander ook af. Wat is de volgende stap? Dat laat nog ik nog even in het midden! Je eerste gedeelte voor het implementeren van een Tosca CI-pipeline is overigens een succes! Mooi toch? Ben je nieuwsgierig naar het vervolg?

De volgende van deze reeks "Wist je dat Tosca..."

In mijn volgende artikel (4^de reeks) zal ik verder gaan over het hoe en wat van de “CI-pipeline in actie”: vanuit een “commit” in GitHub tot het uitvoeren van de testen naar aanleiding van deze commit. Zie voor meer informatie over Tosca CI, Azure DevOps en/of GitHub:

Meer weten over Tosca?

Wil jij iedere dag leren en kunnen sparren met vakgenoten over bijvoorbeeld Tosca of andere testautomationtoolings? Neem gerust contact op, ik vertel je er graag meer over. Of bekijk de vacatures.

Tosca Test vacatures