🥇Utilizzo delle variabili nei pipeline di Azure DevOps

Continuiamo la nostra recensione dello straordinario strumento di sviluppo per Windows e non solo, Azure DevOps. Questa volta, dopo aver tribolato con le variabili di ambiente, ho deciso di raccogliere tutta la mia esperienza in un unico articolo.

Iniziamo col dire che per ciascun ambiente di esecuzione hanno una sintassi diversa, e ciò è accentuato dalla mancanza di una possibilità standard di trasferire variabili da una fase della pipeline all'altra.

Voglio chiarire che i principali esempi saranno su Release Pipelines, poiché YAML non è ancora arrivato lì, e ho bisogno della funzionalità di più fasi e di più artefatti. A quanto pare, questo è diventato disponibile nelle normali Pipelines, il che ha praticamente livellato la loro funzionalità. Nelle Pipelines YAML è stata migliorata e, oltre alla rappresentazione testuale, è stata aggiunta una piccola guida grafica con le opzioni che possono essere impostate. È molto comodo, non è necessario consultare la documentazione per ogni modulo. Ma questo lo descriverò nel prossimo articolo, per ora ecco l'immagine della novità.

Archiviazione e utilizzo

Iniziamo con il fatto che nel sistema abbiamo variabili predefinite. Queste iniziano, a seconda dell'origine, con le parole Release, System, ecc. L'elenco completo (come si è scoperto, non esiste) è disponibile in documentazione. Tutta la schizofrenia con la sintassi è illustrata dall'esempio nella documentazione qui sotto. La stessa variabile ha tre rappresentazioni, a seconda di dove la chiamiamo.

steps:
 - bash: echo Questo script potrebbe usare $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Questo è uno script che potrebbe usare $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Se imposti una variabile sull'agente su cui viene eseguito il task, sarà $(System.AccessToken). Se vuoi usarla all'interno di uno script PowerShell sullo stesso agente, sarà già $env:SYSTEM_ACCESSTOKEN. Se, dio non voglia, vuoi usare questa variabile su un host remoto, utilizzando il task PowerShell su macchine target, dovrai passarla tramite un argomento allo script, utilizzando param. Con bash è più semplice, puoi semplicemente passarla usando l'argomento e la sintassi $SYSTEM_ACCESSTOKEN.

Le stesse leggi non si applicano alle tue variabili personali, qui già sei responsabile per la sintassi. Le variabili possono essere impostate localmente in ciascun task.

O globalmente nel repository delle variabili, e poi collegarle dal repository. È molto comodo.

In aggiunta, se le variabili sono particolarmente riservate, possono essere memorizzate nel cloud di Azure in uno storage chiamato Azure Vault, collegare il Vault al progetto è possibile nella Library.

In generale, le variabili sono chiare, nei pipelines possono anche essere impostate manualmente per ogni esecuzione, mentre in release questa funzionalità non è disponibile. Puoi rivedere ciò che trasferisci nel pipeline nei log di inizializzazione dell'agente, ma considera che lì è già in forma trasformata.

Variabili dinamiche

La parte più interessante inizia quando vogliamo ottenere un certo valore in un passaggio e passarla al seguente.

Tale funzionalità non è stata introdotta. Ma le nostre mani non sono fatte per annoiarsi e con l'aiuto di Google è stata trovata una soluzione. Per fortuna, Azure DevOps ha un'API che ci consente di fare qualcosa in più rispetto a quanto disegnato nell'interfaccia.

Quindi, avremo bisogno di una chiamata per l'aggiornamento delle variabili globali, che eseguiremo direttamente all'interno del pipeline. L'indirizzo viene preso dalle variabili d'ambiente, quelle di cui non c'è traccia nella documentazione, come menzionato in precedenza. Puoi impostarle manualmente o, se necessario, hardcodificarle, nel caso in cui chiudano il tutto.

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

Impostiamo un valore vuoto per la variabile che vogliamo trasferire, impostiamo Scope — Release.

Per esempio, creiamo un generatore di valori casuali. Fai attenzione alla sintassi per dichiarare la variabile all'interno di questo passaggio, questa funzionalità è stata introdotta.

Nel passaggio successivo trasferiamo la variabile allo script, sì, non è possibile direttamente, deve passare tramite un argomento.

Lo script è sotto 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

Oppure

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

In poche parole, il nostro script prende la variabile myVar in ingresso e utilizzando l'API imposta il valore di questa variabile in stageVar. Nel passaggio successivo, utilizzando la sintassi delle variabili di sistema, possiamo visualizzarla.

L'esempio è piuttosto semplice, ma la funzionalità ci offre buone opportunità, insieme al mio precedente. l'articolo, quando possiamo creare una macchina virtuale nella prima fase di test, eseguire alcune operazioni su di essa e, nel frattempo, farlo con più macchine. E come fase finale, distruggerla. Attualmente, eseguiamo test automatici del prodotto ogni volta su nuove macchine virtuali. Considerando che vivono per 10 minuti, il costo è irrisorio.

Nell'articolo successivo, se necessario, parlerò dei pipeline YAML, ci sono molte novità interessanti negli ultimi tempi.

Fonte: habr.com