Continuăm revizuirea unui instrument minunat de dezvoltare pentru Windows și mai mult, Azure DevOps. De data aceasta, după ce am suferit cu variabilele de mediu, am decis să pun toată experiența într-un singur articol.
Pornind de la faptul că au sintaxă diferită pentru fiecare mediu de execuție, terminând cu lipsa unei abilități standard de a transfera variabile de la o etapă la alta a conductei.
Voi face o rezervare că exemplele principale vor fi pe Release Pipelines, deoarece YAML nu a ajuns încă acolo și am nevoie de funcționalitatea multor etape și a multor artefacte. Acest lucru, se pare, a devenit disponibil în Pipelines obișnuite, ceea ce practic le egalează ca funcționalitate. În Pipelines YAML, am adăugat un mic tooltip grafic la reprezentarea textului cu parametri care pot fi setabili. Este foarte convenabil; nu trebuie să parcurgeți documentația pentru fiecare modul. Dar voi descrie acest lucru în articolul următor, dar deocamdată iată o imagine a inovației în sine.
Depozitare și utilizare
Să începem cu faptul că avem variabile implicite în sistem. Ele încep, în funcție de originea lor, cu cuvintele Release, System etc. Lista completă (după cum se dovedește, nu), este disponibilă la . Toată schizofrenia cu sintaxă este ilustrată printr-un exemplu din documentația de mai jos. Aceeași variabilă are trei reprezentări, în funcție de unde o numim.
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)Dacă setați o variabilă pe agentul pe care este executată sarcina, aceasta este $(System.AccessToken). Dacă doriți să îl utilizați în interiorul unui script powershell pe același agent, acesta va fi deja $env:SYSTEM_ACCESSTOKEN. Dacă, Doamne ferește, doriți să utilizați această variabilă pe o gazdă la distanță folosind sarcina PowerShell pe mașinile țintă, trebuie să treceți aceasta printr-un argument scriptului folosind . Cu bash este mai simplu, îl puteți trece pur și simplu în interior folosind argumentul și sintaxa $SYSTEM_ACCESSTOKEN.
Aceleași legi nu se aplică propriilor dvs. variabile aici sunteți deja responsabil pentru sintaxă. Variabilele pot fi setate local în fiecare sarcină.
Sau global la magazinul de variabile și apoi leagă-le din magazin. Foarte confortabil.
Ca bonus, dacă variabilele sunt foarte secrete, ele pot fi stocate în cloudul Azure într-un spațiu de stocare numit Azure Vault, pe care îl puteți lega de proiect în Bibliotecă;
În general, totul este clar cu variabilele în conducte, acestea pot fi încă setate manual pentru fiecare lansare, nu există o astfel de funcționalitate. Puteți vedea din nou ceea ce transferați în conductă în jurnalele de inițializare a agentului, dar rețineți că acestea sunt deja acolo în formă convertită.
Variabile dinamice
Distracția începe atunci când vrem să primim ceva valoare într-o etapă și să o trecem în următoarea.
Nu ni s-au oferit astfel de funcționalități. Dar mâinile noastre nu sunt pentru plictiseală și cu ajutorul Google s-a găsit o soluție. Slavă Domnului, Azure DevOps are un API care ne permite să facem puțin mai mult decât ceea ce a fost descris în interfață.
Deci, vom avea nevoie de un apel pentru a actualiza variabilele globale, ceea ce vom face direct din interiorul conductei. Adresa este preluată din variabilele de mediu, aceleași despre care nu există niciun cuvânt în documentație, așa cum am menționat mai devreme. Le puteți seta singur sau, mai mult, le puteți codifica dacă închid magazinul.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Setăm valoarea goală a variabilei pe care dorim să o transferăm, setăm Scope - Release
De exemplu, facem un generator de valori aleatorii. Atenție la sintaxa declarării unei variabile în această etapă a fost introdusă această funcționalitate.
În pasul următor, trecem variabila către script, da, da, nu este posibil direct, trebuie să fie printr-un argument.
Scenariul sub 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))
#endregionsau
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_URLPe scurt, scriptul nostru ia variabila myVar ca intrare și folosește API-ul pentru a pune valoarea acestei variabile în stageVar. În pasul următor, folosind sintaxa variabilelor de sistem, o putem privi.
Exemplul este destul de simplu, dar funcționalitatea ne deschide oportunități bune, pe lângă precedentul meu , când putem crea o mașină virtuală în prima etapă a testării, efectuam câteva manipulări suplimentare cu ea și mai multe în paralel. Iar etapa finală este să o distrugi. Acum rulăm autotestări ale produsului de fiecare dată pe mașini virtuale noi. Avand in vedere ca traiesc cam 10 minute, costa un ban.
În următorul articol, dacă este necesar, voi vorbi despre conductele YAML, au existat destul de multe inovații interesante în ultimul timp.
Sursa: www.habr.com