Wist je al dat Tosca... met CI pipelines kan werken (II)

GitHub en Tosca

In deel 1 van "Wist je dat Tosca met CI pipelines kan werken " hebben we een GitHub repository gekoppeld met Azure DevOps. Omdat je als ontwikkelaar ook lokaal bouwt, is het handig om je “cloud repo” naar je lokale pc te klonen. Op GitHub heb je een aantal opties om de code lokaal te kopiëren, zie groene knopje “Code” in figuur 1.

Figuur 1. Repo klonen vanuit GitHub

Stel dat we een React-applicatie aan het bouwen zijn. Voor we starten met de code, eerst even uitleggen wat React is. Met andere woorden, wat is React? In 2011 bedacht een software engineer van Facebook een manier om code van grote webapplicaties beter beheersbaar te maken: de React- of ReactJS library werd geboren. Eén van de front-end kaders/principes, de afhankelijkheid met de zogenaamde MVC-architectuur (een “design pattern”), werd hiermee teniet gedaan. Hierdoor konden ontwikkelaars flexibeler en vrijer bouwen. De voordelen liggen verder op het gebied van laagdrempeligheid van front-end ontwikkeling en in het eenvoudige gebruik (usability). Inmiddels is ReactJS wereldwijd een populaire opensource front-end framework geworden, dat actief op GitHub wordt onderhouden (zie link onderaan dit artikel).

Terug naar de code! Als je in GitHub op het groene knopje klikt verschijnen er 6 mogelijkheden tot klonen (figuur 1). In dit artikel wordt optie “HTTPS” gebruikt. Let er allereerst op dat je voor de communicatie met GitHub, Git-software op je pc/laptop geïnstalleerd moet hebben. Git is een Source Control Management tool (SCM), voor lokale versiebeheer dat uitermate geschikt is voor communicatie met “public” en “private” repositories (cloud of intern netwerk). Git bestaat in het algemeen uit een GUI-versie en een command prompt-versie, wij gebruiken de laatste. Zie voor beiden hiervoor link onderaan dit artikel.

Nadat je Git hebt geïnstalleerd, dan ziet de Git command prompt er als volgt uit, zie figuur 2.

Figuur 2. Git (bash) command prompt

In figuur 2 zie je verder dat het een Unix-style command prompt betreft, ook wel “bash” genoemd. Vind je de Windows-style veel beter of gemakkelijker, dan kun je uiteraard ook voor de Windows-style kiezen. Je hoeft overigens geen “bash” op te starten om Git te kunnen gebruiken, ook in de Windows command prompt kun je Git-commando’s uitvoeren, zolang de omgevingsvariabelen maar goed geconfigureerd zijn. Als je naar het bovenstaande plaatje kijkt, dan zie je dat ik een map “dev” heb aangemaakt op de lokale C-schijf. Naar deze map wordt zal de code vanuit GitHub worden gekloond. Wat stappen moet je hiervoor uitvoeren? De eerste stap is het initialiseren van de map waar de code vanuit de repository naar toe gaat. Het initialiseren gebeurt door Git-commando “git init” uit te voeren in de command prompt. Hiermee wordt map “dev” voorbereid voor communicatie en versiebeheer met de GitHub repository.

De volgende stap is het klonen van de code naar je lokale pc. Als we in GitHub op het groene knopje klikken, dan heb je bij TAB “HTTPS” een kopieer-icoontje (figuur 1). Wanneer je hierop klikt, wordt het URL van de repository gekopieerd, die je vervolgens kunt plakken in de Git command prompt, zie figuur 3. Voeg hiervoor Git-commando “git clone” toe, klik daarna op ENTER, en je repository wordt als sub-map “react-app” lokaal aangemaakt.

Figuur 3. Lokaal klonen vanuit GitHub m.b.v. Git

Visual Studio Code

That’s it, voor wat betreft het stukje klonen! Als ontwikkelaar kun je nu lokaal aan de slag met de code. Elke ontwikkelaar gebruikt hiervoor haar/zijn eigen ontwikkelomgeving (IDE), in mijn situatie wordt Visual Studio Code gebruikt. In Visual Studio Code kun je (in map “dev”) een nieuwe (project)map openen op het niveau van sub-map “react-app”, en dan ziet het er als volg uit:

Figuur 4. Visual Studio Code (project)map

Tosca CI

Nu de ontwikkelomgeving globaal is ingericht, gaan we naar Azure DevOps. In Azure DevOps moeten pipelines worden voorbereid voor het uitvoeren van specifieke ontwikkel- en testtaken. Om het allemaal simpel te houden heb ik een CI-pipeline gemaakt voor het runnen van een eenvoudige build-taak, weergegeven in een YAML-bestand (zie figuur 5).

Figuur 5.

Betreffende build CI-pipeline is gekoppeld aan de “react-app” repository, wat betekent dat bij elke wijziging en commit een build wordt getriggered. Betreffende build wordt normaal gesproken, indien goed getest, een nieuwe release. Vanuit deze nieuwe release wordt vervolgens een (software)package geproduceerd. Voor eenvoud laten we het stukje over het release-proces (Continuous Delivery / Deployment) in dit artikel buiten beschouwing. Nu missen we nog de koppeling met Tosca. In deel 1 hebben we de Tosca CI client geconfigureerd. Deze client vormt de “mediator” tussen Tosca Commander en Azure DevOps en vice versa.

Hoe gaan we nu automatische Tosca testen uitvoeren n.a.v. een CI build vanuit Azure DevOps? De “react-app” build pipeline uit figuur 5 gaat de trigger worden voor een test build pipeline, die ik “Tosca CI – Test” zal noemen (zie figuur 6). Voor het voorbereiden van deze pipeline gebruik ik de “Classic” weergave (geen YAML-weergave), zodat direct duidelijk is welke (build-)taken kunnen worden toegevoegd.

