For nylig stødte jeg på et stadig mindre populært værktøj inden for DevOps-verdenen, nemlig Azure DevOps-pipelines. Jeg mærkede straks, at der manglede klare instruktioner eller artikler om emnet. Jeg ved ikke, hvad det skyldes, men Microsoft har tydeligvis noget arbejde foran sig med at popularisere dette værktøj. I dag vil vi opbygge en pipeline til automatiseret test inden for Azure-cloud.

Så, opgaven:
Vi har en software, der bygges med Azure DevOps, og den samles fra et WIX-projekt. Hvis der er interesse, vil jeg også skrive om dette værktøj. Faktisk er det en mere optimeret metode til automatisering af opbygningen af Windows-installationsprogrammer, som erstatter standard InstallShield. Vores software bygge færdigt og genererer en artifact, en slags setup.exe, der installerer applikationen i Windows-systemet. Det er nødvendigt at installere denne applikation i en virtuel maskine, der ligner produktionsmiljøet, kopiere automatiserede tests, forberedt af testteamet, over dertil, køre dem og indsamle resultaterne, så vi kan vurdere, om branchen er god eller dårlig, før vi fusionerer. Alt sammen som i GitLab, bare gennem en lidt mere kompliceret proces.

Som virtualiseringmiljø, hvor vi vil udføre vores tests, bruger vi selvfølgelig Azure DevTest Labs, en type enhed i Azure-abonnementer, der er skabt netop til at køre forskellige testforestillinger til rimelige priser.

1. Integration på cloud-siden

Først skal vi integrere vores DevTest Labs med Azure DevOps, for hvilket vi har brug for en Service Principal, i bund og grund en servicebruger, der giver pipelines adgang til cloud'en og mulighed for at oprette/slette ressourcer der.

Vi går ind i abonnementsområdet og finder tjenesten Azure Active Directory.

Vi finder App Registrations og klikker på New Registration, hvilket vil oprette vores service principal. Jeg vil ikke gå i dybden med, hvilke indstillinger man skal vælge ved oprettelsen, da det kan variere mellem forskellige abonnementer.

Nu skal vi give vores service director adgangsrettigheder. For dette formål går vi ind i abonnementer, klikker på låseikonet. Vi vælger vores abonnement.

Derefter i Access Control klikker vi på Role Assignment og søger efter kontoen, vi lige har oprettet, ved at søge på navnet. Vi tildeler rollen Contributor, det er tilstrækkeligt.

Herefter vender vi tilbage til vores Service Principal i Azure AD og åbner dens egenskaber. Senere vil vi få brug for alle ID'er, der er der, så vi gemmer dem.

Nu er vores portalindstillinger færdige, og vi går videre til Azure DevOps.

2. Integration med Azure DevOps

Først besøger vi projektindstillingerne og vælger Service Connections. Vi opretter et nyt element af typen Azure Resource Manager.

Nu har vi brug for alle de ID'er, vi har skrevet ned. Klik på brug den fulde version af dialogen for serviceforbindelser. Og indtast alle de data, vi har fået fra Service Principal. Klik på verificer, og hvis alt ser godt ud, gemmer vi forbindelsen. Nu kan vores pipelines bruge den til at oprette forbindelse til skyen.

3. Oprettelse af pipeline

Nu går vi i gang med det mest interessante, nemlig opbygningen af selve pipelinen. Vi åbner menuen Pipelines-Builds

Vi mødes af menuen til oprettelse af en ny build, som som standard vil forsøge at oprette en YAML-fil med passende konfiguration. Vi høfligt takker nej til dette og vælger den klassiske version. Microsoft ønsker forståeligt nok at gøre alt som folk og give mulighed for at maksimalt tilpasse pipelines gennem YAML, men den utilstrækkelige dokumentation og de praktiske problemer med mange moduler fortæller os, at det stadig er for tidligt at bruge denne funktionalitet.

Fra mangfoldigheden af skabeloner har vi brug for en simpel Empty Pipeline. Efter dens oprettelse møder vi et tomt redigeringsvindue, hvor vi fremover vil tilbringe en del tid.

Så, klikker vi på + og lander i en slags modulbutik, hvor vi får brug for følgende komponenter i rækkefølge.

Før vi begynder at konfigurere opgaverne i pipelinen, skal vi oprette og placere flere filer i projektet. Dette vil være ARM Template for vores virtuelle maskine, som vi vil generere i Azure DevTest Labs, et script til at hente IP-adressen på maskinen efter, at den er oprettet, samt, hvis ønskes, scripts til vores tests eller det, vi ønsker at køre på værten.

4. Generering af ARM Template

For at oprette en virtuel maskine skal vi først generere en template til den, en json-fil, som vi vil placere i projektkoden, så pipelinen kan læse den derfra.

Vi går ind i vores lab og finder menuen Formulas (genanvendelige baser), klikker opret ny.

