Continuiamo la nostra recensione di uno splendido strumento per lo sviluppo per Windows e non solo, Azure DevOps. Questa volta, avendo sofferto molto con le variabili d'ambiente, ho deciso di mettere tutta l'esperienza in un unico articolo.
A partire dal fatto che hanno una sintassi diversa per ogni ambiente di esecuzione, per finire con la mancanza di una capacità standard di trasferire le variabili da una fase all'altra della pipeline.
Farò una prenotazione sul fatto che gli esempi principali saranno sulle pipeline di rilascio, perché YAML non è ancora arrivato lì e ho bisogno della funzionalità di molte fasi e molti artefatti. Questo, a quanto pare, è diventato disponibile nelle normali pipeline, che praticamente le eguagliano in termini di funzionalità. In Pipelines YAML abbiamo aggiunto un piccolo tooltip grafico alla rappresentazione testuale con parametri che possono essere impostati. È molto comodo; non è necessario consultare la documentazione per ciascun modulo. Ma lo descriverò nel prossimo articolo, ma per ora ecco un'immagine dell'innovazione stessa.
Conservazione e utilizzo
Cominciamo dal fatto che abbiamo variabili predefinite nel sistema. Cominciano, a seconda della loro origine, con le parole Release, System, ecc. L'elenco completo (a quanto pare, no), è disponibile all'indirizzo . Tutta la schizofrenia con sintassi è illustrata da un esempio tratto dalla documentazione seguente. La stessa variabile ha tre rappresentazioni, a seconda di dove la chiamiamo.
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)Se imposti una variabile sull'agente su cui viene eseguita l'attività, sarà $(System.AccessToken). Se desideri utilizzarlo all'interno di uno script PowerShell sullo stesso agente, sarà già $env:SYSTEM_ACCESSTOKEN. Se tu, Dio non voglia, desideri utilizzare questa variabile su qualche host remoto utilizzando l'attività PowerShell sulle macchine di destinazione, devi passarla attraverso un argomento allo script utilizzando . Con bash è più semplice, puoi semplicemente passarlo all'interno usando l'argomento e la sintassi $SYSTEM_ACCESSTOKEN.
Le stesse leggi non si applicano alle tue variabili; qui sei già responsabile della sintassi. Le variabili possono essere impostate localmente in ciascuna attività.
Oppure globalmente al negozio di variabili e quindi collegarli dal negozio. Molto comodamente.
Come bonus, se le variabili sono molto segrete, possono essere archiviate nel cloud di Azure in un archivio chiamato Azure Vault; è possibile collegare Vault al progetto nella Libreria.
In generale, con le variabili tutto è chiaro; nelle pipeline possono ancora essere impostate manualmente per ogni lancio; nel rilascio non esiste tale funzionalità. Puoi vedere nuovamente cosa stai trasferendo alla pipeline nei log di inizializzazione dell'agente, ma tieni presente che sono già presenti in forma convertita.
Variabili dinamiche
Il divertimento inizia quando vogliamo ricevere del valore in una fase e passarlo a quella successiva.
Non ci è stata fornita tale funzionalità. Ma le nostre mani non si annoiano e con l'aiuto di Google è stata trovata una soluzione. Grazie a Dio, Azure DevOps dispone di un'API che ci consente di fare qualcosa in più rispetto a quanto illustrato nell'interfaccia.
Quindi, avremo bisogno di una chiamata per aggiornare le variabili globali, cosa che faremo direttamente all'interno della pipeline. L'indirizzo è preso dalle variabili d'ambiente, le stesse di cui non c'è una parola nella documentazione, come accennato in precedenza. Puoi impostarli tu stesso o, soprattutto, codificarli se chiudono il negozio.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Impostiamo il valore vuoto della variabile che vogliamo trasferire, impostiamo Scope - Release
Ad esempio, creiamo un generatore di valori casuali. Prestare attenzione alla sintassi di dichiarazione di una variabile all'interno di questa fase; questa funzionalità è stata introdotta.
Nel passaggio successivo passiamo la variabile allo script, sì, sì, non è possibile direttamente, deve avvenire tramite un argomento.
Sceneggiatura 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))
#endregionO
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 poche parole, il nostro script prende la variabile myVar come input e utilizza l'API per inserire il valore di questa variabile in stageVar. Nel passaggio successivo, utilizzando la sintassi delle variabili di sistema, possiamo esaminarlo.
L'esempio è abbastanza semplice, ma la funzionalità ci offre buone opportunità, oltre a quelle precedenti , quando possiamo creare una macchina virtuale nella prima fase di test, eseguire con essa alcune ulteriori manipolazioni e diverse in parallelo. E lo stadio finale è distruggerlo. Ora eseguiamo ogni volta test automatici del prodotto su nuove macchine virtuali. Considerando che vivono circa 10 minuti, costa un centesimo.
Nel prossimo articolo, se necessario, parlerò delle pipeline YAML; ultimamente ci sono state molte innovazioni interessanti.
Fonte: habr.com