Wir setzen unsere Übersicht über das großartige Tool für die Entwicklung unter Windows und darüber hinaus, Azure DevOps, fort. Diesmal habe ich, nachdem ich mit Umgebungsvariablen zu kämpfen hatte, beschlossen, all meine Erfahrungen in einem Artikel zusammenzufassen.
Beginnend damit, dass für jede Ausführungsumgebung eine andere Syntax erforderlich ist, bis hin zur fehlenden Standardmöglichkeit, Variablen von einem Stadium in ein anderes innerhalb der Pipeline zu übertragen.
Ich möchte erwähnen, dass die Hauptbeispiele auf Release-Pipelines basieren, weil YAML dort noch nicht verfügbar ist und ich die Funktionalität von mehreren Stufen und mehreren Artefakten benötige. Diese Funktionalität scheint in den normalen Pipelines verfügbar geworden zu sein, was sie fast gleichwertig macht. In den Pipelines wurde YAML weiterentwickelt und eine kleine grafische Hilfestellung mit den Parametern, die eingestellt werden können, zum Text darstellen hinzugefügt. Sehr praktisch, man muss nicht für jedes Modul in die Dokumentation schauen. Aber das werde ich im nächsten Artikel beschreiben, und hier ist ein Bild der Neuerung.
Speicherung und Verwendung
Beginnen wir damit, dass es im System Standardvariablen gibt. Sie beginnen, je nach Herkunft, mit den Wörtern Release, System usw. Eine vollständige Liste (wie sich herausstellte, gibt es keine) ist verfügbar in . Die gesamte Komplexität der Syntax wird anhand des Beispiels aus der folgenden Dokumentation veranschaulicht. Dieselbe Variable hat drei Darstellungen, abhängig davon, wo wir sie aufrufen.
steps:
- bash: echo Dieses Skript könnte $SYSTEM_ACCESSTOKEN verwenden
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
- powershell: Write-Host "Dies ist ein Skript, das $env:SYSTEM_ACCESSTOKEN verwenden könnte"
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)Wenn Sie eine Variable auf dem Agenten setzen, auf dem die Aufgabe ausgeführt wird, ist das $(System.AccessToken). Wenn Sie sie innerhalb eines PowerShell-Skripts auf demselben Agenten verwenden möchten, ist es bereits $env:SYSTEM_ACCESSTOKEN. Wenn Sie, Gott bewahre, diese Variable auf einem entfernten Host verwenden möchten, indem Sie die Aufgabe PowerShell auf Zielmaschinen nutzen, müssen Sie sie über ein Argument an das Skript übergeben, indem Sie . Mit Bash ist es einfacher, man kann sie einfach über ein Argument unter Verwendung der Syntax $SYSTEM_ACCESSTOKEN durchreichen.
Die gleichen Regeln gelten nicht für Ihre eigenen Variablen, hier sind Sie selbst für die Syntax verantwortlich. Variablen können lokal in jeder Aufgabe festgelegt werden.
Oder global im Variablenspeicher, und dann können Sie sie aus dem Speicher verlinken. Sehr praktisch.
Als Bonus können Sie, wenn die Variablen besonders sensibel sind, diese im Azure Cloud-Speicher, bekannt als Azure Vault, speichern. Der Vault kann mit dem Projekt in der Library verknüpft werden.
Im Allgemeinen ist mit Variablen alles klar. In Pipelines können Sie diese manuell für jeden Durchlauf festlegen, in Releases gibt es diese Funktion jedoch nicht. Sie können sich in den Protokollen der Agenteninitialisierung noch einmal ansehen, was Sie an die Pipeline übergeben, aber beachten Sie, dass sie dort bereits in umgewandelter Form vorliegen.
Dynamische Variablen
Das Interessante beginnt, wenn wir bestimmte Werte in einem Schritt erhalten und diese an den nächsten weitergeben wollen.
Eine solche Funktionalität wurde uns nicht bereitgestellt. Aber unsere Hände sind nicht für die Untätigkeit gemacht, und mit Hilfe von Google wurde eine Lösung gefunden. Zum Glück bietet Azure DevOps eine API, die es uns ermöglicht, ein wenig mehr zu tun, als im Interface vorgesehen ist.
Dafür benötigen wir einen Aufruf zur Aktualisierung globaler Variablen, den wir direkt aus der Pipeline heraus durchführen werden. Die Adresse stammt aus den Umgebungsvariablen, von denen in der Dokumentation nichts erwähnt wird, wie bereits zuvor erwähnt. Sie können diese selbst definieren oder, was auch immer, hardcoden, falls der Zugriff eingeschränkt wird.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID))Wir setzen einen leeren Wert für die Variable fest, die wir übergeben möchten, und legen den Scope auf — Release.
Zum Beispiel erstellen wir einen Zufallswertgenerator. Beachten Sie die Syntax der Variablen-Deklaration innerhalb dieses Schrittes; diese Funktion wurde hinzugefügt.
Im nächsten Schritt übergeben wir die Variable an das Skript. Ja, direkt geht das nicht, es muss über ein Argument geschehen.
Skript unter 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))
#endregionOder
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_URLKurz gesagt, unser Skript nimmt die Eingangsvariable myVar und platziert ihren Wert in stageVar mithilfe der API. Im nächsten Schritt können wir sie mit der Syntax der Systemvariablen anzeigen.
Das Beispiel ist ziemlich einfach, aber die Funktionalität eröffnet uns gute Möglichkeiten, zusammen mit meinem vorherigen , wenn wir im ersten Testabschnitt eine virtuelle Maschine erstellen, einige Manipulationen damit vornehmen und dabei mehrere parallel betreiben können. Der finale Schritt besteht darin, sie zu löschen. Momentan führen wir bei jedem neuen Testlauf automatische Produktprüfungen auf frischen virtuellen Maschinen durch. Da sie nur etwa 10 Minuten leben, kostet das nur ein kleines bisschen.
Im nächsten Artikel, falls es notwendig sein sollte, werde ich über YAML-Pipelines berichten, da es in letzter Zeit viele interessante Neuerungen gegeben hat.
Quelle: habr.com
