Continuiamo la nostra esplorazione della straordinaria tool di sviluppo per Windows e non solo, Azure DevOps. Questa volta, dopo diverse difficoltà con le variabili d'ambiente, ho deciso di raccogliere tutta la mia esperienza in un unico articolo.
A partire dal fatto che ogni ambiente di esecuzione ha una sintassi diversa, fino all'assenza di una possibilità standard per trasferire variabili da una fase del pipeline all'altra.
Preciso che i principali esempi saranno sui Release Pipelines, poiché il supporto per YAML non è ancora disponibile lì, e ho bisogno della funzionalità di molteplici fasi e artefatti. Pare che questo sia diventato disponibile nei Pipelines normali, il che ha praticamente livellato le loro funzionalità. Nei Pipelines YAML hanno apportato miglioramenti e aggiunto alla rappresentazione testuale un piccolo suggerimento grafico con i parametri che possono essere impostati. È molto comodo, non è necessario consultare la documentazione per ogni modulo. Ma descriverò tutto ciò in un articolo successivo, intanto ecco un'immagine dell'ultima novità.
Archiviazione e utilizzo
Iniziamo col dire che nel sistema abbiamo delle variabili predefinite. Esse cominciano, a seconda della provenienza, con le parole Release, System, ecc. L'elenco completo (come si è rivelato, no) è disponibile in . Tutta la sintassi relativa alla variabile è illustrata nell'esempio della documentazione qui sotto. La stessa variabile ha tre rappresentazioni, a seconda di dove viene richiamata.
steps:
- bash: echo Questo script potrebbe utilizzare $SYSTEM_ACCESSTOKEN
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
- powershell: Write-Host "Questo è uno script che potrebbe utilizzare $env:SYSTEM_ACCESSTOKEN"
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)Se stai impostando una variabile sull'agente in cui viene eseguito il task, questa è $(System.AccessToken). Se desideri utilizzarla all'interno di uno script PowerShell sullo stesso agente, questa sarà $env:SYSTEM_ACCESSTOKEN. Se, Dio non voglia, desideri utilizzare questa variabile su un host remoto, utilizzando il task PowerShell on target machines, devi passarla come argomento allo script, usando . Con bash è più semplice, puoi semplicemente passarla usando l'argomento e la sintassi $SYSTEM_ACCESSTOKEN.
Le stesse regole non si applicano alle tue variabili, qui sei tu a dover prestare attenzione alla sintassi. Puoi definire variabili localmente in ciascun task.
O globalmente nello storage delle variabili e poi collegarle dallo storage. Molto comodo.
In aggiunta, se le variabili sono estremamente riservate, possono essere memorizzate nel cloud Azure in uno storage chiamato Azure Vault, che può essere collegato al progetto in 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 verificare ciò che stai passando al pipeline nei log di inizializzazione dell'agente, ma tieni presente che lì saranno già in forma trasformata.
Variabili dinamiche
Le cose interessanti iniziano quando vogliamo ottenere un certo valore in un passaggio e trasferirlo al successivo.
Tale funzionalità non è stata introdotta. Ma le nostre mani non sono per nulla inattive e, con l'aiuto di Google, è stata trovata una soluzione. Grazie a Dio, Azure DevOps ha un'API che ci consente di fare un po' di più di quanto sia stato progettato nell'interfaccia.
Quindi, avremo bisogno di una chiamata per aggiornare le variabili globali, che faremo direttamente dal pipeline. L'indirizzo viene recuperato dalle variabili d'ambiente, quelle stesse di cui non si parla affatto nella documentazione, come accennato in precedenza. Puoi definirle autonomamente o, per dire, hardcodificarle se chiudono la baracca.
$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 lo Scope — Release
Per esempio, creiamo un generatore casuale di valori. Attenzione alla sintassi per la dichiarazione della variabile in questa fase, questa funzionalità è stata appena introdotta.
Nella fase successiva, passiamo la variabile allo script, sì, direttamente non si può fare, bisogna farlo tramite un argomento.
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))
#endregionOppure
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_URLIn breve, il nostro script riceve in input la variabile myVar e usando l'API inserisce il valore di questa variabile in stageVar. Nella fase successiva, utilizzando la sintassi delle variabili di sistema, possiamo osservarla.
L'esempio è abbastanza semplice, ma la funzionalità ci offre buone opportunità, sommandosi alla mia esperienza precedente , quando possiamo creare una macchina virtuale nella prima fase di test, eseguire alcune operazioni su di essa e, nel contempo, gestirne più di una. E come fase finale, distruggerla. Attualmente, i test automatici del prodotto vengono eseguiti ogni volta su nuove macchine virtuali. Considerando che durano circa 10 minuti, il costo è irrisorio.
Nell'articolo successivo, se necessario, parlerò dei pipeline YAML, poiché ci sono diverse novità interessanti recentemente.
Fonte: habr.com
