Omgevingsvariabelen in Build vNext

​De populariteit van het nieuwe build systeem in Visual Studio Team Services (VSTS) en TFS 2015 neemt de laatste tijd steeds meer toe, en (volgens mij) terecht. Het werkt een stuk beter dan de oude XAML-gebaseerde builds. De afgelopen periode heb ik een aantal XAML-gebaseerde builds geconverteerd naar het nieuwe build systeem. Hierbij ben ik een flink aantal custom build workflows en tasks tegen gekomen. Het grootste deel hiervan kon eenvoudig omgezet worden naar out-of-the-box beschikbare taken, maar voor anderen moesten custom tasks geschreven worden. Wanneer je een custom build task voor het nieuwe build systeem gaat schrijven, heb je op enig moment build-specifieke informatie nodig. Dat is het moment waarop omgevingsvariabelen nodig zijn. Omdat ik nog niet heel bekend was met het concept van omgevingsvariabelen (ik had er van gehoord, maar nooit actief gebruik van gemaakt) besloot ik om hier eens dieper in te duiken.

Wat is een omgevingsvariabele?

Omgevingsvariabelen zijn een concept binnen het besturingssysteem. Ze bestaan uit een set aan key-value paren specifiek voor de omgeving van het huidige proces. Omgevingsvariabelen worden op de meeste besturingssystemen (bijvoorbeeld Windows, Linux & Mac OS X) gebruikt. Dit maakt ze erg geschikt voor gebruik in cross-platform scenario’s, zoals bijvoorbeeld een build agent.

Een aantal voorbeelden van omgevingsvariabelen zijn “PATH” (een lijst van directories waarin gezocht wordt naar het commando dat je uitvoert), “TEMP” (het pad waar tijdelijke bestanden worden opgeslagen) en “WINDIR” (het pad van de Windows installatie directory).

Omgevingsvariabelen in het build proces

In de context van een TFS build zal het huidige proces het proces zijn dat de build definition uitvoert. Dit betekent dat elke omgevingsvariabele die in deze context aangemaakt wordt beschikbaar is voor alle taken in de build definition! Je kunt dus omgevingsvariabelen gebruiken om de uitvoering van specifieke taken te sturen, of om informatie door te geven van de een taak naar eventuele opvolgende taken.

Omgevingsvariabelen kunnen op meerdere manieren gezet worden:
• Door het besturingssysteem van de build server: dit zijn systeemvariabelen zoals “TEMP” en “PATH”,
• Door de build agent: dit zijn variabelen specifiek voor het uitvoeren van een build, zoals de working directory en bijvoorbeeld de naam van de build definition die uitgevoerd wordt,
• Door de build definition: variabelen die je instelt op het “Variables” tabblad in de build definition (in de build definition zelf of wanneer je een build start) worden beschikbaar gemaakt als omgevingsvariabele.


 
Meer informatie over het gebruik van omgevingsvariabelen in je build definition kan je hier vinden: https://msdn.microsoft.com/en-us/library/vs/alm/build/scripts/variables

Omgevingsvariabelen weergeven

De hierboven genoemde MSDN pagina bevat een lijst van voor gedefinieerde variabelen die beschikbaar zijn binnen de build. Hoewel deze pagina aardig wat inzicht verschaft, vond ik het niet voldoende. Ik wilde graag alle beschikbare omgevingsvariabelen weten mét de bijbehorende waarde tijdens de het uitvoeren van de build. Het blijkt dat het weergeven van alle omgevingsvariabelen en de bijbehorende waardes vrij eenvoudig is. In PowerShell kan dit met de volgende code:

Get-ChildItem Env:

En in Node.js is er een object beschikbaar met alle omgevingsvariabelen:

process.env

Deze code kun je gebruiken wanneer je een custom task aan het ontwikkelen bent. Om het debuggen van builds zonder custom tasks te vereenvoudigen heb ik een kleine custom build task gemaakt met deze code. Deze task kan in de build opgenomen worden om op elk moment de waarde van alle omgevingsvariabelen te bekijken. Je kunt de taak zelfs meerdere keren opnemen om te bekijken of (en hoe) de omgevingsvariabelen gedurende de build veranderen.
De output van de taak ziet er ongeveer zo uit:


 
Zoals je kunt zien zijn er veel omgevingsvariabelen gedefinieerd. In mijn geval waren het er 114…

De code voor deze build task is beschikbaar op GitHub en kan vrij gebruikt worden.

[This post is published in English on Real ALM]