Vi mødes af en lang liste af billeder som base, valg af maskinstørrelse, alt det samme som ved oprettelse af en virtuel maskine. På dette tidspunkt stopper vi ikke op, men går direkte videre til det sidste punkt om maskinens egenskaber, nemlig artefakterne. Du kan bruge enhver konfiguration, der er nødvendig for dit miljø. For eksempel tilføjer jeg maskinen til domæne og jeg tilføjer en servicekonto som administrator, så pipelinen senere kan få adgang til denne maskine med denne bruger. Det hele kan variere, men for at teste koden succesfuldt har vi brug for én artefakt, som vi vil gå i dybden med. For at den nyeste version af den software, vi tester, skal installeres på vores maskine, vil vi bruge artefakten "Download Azure Pipelines Artifact and Run Script". Husk, at jeg i begyndelsen nævnte, at der et sted bygges en version med applikationsinstalleren? Nu er vi nødt til at instruere virtualmaskinen, eller rettere templet, til at hente denne artefakt. Og ikke bare hente den, men også installere den, hvilket kræver, at vi udfylder specielle felter med projektets navn, byggens navn og den hemmelige nøgle. Den hemmelige nøgle, ligesom i alle lignende systemer, genereres i kontoen, i dette tilfælde i Azure DevOps, og gemmes i Secrets i dit laboratorium. Her er der en lille forbehold; vi vil gemme den i Secrets, men templet bliver hverken påvirket af det, da det vil blive kørt af en anden bruger i pipelinen, derfor skal vi manuelt indtaste den hemmelige nøgle i templet igen.

En anden artefakt, som vi absolut skal inkludere, er "Configure WinRM"; vi får brug for den til efterfølgende adgang til maskinen. Der er kun én parameter, hostname. Da vi ikke kender den på forhånd, vil vi bruge variablen %COMPUTERNAME%.

Så vi har tilføjet alle nødvendige artefakter, nu går vi videre til den grund, vi overhovedet er her. Lad os hente den genererede ARM-template under fanen Avanceret i det samme vindue til oprettelse af opskrifter.

Vi kopierer indholdet af siden til filen VMtemplate.json og placerer den i rodmappen af projektet. Vi har ikke brug for skyen længere, så vi vender tilbage til pipelinen.

5. Pipelinekonfiguration

Lad os starte med det vigtigste og mest interessante, oprettelsen af en virtuel maskine. Det var derfor, vi har lavet alle disse integrationer og skabeloner. I sektionen Azure RM Subscription vælger vi vores serviceforbindelse, som vi har konfigureret i punkt 2. Derefter skal der dukke et tilgængeligt laboratoriemiljø op for os. Så vælger vi den json, vi genererede, og definerer nogle obligatoriske variabler. Login og adgangskode til maskinen kan angives direkte eller som variabler, men jeg er ikke helt sikker på, at det virker; hvad end jeg skriver, har jeg ikke kunnet logge ind på maskinen med disse legitimationsoplysninger. Det er vigtigt at give maskinen et navn, så det i det mindste altid er unikt. Til dette bruger jeg en build-miljøvariabel.

Dernæst konfigurerer vi endnu et vigtigt aspekt. Efter maskinen starter, er vi nødt til at vide, hvad dens parametre er, og det er bedre, om det ikke kun er os, men også pipeline'en. Derfor laver vi et script, for eksempel GetLabVMParams.ps1, og placerer det der samme i projektet. Jeg tog teksten til scriptet fra Microsofts hjemmeside, men har justeret det lidt til mit miljø, fordi det hentede PublicIP og FQDN for maskinen. Jeg har ikke nogen af delene, men jeg har en PrivateIP, som ikke er så nem at hente, derfor tilføjede jeg en del.

Param( [string] $labVmId)

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

# Hent navn på lab VM-resourcegruppe
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Hent navn på lab VM
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Hent lab VM offentlig IP-adresse
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

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

# Hent lab VM privat IP-adresse
$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

# Sæt en variabel labVmRgName til at gemme navnet på lab VM-resourcegruppen
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Sæt en variabel labVMIpAddress til at gemme lab VM's IP-adresse
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Sæt en variabel labVMFqdn til at gemme lab VMs FQDN-navn
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Af alt, hvad scriptet læser, har jeg kun brug for variablen labVMIpAddress. Det kan være, du har brug for noget andet, så jeg har ikke slettet noget og blot kommenteret det overflødige ud.

Jeg vil også forklare den sidste linje i scriptet; den giver vores build-maskine adgang til enhver vært via WinRM.

I næste fase kører vi vores fantastiske script. Det vil kræve den samme forbindelse til skyen, en indgangsvariabel med ID'et på maskinen, som vil være kendt fra det foregående trin. Hvordan? Her skal vi nævne noget så fantastisk som Output Variabler. Hver fase kan have en liste af variabler, der sendes videre til de næste trin i pipeline. For vores super script vil en sådan variabel være labVMIpAddress, så glem ikke at angive dette.

Dernæst laver jeg ret enkle ting, som desuden kan variere fra sag til sag. Jeg kører et fjernt script, som opretter en deling, hvor jeg senere vil uploade mine scripts.

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

Fra navnet på opgaverne er det klart, at vi derefter kopierer et sample script til maskinen og udfører det i et separat trin. Til den fjerne maskines adresse vil vores variabel $(labVMIpAddress) være nyttig. Derefter bruger vi opgaven «hent artefakt fra deling» og kopierer resultaterne fra scriptets udførsel til vores build-miljø, hvorefter vi gemmer disse filer i build-artefakten med den samme standardopgave. Når vi ikke længere har brug for maskinen, dræber vi den som det sidste trin. Hovedudfordringen, som det ses af artikelens omfang, er at integrere med skyen og etablere kontakt med den virtuelle maskine, du har oprettet, så kan du have det sjovt, som du ønsker.

Dette er min første artikel, så døm venligst ikke hårdt, bemærkninger er velkomne.

Kilde: habr.com