ProHoster > Bloc > Administració > Ús de variables a les canalitzacions d'Azure DevOps

Ús de variables a les canalitzacions d'Azure DevOps

Continuem la nostra revisió d'una meravellosa eina per al desenvolupament per a Windows i més, Azure DevOps. Aquesta vegada, després d'haver patit molt amb les variables d'entorn, vaig decidir posar tota l'experiència en un sol article.

A partir del fet que tenen una sintaxi diferent per a cada entorn d'execució, acabant amb la manca d'una capacitat estàndard per transferir variables d'una etapa del pipeline a una altra.

Faré una reserva que els exemples principals seran a Release Pipelines, perquè YAML encara no hi ha arribat i necessito la funcionalitat de moltes etapes i molts artefactes. Sembla que això s'ha fet disponible a Pipelines habituals, cosa que pràcticament els iguala en funcionalitat. A Pipelines YAML, hem afegit una petita informació gràfica a la representació del text amb paràmetres que es poden establir. És molt convenient, no cal que revises la documentació de cada mòdul. Però ho descriuré en el proper article, però de moment aquí teniu una imatge de la innovació en si.

Ús de variables a les canalitzacions d'Azure DevOps

Emmagatzematge i ús

Comencem pel fet que tenim variables per defecte al sistema. Comencen, segons el seu origen, amb les paraules Release, System, etc. La llista completa (com resulta que no), està disponible a documentació. Tota l'esquizofrènia amb sintaxi s'il·lustra amb un exemple de la documentació següent. La mateixa variable té tres representacions, segons on l'anomenem.

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)

Si configureu una variable a l'agent en què s'executa la tasca, és $(System.AccessToken). Si voleu utilitzar-lo dins d'un script de Powershell al mateix agent, ja serà $env:SYSTEM_ACCESSTOKEN. Si, Déu no ho vulgui, voleu utilitzar aquesta variable en algun host remot mitjançant la tasca PowerShell a les màquines de destinació, heu de passar-ho a través d'un argument a l'script mitjançant els meus diners. Amb bash és més senzill, simplement podeu passar-lo dins utilitzant l'argument i la sintaxi $SYSTEM_ACCESSTOKEN.

Les mateixes lleis no s'apliquen a les vostres pròpies variables; aquí ja sou responsable de la sintaxi. Les variables es poden establir localment en cada tasca.

Ús de variables a les canalitzacions d'Azure DevOps

O globalment a la botiga de variables i, a continuació, enllaçeu-les des de la botiga. Molt còmodament.

Ús de variables a les canalitzacions d'Azure DevOps

Com a avantatge, si les variables són molt secretes, es poden emmagatzemar al núvol Azure en un emmagatzematge anomenat Azure Vault; podeu enllaçar Vault al projecte a la Biblioteca.

Ús de variables a les canalitzacions d'Azure DevOps

En general, tot està clar amb les variables; a les pipelines encara es poden configurar manualment per a cada llançament; en el llançament no hi ha aquesta funcionalitat. Podeu tornar a veure què esteu transferint a la canalització als registres d'inicialització de l'agent, però tingueu en compte que ja hi són en forma convertida.

Ús de variables a les canalitzacions d'Azure DevOps

Variables dinàmiques

La diversió comença quan volem rebre algun valor en una etapa i passar-la a la següent.

Ús de variables a les canalitzacions d'Azure DevOps

No ens van proporcionar aquesta funcionalitat. Però les nostres mans no estan per avorrir-se i amb l'ajuda de Google es va trobar una solució. Gràcies a Déu, Azure DevOps té una API que ens permet fer una mica més del que es mostra a la interfície.

Per tant, necessitarem una trucada per actualitzar les variables globals, cosa que farem directament des de la canalització. L'adreça està presa de variables d'entorn, les mateixes de les quals no hi ha cap paraula a la documentació, com s'ha esmentat anteriorment. Podeu configurar-los vosaltres mateixos o, a més, codificar-los si tanquen la botiga.

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

Establim el valor buit de la variable que volem transferir, establim Scope - Release

Ús de variables a les canalitzacions d'Azure DevOps

Per exemple, fem un generador de valors aleatoris. Fixeu-vos en la sintaxi de declarar una variable dins d'aquesta etapa; aquesta funcionalitat es va introduir.

Ús de variables a les canalitzacions d'Azure DevOps

En el següent pas, passem la variable a l'script, sí, sí, no és possible directament, ha de ser mitjançant un argument.

Ús de variables a les canalitzacions d'Azure DevOps

Guió sota 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

O

xoc

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

En poques paraules, el nostre script pren la variable myVar com a entrada i utilitza l'API per posar el valor d'aquesta variable a stageVar. En el següent pas, utilitzant la sintaxi de la variable del sistema, podem mirar-ho.

Ús de variables a les canalitzacions d'Azure DevOps

L'exemple és força senzill, però la funcionalitat ens obre bones oportunitats, a més de la meva anterior article, quan puguem crear una màquina virtual en la primera etapa de la prova, realitzar algunes manipulacions addicionals amb ella, i diverses en paral·lel. I l'etapa final és destruir-lo. Ara fem proves automàtiques del producte cada vegada en màquines virtuals noves. Tenint en compte que viuen uns 10 minuts, costa un cèntim.

En el següent article, si cal, parlaré dels pipelines YAML; darrerament hi ha hagut moltes innovacions interessants.

Font: www.habr.com

Afegeix comentari