Së fundmi, u ndesha me një krijesë që ende nuk është shumë e njohur në botën e DevOps, pipelinët e Azure DevOps. Menjëherë ndjeva mungesën e ndonjë udhëzimi të qartë ose artikujsh mbi këtë temë, nuk e di se me çfarë lidhet, por Microsoft definitivisht ka punë për të bërë në promovimin e këtij instrumenti. Sot ne do të ndërtojmë një pipeline për testimin e automatizuar brenda облаkut të Azure.

Pra, detyra është:
Kemi një softuer, që ndërtohet me ndihmën e të njëjtit Azure DevOps, duke u mbledhur nga projekti në WIX. Nëse do të ketë interes, do të shkruaj edhe mbi këtë mjet. Në fakt, ky është një mënyrë më e optimizuar për automatizimin e ndërtimit të instaluesve Windows, që zëvendëson standardin InstallShield. Pra, softi ynë ndërtohet me sukses dhe gjeneron një artifact, një setup.exe, i cili instalon aplikacionin në sistemin Windows. Është e nevojshme të instalojmë këtë aplikacion në një virtualizim të ngjashëm me prodhimin, të kopjojmë atje testet e automatizuara, të përgatitura nga ekipi i testimit, t'i lançojmë dhe të marrim rezultatet, për të vlerësuar nëse dega është e mirë apo e keqe, para se ta bashkojmë. Njësoj si në GitLab, vetëm përmes një ...

Si një mjedis virtualizimi, ku do të ekzekutojmë provat tona, përdorim, natyrisht, Azure DevTest Labs, një entitet në abonimet Azure, i cili është krijuar pikërisht për të funksionuar me çdo lloj testi për çmime të arsyeshme.

1. Integrimi në anën e re

Fillimisht, na nevojitet të integrojmë DevTest Labs me Azure DevOps, për të cilën na nevojitet një Service Principal, i cili është në thelb një llogari shërbimi që mundëson që pipeline-t të aksesojnë cloud-in dhe të krijojnë/fshijnë aty burime për veten e tyre.

Shkoi në abonim dhe gjeni shërbimin Azure Active Directory

Gjeni App Registrations dhe klikoni në New Registration, kjo do të krijojë service principal-in tonë. Nuk do të analizoj në detaje cilat parametra të zgjidhen gjatë krijimit, pasi kjo mund të ndryshojë në varësi të abonimeve të ndryshme.

Tani na nevojitet të japim të drejta drejtorit tonë të shërbimit. Për këtë, shkojmë në abonimet, ikona me çelës. Zgjedhim abonimin tonë.

Pastaj në Access Control klikoni Role Assignment dhe kërkoni për këtë llogari me emrin që sapo krijuam. Jepni rolin Contributor, kjo është e mjaftueshme.

Më pas, kthehemi tek Service Principal-i ynë në Azure AD dhe hapim pronat e tij. Më vonë, do na nevojiten të gjitha ID-të që ndodhen aty, i ruajmë ato.

Këtu përfundojnë cilësimet tona të portalit dhe kalojmë në Azure DevOps.

2. Integrimi në anën e Azure DevOps

Së pari, do të hyjmë në cilësimet e projektit dhe do të zgjedhim Shërbimet e Lidhjeve. Krijojmë një element të ri të tipit Azure Resource Manager.

Tani na duhen të gjitha ID-të që kemi regjistruar. Klikojmë në përdorni versionin e plotë të dialogut të lidhjes shërbimit. Dhe futim të gjitha të dhënat që kemi marrë nga Shërbimi i Parë. Shtypim verifiko dhe, nëse është gjithçka në rregull, ruajmë lidhjen. Tani, proceset tona të pipeline mund ta përdorin atë për t'u lidhur me re.

3. Krijimi i pipeline

Tani kalojmë në pjesën më interesante, ndërtimin e pipeline direkt. Hapim menunë Pipelines-Builds

Na pret menuja e krijimit të një ndërtimi të ri, e cila për default do të përpiqet të krijojë një skedar YAML me konfigurim të përshtatshëm. Ne e refuzojmë këtë me marrëveshje dhe zgjedhim opsionin klasik. Është e kuptueshme dëshira e Microsoft për ta bërë gjithçka si për njerëzit dhe për të dhënë mundësinë për ta personalizuar maksimumin e pipeline-ve përmes YAML, por dokumentacioni i dobët dhe thjesht prakticiteti i pafunksionueshmërisë të shumë moduleve na thotë se është ende herët për ta përdorur këtë funksionalitet.

