Mainīgo izmantošana Azure DevOps caurlaides

Turpinām apskatīt izcilo rīku Windows izstrādei un ne tikai, Azure DevOps. Šoreiz, mocoties ar vidi, es nolēmu apkopot visu pieredzi vienā rakstā.

Sākot no tā, ka katrai izpildes videi ir atšķirīga sintakse, beidzot ar standarta iespēju trūkumu pārvietot mainīgus no viena posma pārvietošanas joslā uz otru.

Jāatzīmē, ka galvenie piemēri būs uz Release Pipelines, jo YAML vēl nav īstenojies, bet man ir nepieciešama daudzposmu un daudzu artefaktu funkcionalitāte. Šķiet, ka tas ir kļuvis pieejams parastajos Pipelines, kas praktiski izlīdzināja to funkcionalitāti. Pipelines YAML ir papildināts un pievienots teksta attēlojumam, neliela grafiska norāde ar parametriem, kurus var noteikt. Ļoti ērti, nav jāmeklē dokumentācija katram modulim. Bet to aprakstīšu nākamajā rakstā, bet pagaidām lūk attēls no jaunāko izmaiņu.

Uzglabāšana un izmantošana

Sāksim ar to, ka sistēmā mums ir noklusējuma mainīgie. Tie sākas, atkarībā no izcelsmes, ar vārdiem Release, System, utt. Pilns saraksts (kā izrādījās, nav) ir pieejams dokumentācijā. Visu šo šizofrēniju ar sintaksi attēlo piemērs no dokumentācijas zemāk. Vienai un tai pašai mainīgajai ir trīs attēlojumi, atkarībā no tā, kur mēs to izmantosim.

steps:
 - bash: echo This script could use $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Ja jūs nosakāt mainīgo uz aģenta, kurā izpildās uzdevums, tas ir $(System.AccessToken). Ja vēlaties to izmantot iekšā PowerShell skriptā uz tā paša aģenta, tas būs $env:SYSTEM_ACCESSTOKEN. Ja jūs, Dievs pasarg, vēlaties izmantot šo mainīgo kādā attālinātā hostā, izmantojot uzdevumu PowerShell uz mērķa mašīnām, jums tas jānodod kā skripta arguments, izmantojot param. Ar bash ir vienkāršāk, varat vienkārši to nodot iekšā, izmantojot argumentu un sintaksi $SYSTEM_ACCESSTOKEN.

Tie paši likumi neattiecas uz jūsu pašu mainīgajiem, šeit jau jūs esat atbildīgs par sintaksi. Jūs varat noteikt mainīgos lokāli katrā uzdevumā.

Vai globāli mainīgo krātuvē, un pēc tam tos saistīt no krātuves. Ļoti ērti.

Par bonusu, ja, ja, ja, ja mēs gribam saglabāt mainīgos Azure mākoņī, varam izmantot Azure Vault. Savienot Vault ar projektu var bibliotēkā.

Kopumā ar mainīgajiem viss ir skaidrs, pipelines tos var iestatīt manuāli katram palaišanai, bet release tādas funkcionalitātes nav. Varat pārbaudīt, ko nododat pipeline, vēlreiz paskatoties aģenta inicializācijas žurnālos, bet ņemiet vērā, ka tur tie jau ir pārveidoti.

Dinamiskie mainīgie

Interesantā daļa sākas, kad mēs vēlamies iegūt kādu vērtību vienā posmā un nodot to nākamajā.

Šāda funkcionalitāte mums nav pieejama. Bet mūsu rokas nav domātas, lai slinkotu, un ar Google palīdzību mēs atradām risinājumu. Par laimi, Azure DevOps ir API, kas ļauj mums darīt nedaudz vairāk, nekā ir zīmējis interfeiss.

Tātad, mums būs jāveic globālo mainīgo atjaunināšanas izsaukums tieši no pipeline iekšienes. Adresi ņemam no vidi mainīgiem, par kuriem dokumentācijā nav ne vārda, kā tika minēts iepriekš. Jūs varat tos paši iestatīt vai, nu kas tur, saglabāt kodā, ja uzdevums tiks bloķēts.

$releaseurl = ('{0}{1}\/apis\/release\/releases\/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID))

Uzstādām tukšu mainīgā vērtību, kuru vēlamies nodot, iestatām Scope — Release.

Piemēram, izveidosim kādu nejaušu vērtību ģeneratoru. Ņemiet vērā mainīgā paziņošanas sintaksi šajā posmā, šāda funkcionalitāte ir ieviesta.

Nākamajā posmā mēs nododam mainīgo skriptam, jā, jā, tieši nevar, ir jāizmanto arguments.

Skripts zem spoiler.

PowerShell

#Script requires stageVar variable in release variables set to Release scope

param ( [string] $expVar )
#region variables
$ReleaseVariableName = 'StageVar'
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID)  )
#endregion


#region Get Release Definition
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion

#region Output current Release Pipeline
Write-Output ('Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion


#region Update StageVar with new value
$release.variables.($ReleaseVariableName).value = "$expVar"
#endregion

#region update release pipeline
Write-Output ('Updating Release Definition')
$json = @($release) | ConvertTo-Json -Depth 99
Invoke-RestMethod -Uri $releaseurl -Method Put -Body $json -ContentType "application/json" -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }
#endregion

#region Get updated Release Definition
Write-Output ('Get updated Release Definition')
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion

#region Output Updated Release Pipeline
Write-Output ('Updated Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion

Vai

Bash

INPUT_VAR=$1
RELEASE_VAR=$2

echo Test ID: ${INPUT_VAR}

RELEASE_URL="${SYSTEM_TEAMFOUNDATIONSERVERURI}${SYSTEM_TEAMPROJECTID}\/apis\/release\/releases\/${RELEASE_RELEASEID}?api-version=5.0"

echo release url: $RELEASE_URL

RELEASE_JSON=$(curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" $RELEASE_URL)

OUTPUT=`jq ''.variables.${RELEASE_VAR}.value' = '"${INPUT_VAR}"'' <<< $RELEASE_JSON`

curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" -H "Content-Type: application\/json" -X PUT -d "$OUTPUT" $RELEASE_URL

Divos vārdos, mūsu skripts ņem mainīgo myVar kā ieeju un, izmantojot API, ievieto šīs mainīgās vērtību stageVar. Nākamajā posmā, izmantojot sistēmas mainīgo sintaksi, mēs varam to apskatīt.

Piemērs ir diezgan vienkāršs, taču funkcionalitāte sniedz mums labas iespējas, kopā ar manu iepriekšējo no raksta, kad mēs varam izveidot virtuālo mašīnu pirmajā testēšanas posmā, veikt ar to dažādas manipulācijas un pat vienlaikus vairākas. Un noslēguma posmā to iznīcināt. Šobrīd mūsu produkta automātiskie testi tiek izpildīti katru reizi uz jauniem virtuālajiem serveriem. Ņemot vērā, ka tie eksistē desmit minūtes, tas izmaksā niekus.

Nākamajā rakstā, ja būs nepieciešamība, pastāstīšu par YAML cauruļvadiem, tur ir diezgan daudz interesantu jaunievedumu pēdējā laikā.

Avots: habr.com