Onlangs kwam ik een nog niet zo populaire tool tegen in de wereld van DevOps: Azure DevOps-pijplijnen. Ik merkte al snel het gebrek aan duidelijke instructies of artikelen over het onderwerp. Ik weet niet waar dit vandaan komt, maar Microsoft heeft duidelijk werk te verzetten op het gebied van het populariseren van de tool. Vandaag gaan we een pijplijn opzetten voor geautomatiseerd testen in de Azure-cloud.

Dus, de taak:
We hebben software die wordt gebouwd met behulp van Azure DevOps en wordt samengesteld uit een WIX-project. Als er interesse is, kan ik ook over deze tool schrijven. Dit is in feite een meer geoptimaliseerde automatiseringsmethode voor het bouwen van Windows-installateurs, die de standaard InstallShield vervangt. Dus onze software wordt met succes opgebouwd en genereert een artefact, een setup.exe, dat de applicatie op Windows installeert. We moeten deze applicatie op een virtuele machine die op productie lijkt, installeren, de geautomatiseerde tests, voorbereid door het testteam, daarheen kopiëren, ze uitvoeren en de resultaten ophalen om te bepalen of de tak goed of slecht is, voordat we samensmelten. Het is net als in GitLab, alleen via een andere weg...

Als virtualisatieomgeving waar we onze tests zullen uitvoeren, gebruiken we uiteraard Azure DevTest Labs, een soort entiteit binnen Azure-abonnementen, die speciaal is ontworpen om allerlei testgerelateerde taken tegen redelijke kosten uit te voeren.

1. Integratie aan de cloudzijde

Eerst moeten we onze DevTest Labs integreren met Azure DevOps, waarvoor we een Service Principal nodig hebben, in wezen een serviceaccount dat pijplijnen in de cloud toegang geeft om daar middelen voor zichzelf te creëren of te verwijderen.

We gaan naar het abonnement en zoeken de service Azure Active Directory.

We zoeken onder App-registraties en klikken op Nieuwe registratie; dit stelt ons in staat om onze service principal te creëren. Ik zal de instellingen die gekozen moeten worden bij het maken niet in detail bespreken, deze kunnen verschillen per abonnement.

Nu moeten we rechten geven aan onze service principal. We gaan naar abonnementen, het pictogram met het slot. We kiezen ons abonnement.

Vervolgens klikken we in Toegangsbeheer op Roltoewijzing en zoeken we in de zoekfunctie naar het zojuist aangemaakte account. We geven de rol Contributor; dit is voldoende.

Daarna gaan we terug naar onze Service Principal in Azure AD en openen we de eigenschappen. Later zullen we alle ID's die daar zijn, nodig hebben, dus we slaan ze op.

Hier eindigen onze portalinstellingen en gaan we over naar Azure DevOps.

2. Integratie aan de Azure DevOps-kant

Eerst gaan we naar de projectinstellingen en kiezen we Service Connections. We maken een nieuw element van het type Azure Resource Manager.

Nu hebben we alle ID's nodig die we hebben genoteerd. Klik op gebruik de volledige versie van het dialoogvenster voor de serviceverbinding. Vul alle gegevens in die we van de service-principal hebben ontvangen. Klik op verifiëren en als alles goed is, slaan we de verbinding op. Nu kunnen onze pipelines deze gebruiken om verbinding te maken met de cloud.

3. Het aanmaken van een pipeline

Nu beginnen we met het meest interessante, het bouwen van de pipeline. Open het menu Pipelines-Builds.

We worden verwelkomd door het menu voor het aanmaken van een nieuwe build, dat standaard probeert een YAML-bestand met de geschikte configuratie te maken. We wijzen dit vriendelijk af en kiezen de klassieke optie. Het is duidelijk de wens van Microsoft om alles menselijker te maken en gebruikers de mogelijkheid te geven om pipelines maximaal te personaliseren via YAML, maar de schaarse documentatie en gewoon de praktische onwerkbaarheid van veel modules vertellen ons dat het nog te vroeg is om deze functionaliteit te gebruiken.

