Nyligen stötte jag på ett ännu inte så populärt verktyg i DevOps-världen, Azure DevOps-pipelines. Jag kände omedelbart bristen på tydliga instruktioner eller artiklar om detta. Jag vet inte varför, men Microsoft har uppenbarligen något att arbeta med när det kommer till att popularisera verktyget. Idag kommer vi att bygga en pipeline för automatiserad testning inom Azure-molnet.

Så, uppgiften är:
Det finns en mjukvara som byggs med hjälp av Azure DevOps, som samlas från ett WIX-projekt. Om det finns intresse kan jag också skriva om detta verktyg. Faktum är att det är ett mer optimerat sätt att automatisera byggandet av Windows-installationsprogram, som ersätter den traditionella InstallShield. Så, vår mjukvara byggs framgångsrikt och genererar en artefakt, ett setup.exe, som installerar applikationen i Windows-systemet. Det är nödvändigt att installera denna applikation på en virtuell maskin liknande den produktionsmiljö vi har, kopiera dit automatiserade tester som förberetts av testteamet, köra dem och samla in resultaten för att avgöra om grenen är bra eller dålig innan vi slår ihop den. Allt som i GitLab, men lite mer komplicerat.

Som virtualiseringsmiljö där vi ska köra våra tester använder vi uppenbarligen Azure DevTest Labs, en slags enhet inom Azure-prenumerationerna, som är skapad för att köra olika testrelaterade aktiviteter till rimliga kostnader.

1. Integration på cloud-sidan

Först behöver vi integrera vårt DevTest Labs med Azure DevOps, vilket kräver en viss Service Principal, i huvudsak ett tjänstekonto som gör det möjligt för våra pipelines att interagera med molnet och skapa/ta bort resurser där.

Gå till prenumerationen och hitta tjänsten Azure Active Directory

Hitta App Registrations och klicka på New Registration, så skapar vi vår service principal. Jag går inte in på detaljer om vilka inställningar som ska väljas vid skapandet, det kan variera mellan olika prenumerationer.

Nu måste vi ge rättigheter till vår service principal. Gå till prenumerationerna, klicka på nyckelsymbolen. Välj vår prenumeration.

I Access Control klickar vi på Role Assignment och söker efter det nyss skapade kontot. Ge rollen Contributor, det räcker.

Gå tillbaka till vår Service Principal i Azure AD och öppna dess egenskaper. Senare kommer vi att behöva alla ID:n som finns där, så vi sparar dem.

Här avslutar vi våra portalinställningar och går vidare till Azure DevOps.

2. Integration på Azure DevOps-sidan

Först går vi in i projektinställningarna och väljer Service Connections. Vi skapar ett nytt element av typen Azure Resource Manager.

Nu behöver vi alla ID:n som vi har skrivit ner. Klicka på 'use the full version of the service connection dialog'. Och ange all information som vi fått från Service Principal. Tryck på verify och om allt ser bra ut, spara uppkopplingen. Nu kan våra pipelines använda det för att ansluta till molnet.

3. Skapa pipeline

Nu går vi till det mest intressanta, nämligen att bygga själva pipelinen. Öppna menyn Pipelines-Builds.

Vi möts av menyn för att skapa en ny build, som som standard kommer att försöka skapa en YAML-fil med lämplig konfiguration. Vi avböjer artigt detta och väljer det klassiska alternativet. Det är förståeligt att Microsoft vill göra allt som vanligt och ge möjlighet att maximera anpassningen av pipelines via YAML, men den skrala dokumentationen och helt enkelt den praktiska oåterkalleligheten hos många moduler säger oss att det är för tidigt att använda denna funktionalitet.

Av alla mallar behöver vi en enkel Empty Pipeline. Efter att den har skapats möts vi av ett tomt redigeringsfönster, där vi kommer att spendera ganska mycket tid.

Så, tryck på + och komma till en slags modulbutik, där vi behöver följande komponenter enligt listan.

Innan vi börjar konfigurera pipeline-tasks behöver vi skapa och lägga in några filer i projektet. Detta kommer att vara ARM Template för vår virtuella maskin, som vi kommer att generera i Azure DevTest Labs, ett skript för att hämta IP-adress för maskinen efter att den har skapats, samt, om så önskas, skripten för våra tester eller det som vi vill köra på värden.

4. Generera ARM Template

För att skapa en virtuell maskin behöver vi först generera en template, en JSON-fil, som vi kommer att lägga i projektets kod så att pipelinen kan läsa den därifrån.

Gå till vårt labb och hitta menyn Formulas (återanvändbara baser), klicka för att skapa en ny.