Nga shumëllojshmëria e shablloneve, na nevojitet një Empty Pipeline i thjeshtë. Pas krijimit të tij, na pret një dritare redaktimi bosh, ku do të kalojmë një kohë të konsiderueshme.

Pra, klikoni në + dhe shfaqet një dyqan modulash, ku na nevojiten këta komponente sipas listës.

Përpara se të fillojmë konfigurimin e detyrave të pipeline-it, na nevojitet të formojmë dhe të vendosim disa skedarë në projekt. Këta do të jenë ARM Template-i i makinës sonë virtuale, i cili do të gjenerohet në Azure DevTest Labs, skripti për të nxjerrë IP-në e makinës pasi ajo të krijohet dhe, nëse dëshirojmë, skriptet e testeve tona ose të asaj që duam të ekzekutojmë në host.

4. Gjenerimi i ARM Template-it

Për të krijuar një makinë virtuale, së pari na nevojitet të gjenerojmë një template, një skedar json, të cilin do ta vendosim në kodin e projektit, në mënyrë që pipeline-i ta lexojë nga aty.

Shkoni në laboratorin tonë dhe gjeni menunë Formulas (bazat e riciklueshme), klikoni për të krijuar një të re.

Do të na presë një listë e gjatë e imazheve si bazë, zgjedhja e madhësisë së makinës, e gjithë kjo ashtu siç ndodh kur krijoni një makinë virtuale. Në këtë fazë nuk do të ndalemi, por do të kalojmë menjëherë te pika e fundit të pronave të makinës, në veçanti artefaktet. Ju mund të përdorni çdo konfigurim që është i nevojshëm për mjedisin tuaj. Për shembull, unë po shtoj një makinë në domain dhe e shtoj atë si një llogari shërbimi si administrator, në mënyrë që pipeline më pas të mund të hyjë në këtë makinë me këtë llogari. Të gjitha këto mund të ndryshojnë, por për testimin e suksesshëm të kodit na nevojitet një artefakt, për të cilin do të ndalemi më në detaje. Për të instaluar versionin më të fundit të softuerit që po testojmë në makinën tonë, do të përdorim artefaktin "Download Azure Pipelines Artifact and Run Script". Mos harroni në fillim, përmenda se diku ndërtohet një ndihmës për instalimin e aplikacionit? Tani na nevojitet të themi virtualkës, dhe në veçanti template-it, që të shkojë dhe të marrë këtë artefakt. Dhe jo vetëm ta marrë, por gjithashtu ta instalojë, për çfarë do të plotësojmë fushat speciale duke treguar projektin, emrin e ndihmës dhe çelësin sekret. Çelësi sekret, si në të gjitha sistemet e tilla, gjenerohet në llogari, në këtë rast në Azure DevOps, dhe ruhet në Secrets në laboratorin tuaj. Ka një sqarim të vogël këtu, në Secrets do ta ruajmë, por template-it nuk do t'i bëjë ndonjë ndryshim, do të nisët nga një përdorues tjetër brenda pipeline-it, prandaj na nevojitet ta fusim manualisht çelësin sekret në template përsëri.

Një tjetër artifact që duhet patjetër të përfshihet është «Configure WinRM», do na nevojitet për qasje në makinë më vonë. Ka vetëm një parameter, hostname. Duke qenë se nuk e dimë paraprakisht, do të përdorim variablën %COMPUTERNAME%.

Pra, kemi shtuar të gjitha artifactet e nevojshme, tani kalojmë në atë për të cilën erdhëm këtu. Nxjerrim ARM Template të generuar në skedën Advanced të të njëjtat dritare krijimi formulash.

Kopjojmë përmbajtjen e faqes në skedarin VMtemplate.json dhe e vendosim në rrënjën e projektit. Nuk kemi nevojë për më shumë nga cloud, kthehemi në pipeline.

5. Konfigurimi i pipeline-it

Le të fillojmë me atë më të rëndësishme dhe interesante, krijimin e një virtuale, për këtë e bëmë të gjithë këto integrime dhe template. Në seksionin Azure RM Subscription, ne zgjedhim lidhjen tonë të shërbimit, që e konfigurëm në pikën 2. Më pas, duhet të shfaqet ambienti laboratorik që kemi në dispozicion. Pas kësaj, zgjedhim json-in që e kemi gjeneruar dhe përcaktojmë disa variabla të domosdoshëm. Emri i përdoruesit dhe fjalëkalimi për makinën mund të vendosen direkt ose me variabla, por nuk jam i sigurt se funksionon; çfarëdo që të shkruaj, nuk kam mundur të hyj në makinë më pas me këto kredenciale. E rendësishme është të vendosësh emrin e makinës, që të jetë sa më unik. Për këtë përdor një variabel ambjenti të ndërtimit.

Më pas, ne vendosim një tjetër moment të rëndësishëm. Pasi makina të ngrihet, na nevojitet një mënyrë për të ditur parametrit e saj, dhe më mirë është që jo ne, por pipeline. Për këtë, krijojmë një skript, për shembull GetLabVMParams.ps1 dhe e vendosim atë aty, në projekt. Tekstin e skriptit e kam marrë nga faqja e Microsoft, por e kam modifikuar pak për mjedisin tim, pasi ai merrte PublicIP dhe FQDN të makinës. Asnjëra nga ato nuk ekziston, por kam PrivateIP që nuk është aq e lehtë për t'u marrë, prandaj kam shtuar një copë.

Param( [string] $labVmId)

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

# Merrni emrin e grupit të burimeve të VM-së në laborator
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Merrni emrin e VM-së në laborator
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Merrni adresën publike IP të VM-së në laborator
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Merrni FQDN e VM-së në laborator
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Merrni adresën private IP të VM-së në laborator
$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

# Caktoni një variabël labVmRgName për të ruajtur emrin e grupit të burimeve të VM-së në laborator
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Caktoni një variabël labVMIpAddress për të ruajtur adresën IP të VM-së në laborator
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Caktoni një variabël labVMFqdn për të ruajtur emrin FQDN të VM-së në laborator
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Nga e gjithë ajo që lexon skripti, na nevojitet vetëm variabla labVMIpAddress. Mirë, ndoshta ju duhet diçka tjetër, për këtë arsye nuk kam fshirë asgjë, vetëm kam komentuar të tepërtat.

Po ashtu, do të shpjegoj rreshtin e fundit të skriptit, ai lejon makinës sonë të ndërtimit aksesin në çdo host përmes WinRM.

Hapi tjetër është që ne fillojmë skriptin tonë të mrekullueshëm. Ai do të kërkojë të njëjtin lidhje me re, një variable hyrëse me ID e makinës, e cila do të jetë tashmë e njohur nga hapi i mëparshëm. Si? Këtu duhet të përmendim një gjë kaq të mrekullueshme, siç janë Variablat e Daljes. Çdo hap mund të ketë një listë variablash që kalojnë më tej, në hapat e ardhshëm të pipeline-it. Përkatësisht, për skriptin tonë të mrekullueshëm, një nga këto variabla do të jetë labVMIpAddress, mos e harro këtë.

Më pas unë bëj disa gjëra të thjeshta, që gjithashtu mund të ndryshojnë nga rasti në rast. Ekzekutoj skriptin e largët duke krijuar një ndarje, në të cilën do të ngarkoj skriptet e mia.

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

Nga emri i detyrave, është e qartë se ne do të kopjojmë një skenar të caktuar në makinë dhe në një hap tjetër do ta ekzekutojmë. Si adresë të makinës remote, do të na nevojitet variabla jonë $(labVMIpAddress). Më pas, ne do të përdorim detyrën "merr artefaktin nga ndarja" dhe do të kopjojmë rezultatet e ekzekutimit të skenarit në ambientin tonë të ndërtimit, pastaj me një detyrë standarde do të ruajmë këto skedarë si artefakte të ndërtimit. Pasi që makina nuk na nevojitet më, në fazën përfundimtare, ne e shkatërrojmë atë. Vështirësia kryesore, siç duket nga volumi i artikullit, është të integruar me cloud-in dhe të krijoni kontakt me virtualizimin që keni krijuar, më pas mund të kënaqeni sa të dëshironi.

Kjo është artikulli im i parë, kështu që mos e gjykoni ashpër, sugjerimet janë të mirëpritura.

Burimi: habr.com