Uit de verscheidenheid aan sjablonen hebben we een eenvoudige Lege Pipeline nodig. Na het maken ervan worden we begroet door een leeg bewerkingsvenster, waarin we verder best veel tijd zullen doorbrengen.

Laten we dus op + drukken en komen in een soort modulewinkel, waar we volgens onze lijst de volgende componenten nodig hebben.

Voordat we beginnen met de configuratie van de taken in de pipeline, moeten we enkele bestanden maken en in het project plaatsen. Dit zullen de ARM-template van onze virtuele machine zijn, die we in Azure DevTest Labs genereren, een script om het IP-adres van de machine te verkrijgen nadat deze is gemaakt, en, indien gewenst, scripts van onze tests of wat we op de host willen uitvoeren.

4. Generatie van ARM-template

Om een virtuele machine te maken, moeten we eerst een template genereren, een json-bestand dat we in de projectcode plaatsen, zodat de pipeline het daar kan uitlezen.

Ga naar ons lab en zoek het menu Formules (herbruikbare bases), klik op een nieuwe maken.

We worden begroet door een lange lijst met afbeeldingen als basis, de keuze van de machinegrootte, hetzelfde als bij het maken van een virtuele machine. Op dit punt zullen we niet stoppen, maar direct naar het laatste punt van de machine-eigenschappen gaan, namelijk de artefacten. U kunt elke configuratie gebruiken die nodig is voor uw omgeving. Bijvoorbeeld, ik voeg de machine toe aan domein en ik voeg er een service-account als admin aan toe, zodat de pipeline later deze machine kan benaderen onder dit account. Dit kan variëren, maar voor succesvolle code-testing hebben we één artefact nodig, waar we dieper op in zullen gaan. Om ervoor te zorgen dat de laatste versie van de software die we testen op onze machine wordt geïnstalleerd, zullen we het artefact "Download Azure Pipelines Artifact and Run Script" gebruiken. Onthoud dat ik in het begin zei dat er ergens een build met de applicatie-installateur wordt samengesteld? Nu moeten we de virtuele machine, of beter gezegd, de template, vertellen dat hij dit artefact moet ophalen. En niet alleen ophalen, maar ook installeren, waarvoor we speciale velden invullen met het project, de bouwnaam en de geheime sleutel. De geheime sleutel, zoals in alle systemen van dit soort, wordt gegenereerd binnen het account, in dit geval in Azure DevOps en opgeslagen in Secrets in jouw lab. Hier is een kleine kanttekening, we zullen het in Secrets opslaan, maar de template zal hier niets van merken, hij zal al worden uitgevoerd door een andere gebruiker binnen de pipeline, daarom moeten we de geheime sleutel nog een keer handmatig in de template invoeren.

Een ander artefact dat zeker moet worden opgenomen is "Configure WinRM", dit hebben we nodig voor de toekomstige toegang tot de machine. Er is slechts één parameter, hostname. Aangezien we deze van tevoren niet weten, gebruiken we de variabele %COMPUTERNAME%.

Dus we hebben alle benodigde artefacten toegevoegd, laten we overgaan naar het doel waarvoor we hier zijn gekomen. We halen de gegenereerde ARM Template op via het tabblad Advanced van hetzelfde venster waarin we de formule aanmaken.

We kopiëren de inhoud van de pagina naar het bestand VMtemplate.json en plaatsen het in de hoofdmap van het project. We hebben de cloud niet meer nodig, laten we teruggaan naar de pipeline.

5. Configuratie van de pipeline