Figuur 6. Classic build pipeline “Tosca CI - Test”

Vervolgens voegen we via het plusje “+”, om het eenvoudig te houden, slechts 2 taken toe, te weten “Command Line” en “Publish Test Results...”. Betreffende taken kunnen we een eigen label/naam geven om de taak begrijpelijker te maken.

Figuur 7. “Command Line” Taak

Neem daarna de gegevens over, zoals die in figuur 7 wordt weergegeven. Het gaat hier om de minimale gegevens om Tosca CI via command line uit te voeren. De “Tool”-veld geeft de locatie van de Tosca CI client op je lokale pc weer. In specifieke “project” situaties zal dit meestal een remote “server path” zijn, maar in dit geval houden we het simpel. De resterende velden kunnen gewoon op de default waardes worden gelaten. Voor de 2^de taak moet het volgende minimaal worden ingevuld, zie figuur 8:

Figuur 8. “Publish Test Results” Taak

Overigens is dit een additionele of optionele taak voor de Azure DevOps dashboard, aangezien de testresultaten ook bijgehouden worden in Tosca Commander. Sla pipeline “Tosca CI – Test” vervolgens op.

Nu hebben we 2 CI pipelines, die onafhankelijk van elkaar kunnen draaien, maar nog geen directe relatie / koppeling hebben. Wat we uiteindelijk willen bereiken is dat een “commit” van de ontwikkelaar een trigger vormt voor pipeline “react-app” om een build uit te voeren, en wanneer deze build succesvol is, dit weer een trigger vormt voor pipeline “Tosca CI - Test” voor het uitvoeren van de Tosca testen. Hoe richt je dit verder in? Heel eenvoudig! Bewerk pipeline “Tosca CI - Test” met “Edit” (rechtsboven) en navigeer naar de “Triggers” TAB. In figuur 9 zie je dat bij “Build Completion”, na een “+ Add”-actie, een aantal velden zijn ingevuld, de “Triggering build” en de “Branch filters”.

Figuur 9. “Triggers” TAB

Neem het bovenstaande 1-op-1 over en sla pipeline “Tosca CI - Test” nogmaals op. De “Build completion” optie, is één van de trigger-opties binnen Azure DevOps. Bij “Build completion” wordt de voorgaande CI pipeline, bij een succesvolle build, als trigger gebruikt voor het starten van de huidige pipeline. Nu hebben we de koppeling tussen de 2 CI pipelines gerealiseerd!

Als je in deel 1 alle voorgaande configuratie stappen op de juiste manier hebt uitgevoerd, is het tijd voor een “change” in de code. Laten we als ontwikkelaar een eenvoudige lokale wijziging in het README bestand uitvoeren, dan ziet dit er in Visual Studio Code als volgt uit:

Figuur 10. Wijziging README bestand

In het project zie je links in het scherm een “M” en een blauw icoontje “1” verschijnen, wat betekent dat we nu qua versie(beheer) vooruitlopen met wat er op de GitHub repository staat. Vervolgens ontstaat een belangrijke taak voor de ontwikkelaar om de lokale code gelijk te trekken met de GitHub repository. Hoe doet de ontwikkelaar dat? Eén van de handigheden die een ontwikkelaar bezit, is het kunnen gebruiken van Git-commando’s. In deze situatie wordt “Git-bash” command prompt gebruikt om Git-commando’s uit te voeren voor de communicatie tussen je lokale pc en de remote repository. Als je “Git-bash” opstart, commando “git status” intypt en vervolgens op ENTER klikt, dan zie je het volgende:

Figuur 11. Git status

Op branch “master” wordt de wijziging lokaal bijgehouden (figuur 11). Voer daarna achtereenvolgens (numerieke volgorde) de volgende commando’s uit:

git add .
git commit -m “README wijziging”
git push origin master

Bovenstaande “add” commando (let op het laatste puntje!) plaatst de wijziging in de zogenaamde “stage”, van waaruit een definitieve commit kan worden uitgevoerd. Het laatste commando is de definitieve trigger voor de CI pipelines in Azure DevOps. Als alle build pipelines succesvol zijn doorlopen, dan zal in Tosca Commander in de ExecutionList map, de “build” testresultaten worden weergegeven met de default “datum-tijd” label (zie figuur 12).

Figuur 12. ExecutionList / Build testresultaten

Verder groeien in Tosca?

Nu kun je jezelf rekenen tot een select gezelschap van DevOps-gildes! Gaaf toch? 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. Benieuwd naar mijn volgende artikel (5^de in de reeks)? Voor nu even een zomerstop. In de tussentijd, bekijk gerust de vacatures en wie weet, misschien worden we wel collega's.

Tosca Test vacatures

* Tosca is sinds de introductie van Tosca-versie 15.2 afgelopen juni, is Tosca CI niet meer “de standaard” feature voor CI-integratie tussen Tosca en willekeurige CI-tools. Tosca CI wordt vervangen door de “Tosca Execution Client” en daarbij is er een API beschikbaar, de zogenaamde “Tosca Server Execution API”. Beide nieuwe features werken uitsluitend via “Distributed Execution” via AOS (Automation Object Service). Uiteraard is gaat dit niet van de ene op de andere dag. Gebruik je bijvoorbeeld Tosca versie 15.0 LTS, dan ontvang je support tot 3 jaar na de introductie, in dit specifieke geval tot 13 december 2024. LTS staat overigens voor Long Time Service. Bovendien biedt Tricentis Support of de actieve Tosca community meestal tussenoplossingen of workarounds voor “legacy(-wordende)” features. Meer info over Tosca releases/support, GitHub en Git: