Wir setzen die Übersicht über das bemerkenswerte Tool für die Entwicklung unter Windows und darüber hinaus, Azure DevOps, fort. Diesmal, nachdem ich mit Umgebungsvariablen zu kämpfen hatte, habe ich beschlossen, alle Erfahrungen in einen Artikel zu bündeln.
Beginnend damit, dass sie für jede Ausführungsumgebung eine unterschiedliche Syntax haben, bis hin zur fehlenden standardmäßigen Möglichkeit, Variablen von einer Pipeline-Phase zur anderen zu übertragen.
Ich möchte darauf hinweisen, dass die Hauptbeispiele in den Release-Pipelines sein werden, weil YAML dort noch nicht angekommen ist und ich die Funktionalität von mehreren Stufen und mehreren Artefakten benötige. Das scheint jetzt in den regulären Pipelines verfügbar zu sein, was sie in der Funktionalität praktisch auf ein Level gebracht hat. In den Pipelines wurde YAML nachgebessert und es wurde eine kleine grafische Hilfestellung zu den Parametern hinzugefügt, die man festlegen kann, die im textuellen Ausdruck eingebaut sind. Sehr praktisch, man muss nicht für jedes Modul in die Dokumentation schauen. Aber das werde ich im nächsten Artikel beschreiben, hier ist zunächst das Bild der Neuerung.
Speicherung und Nutzung
Beginnen wir mit der Tatsache, dass im System Standardvariablen vorhanden sind. Diese beginnen, je nach Herkunft, mit den Worten Release, System usw. Eine vollständige Liste (wie sich herausstellte, gibt es keine) ist verfügbar unter . Die ganze Schizophrenie der Syntax wird durch das folgende Beispiel aus der Dokumentation veranschaulicht. Für dieselbe Variable gibt es 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 "Das ist ein Skript, das $env:SYSTEM_ACCESSTOKEN verwenden könnte"
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)Wenn Sie eine Variable auf dem Agenten festlegen, auf dem die Aufgabe ausgeführt wird, ist das $(System.AccessToken). Wenn Sie sie in einem PowerShell-Skript auf demselben Agenten verwenden möchten, wird sie $env:SYSTEM_ACCESSTOKEN sein. Wenn Sie, Gott bewahre, diese Variable auf einem bestimmten Remote-Host verwenden möchten, indem Sie die Aufgabe PowerShell on target machines verwenden, müssen Sie dies über ein Argument an das Skript übergeben, unter Verwendung von . Bei bash ist es einfacher, man kann sie einfach übergeben, indem man das Argument und die Syntax $SYSTEM_ACCESSTOKEN verwendet.
Die gleichen Regeln gelten nicht für Ihre eigenen Variablen, hier sind Sie bereits für die Syntax verantwortlich. Variablen können lokal in jeder Aufgabe festgelegt werden.
Oder global im Variablenspeicher, und dann von dort verlinkt werden. Sehr praktisch.
Als Bonus dazu, wenn die Variablen sehr geheim sind, können sie im Azure Cloud-Speicher namens Azure Vault gespeichert werden. Das Vault kann mit dem Projekt in der Bibliothek verlinkt werden.
Insgesamt sind die Variablen klar, in Pipelines können sie auch manuell für jeden Lauf definiert werden, in Releases gibt es diese Funktionalität jedoch nicht. Sie können erneut überprüfen, was Sie an die Pipeline übergeben, in den Logs der Agenteninitialisierung, beachten Sie jedoch, dass sie dort bereits in umgewandelter Form vorliegen.
Dynamische Variablen
Das Interessanteste beginnt, wenn wir einen bestimmten Wert in einem Schritt erhalten und ihn an den nächsten übergeben möchten.
Eine solche Funktionalität haben wir nicht erhalten. Aber unsere Hände sind nicht zum Faulenzen, und mit Hilfe von Google haben wir eine Lösung gefunden. Gott sei Dank bietet Azure DevOps eine API, die uns ermöglicht, etwas mehr zu tun, als die Benutzeroberfläche zeigt.
Wir benötigen einen Aufruf zur Aktualisierung von globalen Variablen, den wir direkt aus der Pipeline machen werden. Die Adresse wird aus Umgebungsvariablen entnommen, von denen in der Dokumentation kein Wort zu finden ist, wie bereits erwähnt. Sie können sie selbst festlegen oder, wenn nötig, hardcodieren, falls die Sache geschlossen wird.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID))Wir setzen den leeren Wert der Variablen, die wir übergeben möchten, und stellen den Scope — Release ein.
Zum Beispiel erstellen wir einen zufälligen Wertgenerator. Beachten Sie die Syntax zur Deklaration der Variable innerhalb dieses Schrittes; solche Funktionalität wurde implementiert.
Im nächsten Schritt übergeben wir die Variable an das Skript, ja, direkt geht es nicht, wir müssen sie als Argument übergeben.
Skript im 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_URLIn wenigen Worten, unser Skript nimmt die Eingabevariable myVar und legt mithilfe der API den Wert dieser Variablen in stageVar fest. Im nächsten Schritt können wir sie mithilfe der Syntax von Systemvariablen anzeigen.
Das Beispiel ist recht einfach, aber die Funktionalität eröffnet uns gute Möglichkeiten, zusammen mit meinen früheren. , wenn wir eine virtuelle Maschine in der ersten Testphase erstellen können, damit einige Manipulationen durchgeführt werden können, und zwar parallel mehrere. Und als letzter Schritt diese zu vernichten. Derzeit werden die automatisierten Tests des Produkts jedes Mal auf frischen virtuellen Maschinen durchgeführt. Angesichts der Tatsache, dass sie etwa 10 Minuten lang leben, kostet das ein kleines bisschen.
Im nächsten Artikel, falls erforderlich, werde ich über YAML-Pipelines sprechen, die in letzter Zeit viele interessante Neuerungen erlebt haben.
Quelle: habr.com
