Nous continuons à examiner le merveilleux outil de développement pour Windows et pas seulement, Azure DevOps. Cette fois, tourmenté par les variables d'environnement, j'ai décidé de mettre toute l'expérience dans un seul article.Partant du fait que pour chaque environnement d'exécution, ils ont une syntaxe différente, se terminant par le manque d'une capacité standard de transférer des variables d'une étape du pipeline à une autre.Je ferai une réservation que les principaux exemples seront sur Release Pipelines, car YAML ne l'a pas encore atteint, et j'ai besoin de la fonctionnalité de nombreuses étapes et de nombreux artefacts. Il semble que cela soit devenu disponible dans les pipelines réguliers, ce qui les a pratiquement nivelés en termes de fonctionnalités. Dans Pipelines, YAML a ajouté et ajouté à la vue texte une petite info-bulle graphique avec des paramètres qui peuvent être définis. Très pratique, pas besoin d'aller dans la documentation de chaque module. Mais je décrirai cela dans le prochain article, mais pour l'instant, voici une image de l'innovation elle-même.
Stockage et utilisation
Pour commencer, nous avons des variables par défaut dans le système. Ils commencent, selon l'origine, par les mots Release, System, etc. Une liste complète (en fait, non) est disponible dans la documentation . Toute schizophrénie avec syntaxe est illustrée par un exemple tiré de la documentation ci-dessous. La même variable a trois représentations, selon l'endroit où nous l'appelons.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 vous définissez une variable sur l'agent qui exécute la tâche, il s'agit de $ (System.AccessToken). Si vous souhaitez l'utiliser dans un script PowerShell sur le même agent, ce sera déjà $ env: SYSTEM_ACCESSTOKEN. Si, à Dieu ne plaise, vous souhaitez utiliser cette variable sur un hôte distant à l'aide de la tâche PowerShell sur les machines cibles, vous devez passer cela par un argument au script en utilisant param . Avec bash plus simple, vous pouvez simplement le lancer en utilisant l'argument et la syntaxe $ SYSTEM_ACCESSTOKEN.Les mêmes lois ne s'appliquent pas à vos propres variables, ici vous êtes déjà responsable de la syntaxe. Vous pouvez définir des variables localement dans chaque tâche.
Ou globalement dans le référentiel de variables, puis reliez-les à partir du référentiel. Très confortablement.
En prime, si les variables sont très secrètes, elles peuvent être stockées dans le cloud Azure dans un stockage appelé Azure Vault, Vault peut être lié au projet dans la bibliothèque.
En général, tout est clair avec les variables, dans les pipelines, vous pouvez toujours les définir manuellement pour chaque lancement, dans la version il n'y a pas une telle fonctionnalité. Vous pouvez à nouveau voir ce que vous transférez dans le pipeline dans les journaux d'initialisation de l'agent, mais notez qu'ils y sont déjà sous la forme convertie.
Variables dynamiques
La partie la plus intéressante commence lorsque nous voulons obtenir de la valeur dans une étape et la passer à la suivante.
Une telle fonctionnalité ne nous a pas été livrée. Mais nos mains ne sont pas pour l'ennui et avec l'aide de Google, une solution a été trouvée. Dieu merci, Azure DevOps possède une API qui nous permet de faire un peu plus que ce que nous avons dessiné dans l'interface.Nous avons donc besoin d'un appel pour mettre à jour les variables globales, ce que nous ferons directement de l'intérieur du pipeline. L'adresse est tirée des variables d'environnement, les mêmes dont il n'y a pas un mot dans la documentation, comme mentionné précédemment. Vous pouvez leur demander vous-même ou, ce qui est là, un code dur s'ils ferment la boutique.$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )
Définissez la valeur vide de la variable que vous souhaitez transmettre, définissez Scope - Release.Par exemple, nous créons un générateur de valeurs aléatoire. Faites attention à la syntaxe de la déclaration de variable à l'intérieur de cette étape, une telle fonctionnalité a été introduite.
Dans l'étape suivante, nous passons la variable au script, oui oui, c'est impossible directement, c'est nécessaire via l'argument.
Le script sous le spoilerPowerhell
param ( [string] $expVar )
$ReleaseVariableName = 'StageVar'
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Output ('Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
$release.variables.($ReleaseVariableName).value = "$expVar"
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" }
Write-Output ('Get updated Release Definition')
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Output ('Updated Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
OuFrapperINPUT_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 un mot, notre script prend la variable d'entrée myVar et l'utilisation de l'API met la valeur de cette variable dans stageVar. Dans l'étape suivante, en utilisant la syntaxe des variables système, nous pouvons l'examiner.
L'exemple est assez simple, mais la fonctionnalité nous offre de bonnes opportunités, au total avec mon dernier article , lorsque nous pouvons créer une machine virtuelle au premier stade des tests, faire d'autres manipulations avec elle, et en même temps plusieurs. Et la dernière étape consiste à le détruire. Maintenant, nous poursuivons chaque fois les auto-tests de produits sur de nouvelles machines virtuelles. Étant donné qu'ils vivent pendant 10 minutes, cela vaut un sou.Dans le prochain article, si nécessaire, je parlerai des pipelines YAML, il y a beaucoup d'innovations intéressantes ces derniers temps.