Vi möts av en lång lista av bilder som bas, val av maskinstorlek, allt samma som när man skapar en virtuell maskin. Vi kommer inte att stanna vid detta steg, utan gå direkt till den sista punkten i maskinens egenskaper, nämligen artefakterna. Du kan använda valfria konfigurationer som behövs för din miljö. Till exempel, jag lägger till en maskin i domänen och lägger till ett tjänstekonto som administratör, så att pipelinen senare kan komma åt denna maskin under det kontot. Detta kan variera, men för att framgångsrikt testa koden behöver vi en artefakt som vi kommer att fokusera mer på. För att vår maskin ska få den senaste versionen av programvaran som vi testar kommer vi att använda artefakten "Download Azure Pipelines Artifact and Run Script". Kommer ni ihåg att jag i början sa att en byggnad med installationsprogrammet sammanställs någonstans? Nu behöver vi säga till den virtuella maskinen, mer specifikt till mallen, att den ska gå och hämta denna artefakt. Och inte bara hämta den, utan också installera den, för vilket vi fyller i speciella fält med angivande av projektet, byggnamnet och den hemliga nyckeln. Den hemliga nyckeln, precis som i alla system av detta slag, genereras i kontot, i det här fallet i Azure DevOps och sparas i Secrets i ditt labb. Här finns en liten förbehåll, i Secrets kommer vi att spara den, men det hjälper inte mallen, den kommer att köras av en annan användare inom ramen för pipelinen, därför måste vi manuellt ange den hemliga nyckeln i mallen en gång till.

En annan artefakt som måste inkluderas är "Configure WinRM", vi kommer att behöva den för efterföljande åtkomst till maskinen. Det finns bara en parameter, hostname. Eftersom vi inte vet den i förväg kommer vi att använda variabeln %COMPUTERNAME%.

Så vi har lagt till alla nödvändiga artefakter, nu går vi vidare till varför vi faktiskt är här. Vi tar fram den genererade ARM-mallen under fliken Avancerat i samma fönster för att skapa formeln.

Vi kopierar innehållet på sidan till filen VMtemplate.json och placerar den i rotkatalogen för projektet. Vi behöver inte mer från molnet, utan återvänder till pipelinen.

5. Konfiguration av pipelinen

Låt oss börja med det viktigaste och mest intressanta, att skapa en virtuell maskin. Det är därför vi har gjort alla dessa integrationer och mallar. I avsnittet Azure RM Subscription väljer vi vår serviceanslutning som vi konfigurerade i avsnitt 2. Därefter bör vår tillgängliga laboratoriemiljö visas. Sedan väljer vi json som vi genererade och definierar några obligatoriska variabler. Inloggning och lösenord för maskinen kan anges direkt eller som variabler, men jag är inte säker på att det fungerar. Oavsett vad jag skriver lyckades jag inte logga in på maskinen med dessa referenser, så det är viktigt att ge maskinen ett namn som förhoppningsvis alltid är unikt. För detta använder jag en byggmiljövariabel.

Därefter konfigurerar vi en annan viktig punkt. När maskinen startar behöver vi veta dess parametrar, eller snarare, det är pipeline som behöver detta. För detta skapar vi ett skript, till exempel GetLabVMParams.ps1, och placerar det i projektet. Texten i skriptet tog jag från Microsofts webbplats men justerade det något för min miljö, eftersom det hämtade PublicIP och FQDN för maskinen. Jag har varken det ena eller det andra, men jag har PrivateIP som är ganska svårt att få tag på, så jag lade till en bit.

Param( [string] $labVmId)

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

# Hämta labor VM-resursgruppens namn
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Hämta labor VM-namnet
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Hämta labor VM:s offentliga IP-adress
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Hämta labor VM:s FQDN
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Hämta labor VM:s privata IP-adress
$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ätt en variabel labVmRgName för att lagra labor VM-resursgruppens namn
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Sätt en variabel labVMIpAddress för att lagra labor VM:s IP-adress
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Sätt en variabel labVMFqdn för att lagra labor VM:s FQDN-namn
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Av allt som skriptet läser behöver vi bara variabeln labVMIpAddress. Detta är vad jag behöver, kanske ni behöver något mer, så jag har inte raderat något utan bara kommenterat ut det överflödiga.

Jag förklarar också den sista raden i skriptet; den tillåter vår byggmaskin att få åtkomst till vilken värd som helst via WinRM.

I nästa steg kör vi vårt fantastiska skript. Det behöver samma anslutning till molnet, en inparameter med maskinens ID, som då redan kommer att vara känt från föregående steg. Hur? Här behöver vi nämna en fantastisk sak som kallas Output Variabler. Varje steg kan ha en lista med variabler som skickas vidare till de efterföljande stegen i pipelinen. Så för vårt super skript kommer variabeln att vara labVMIpAddress, glöm inte att ange detta.

Vidare gör jag ganska enkla saker som dessutom kan variera från fall till fall. Jag kör ett fjärrskript som skapar en delad mapp där jag sedan ska ladda upp mina skript.

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

Av namnen på uppgifterna framgår att vi nästa kopierar ett exempel skript till maskinen och kör det i ett senare steg. Adressen till den fjärranslutna maskinen kommer att vara vår variabel $(labVMIpAddress). Sedan använder vi uppgiften "hämta artefakt från dell" och kopierar resultaten av skriptets körning till vår byggmiljö, därefter sparar vi dessa filer i byggartefakten med en standarduppgift. När vi inte längre behöver maskinen, dödar vi den som sista steg. Den största svårigheten, som framgår av artikelns omfattning, är att integrera med molnet och upprätta kontakt med den virtuella maskin du har skapat, sedan kan du underhålla dig hur mycket du vill.

Det här är min första artikel, så döm mig inte för hårt, kommentarer välkomnas.

Källa: habr.com