Jätkame Windowsi ja muude jaoks mõeldud arendustööriista – Azure DevOpsi – ülevaatamist. Seekord, olles keskkonnamuutujatega palju kannatanud, otsustasin koondada kogu kogemuse ühte artiklisse.
Alustades sellest, et neil on iga täitmiskeskkonna jaoks erinev süntaks, lõpetades standardse võimaluse puudumisega muutujate ülekandmiseks konveieri ühest etapist teise.
Teen reservatsiooni, et peamised näited on väljalasketorustikel, kuna YAML pole sinna veel jõudnud ja mul on vaja paljude etappide ja paljude artefaktide funktsionaalsust. Tundub, et see on muutunud kättesaadavaks tavalistes torujuhtmetes, mis on nende funktsionaalsuselt praktiliselt võrdne. Pipelines YAML-is lisasime tekstiesitusse väikese graafilise tööriistaspikri koos seadistatavate parameetritega. See on väga mugav; te ei pea iga mooduli dokumentatsiooni läbi vaatama. Kuid ma kirjeldan seda järgmises artiklis, kuid praegu on siin pilt uuendusest endast.
Säilitamine ja kasutamine
Alustame sellest, et meil on süsteemis vaikimisi muutujad. Need algavad olenevalt päritolust sõnadega Release, System jne. Täielik nimekiri (nagu selgub, mitte) on saadaval aadressil . Kõiki süntaksiga skisofreeniat illustreerib näide allolevast dokumentatsioonist. Samal muutujal on kolm esitust, olenevalt sellest, kus me seda nimetame.
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)Kui määrate agendile, millel ülesanne täidetakse, muutuja, on see $(System.AccessToken). Kui soovite seda kasutada sama agendi powershelli skriptis, on see juba $env:SYSTEM_ACCESSTOKEN. Kui sa, jumal hoidku, tahad kasutada seda muutujat mõnes kaughostis, kasutades PowerShelli sihtmasinatel ülesannet, pead sa selle argumendi kaudu edastama skriptile, kasutades . Bashiga on see lihtsam, saate selle lihtsalt sisestada, kasutades argumenti ja süntaksit $SYSTEM_ACCESSTOKEN.
Samad seadused ei kehti teie enda muutujate kohta, siin vastutate juba süntaksi eest. Muutujaid saab igas ülesandes lokaalselt määrata.
Või globaalselt muutujate poodi ja seejärel linkida need poest. Väga mugav.
Kui muutujad on väga salajased, saab need boonusena salvestada Azure'i pilve salvestusruumis nimega Azure Vault; saate linkida Vaulti projektiga teegis.
Üldiselt on muutujatega kõik selge, torustikes saab neid ikkagi iga käivitamise jaoks käsitsi seadistada, väljalaskes sellist funktsiooni pole. Saate näha, mida te konveierile edastate uuesti agendi lähtestamise logides, kuid pidage meeles, et need on seal juba teisendatud kujul.
Dünaamilised muutujad
Lõbu algab siis, kui tahame ühes etapis mingit väärtust saada ja seda järgmisele edasi anda.
Meile sellist funktsiooni ei pakutud. Aga meie käed pole igavuse jaoks ja Google’i abiga leiti lahendus. Jumal tänatud, Azure DevOpsil on API, mis võimaldab meil teha natuke rohkem, kui liidesel kujutati.
Seega vajame globaalsete muutujate värskendamiseks kõnet, mida teeme otse konveieri kaudu. Aadress on võetud keskkonnamuutujatest, samadest, millest dokumentatsioonis pole sõnagi, nagu varem mainitud. Saate need ise seadistada või poe sulgemisel need kõvasti kodeerida.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Määrame muutuja tühja väärtuse, mida tahame üle kanda, määrame ulatuse - vabastamise
Näiteks teeme mingi juhuslike väärtuste generaatori. Pöörake selles etapis tähelepanu muutuja deklareerimise süntaksile; see funktsioon võeti kasutusele.
Järgmises etapis edastame muutuja skriptile, jah, jah, see pole otse võimalik, see peab toimuma argumendi kaudu.
Skript spoileri all
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))
#endregionVõi
sisse lööma
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_URLLühidalt öeldes võtab meie skript sisendiks muutuja myVar ja kasutab API-d, et lisada selle muutuja väärtus etappi Var. Järgmises etapis, kasutades süsteemimuutuja süntaksit, saame seda vaadata.
Näide on üsna lihtne, kuid funktsionaalsus avab meile lisaks minu eelnevale häid võimalusi , kui saame testimise esimeses etapis luua virtuaalse masina, teha sellega täiendavaid manipuleerimisi ja mitut paralleelselt. Ja viimane etapp on selle hävitamine. Nüüd käivitame värsketes virtuaalmasinates iga kord toote automaatteste. Arvestades, et nad elavad umbes 10 minutit, maksab see kopika.
Järgmises artiklis räägin vajadusel YAML torustikest, seal on viimasel ajal päris palju huvitavaid uuendusi olnud.
Allikas: www.habr.com