Laten we beginnen met het belangrijkste en interessantste: het creëren van een virtuele machine. Daarvoor hebben we al deze integraties en sjablonen gemaakt. Bij het Azure RM Subscription selecteren we onze Service connector, die we in stap 2 hebben geconfigureerd. Vervolgens moet de beschikbare laboratoriumomgeving verschijnen. Daarna kiezen we de json die we hebben gegenereerd en definiëren we enkele verplichte variabelen. De inloggegevens van de machine kunnen direct of via variabelen worden opgegeven, maar ik ben er niet zeker van of het werkt; wat ik ook probeer, ik kon niet inloggen op de machine met deze inloggegevens. Het belangrijkste is om een naam voor de machine in te voeren die, indien mogelijk, altijd uniek is. Hiervoor gebruik ik een build-omgeving variabele.

Vervolgens stellen we nog een belangrijk aspect in. Nadat de machine is opgestart, moeten we haar parameters op een of andere manier weten, beter is het voor de pipeline. Hiervoor maken we een script, bijvoorbeeld GetLabVMParams.ps1, en plaatsen het ook in het project. De tekst van het script heb ik van de Microsoft-website gehaald, maar ik heb het een beetje aangepast voor mijn omgeving, aangezien het de PublicIP en FQDN van de machine gebruikte. Geen van beide heb ik, maar ik heb een PrivateIP dat niet zo eenvoudig te verkrijgen is, daarom heb ik een stuk code toegevoegd.

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Verkrijg de naam van de resourcegroep van de lab VM
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Verkrijg de naam van de lab VM
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Verkrijg het openbare IP-adres van de lab VM
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Verkrijg de FQDN van de lab VM
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Verkrijg het privé IP-adres van de lab VM
$VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id
$nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/") + 1)
$labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations 
$labVMIpAddress = $labVMnetwork.PrivateIpAddress

# Stel een variabele labVmRgName in om de naam van de resourcegroep van de lab VM op te slaan
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Stel een variabele labVMIpAddress in om het IP-adres van de lab VM op te slaan
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Stel een variabele labVMFqdn in om de FQDN-naam van de lab VM op te slaan
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Van alles wat het script uitleest, hebben we alleen de variabele labVMIpAddress nodig. Nou, dat is voor mij; misschien hebt u nog iets anders nodig, daarom heb ik niets verwijderd en gewoon de overbodige regels gecommentarieerd.

Ik zal ook de laatste regel van het script uitleggen; deze staat onze buildmachine toe om toegang te krijgen tot elk host via WinRM.

In de volgende stap starten we ons geweldige script. Dit vereist dezelfde verbinding met de cloud, en de invoervariable met het machine-ID, dat tegen die tijd al bekend zal zijn uit de vorige stap. Hoe? Hier moet ik een geweldig iets noemen, genaamd Output Variables. Elke stap kan een lijst met variabelen hebben die verder worden doorgegeven aan de volgende stappen in de pipeline. Voor ons super script zal die variabele labVMIpAddress zijn; vergeet niet dit op te geven.

Vervolgens voer ik een aantal vrij eenvoudige taken uit, die bovendien van geval tot geval kunnen verschillen. Ik voer een extern script uit waarbij ik een share aanmaak, waarin ik later mijn scripts zal uploaden.

New-Item “C:test" –type directory
New-SMBShare –Name “test” –Path “C:test”  –FullAccess everyone

Uit de naam van de taken blijkt al dat we in de volgende stap een sample script naar de machine kopiëren en dat we het in een verdere stap uitvoeren. Voor het adres van de externe machine hebben we onze variabele $(labVMIpAddress). Vervolgens gebruiken we de taak 'haal artefact van share' en kopiëren we de resultaten van de scriptuitvoering naar onze build omgeving. Daarna slaat dezelfde standaardtaak deze bestanden op als artefact van de build. Nadat de machine niet meer nodig is, vernietigen we deze in de laatste stap. De grootste uitdaging, zoals blijkt uit de lengte van het artikel, is om verbinding te maken met de cloud en contact te leggen met de virtuele machine die u heeft gemaakt; daarna kunt u zoveel plezier hebben als u wilt.

Dit is mijn eerste artikel, dus oordeel niet te streng, opmerkingen zijn welkom.

Bron: habr.com