Wir setzen unsere Überprüfung eines wunderbaren Tools für die Entwicklung für Windows und mehr fort: Azure DevOps. Nachdem ich dieses Mal sehr unter Umgebungsvariablen gelitten hatte, beschloss ich, alle Erfahrungen in einem Artikel zusammenzufassen.
Angefangen bei der Tatsache, dass sie für jede Ausführungsumgebung eine unterschiedliche Syntax haben, bis hin zum Fehlen einer Standardfähigkeit, Variablen von einer Stufe der Pipeline in eine andere zu übertragen.
Ich mache einen Vorbehalt, dass die Hauptbeispiele Release Pipelines sein werden, da YAML noch nicht dort angekommen ist und ich die Funktionalität vieler Stufen und vieler Artefakte benötige. Dies scheint nun auch in regulären Pipelines verfügbar zu sein, was ihnen in der Funktionalität praktisch ebenbürtig ist. In Pipelines YAML haben wir der Textdarstellung einen kleinen grafischen Tooltip mit einstellbaren Parametern hinzugefügt. Das ist sehr praktisch: Sie müssen nicht die Dokumentation für jedes Modul durchgehen. Aber ich werde dies im nächsten Artikel beschreiben, aber hier ist zunächst ein Bild der Innovation selbst.
Lagerung und Verwendung
Beginnen wir mit der Tatsache, dass wir Standardvariablen im System haben. Sie beginnen je nach Herkunft mit den Worten Release, System usw. Die vollständige Liste (wie sich herausstellt, nicht) ist verfügbar unter . Alle Schizophrenie mit Syntax wird anhand eines Beispiels aus der folgenden Dokumentation veranschaulicht. Dieselbe Variable hat drei Darstellungen, je nachdem, wo wir sie nennen.
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)Wenn Sie auf dem Agenten, auf dem die Aufgabe ausgeführt wird, eine Variable festlegen, lautet diese $(System.AccessToken). Wenn Sie es in einem Powershell-Skript auf demselben Agenten verwenden möchten, ist es bereits $env:SYSTEM_ACCESSTOKEN. Wenn Sie, Gott bewahre es, diese Variable auf einem Remote-Host mithilfe der PowerShell-Aufgabe auf Zielcomputern verwenden möchten, müssen Sie dies über ein Argument an das Skript übergeben . Mit Bash ist es einfacher, Sie können es einfach mit dem Argument und der Syntax $SYSTEM_ACCESSTOKEN nach innen übergeben.
Für Ihre eigenen Variablen gelten nicht die gleichen Gesetze, hier sind Sie bereits für die Syntax verantwortlich. Variablen können lokal in jeder Aufgabe gesetzt werden.
Oder global zum Variablenspeicher und verknüpfen Sie sie dann vom Speicher aus. Sehr bequem.
Als Bonus können die Variablen, wenn sie sehr geheim sind, in der Azure-Cloud in einem Speicher namens Azure Vault gespeichert werden; Sie können Vault mit dem Projekt in der Bibliothek verknüpfen.
Im Allgemeinen ist bei Variablen alles klar; in Pipelines können sie immer noch manuell für jeden Start festgelegt werden; im Release gibt es keine solche Funktionalität. Sie können in den Initialisierungsprotokollen des Agenten sehen, was Sie erneut in die Pipeline übertragen. Beachten Sie jedoch, dass diese bereits in konvertierter Form vorhanden sind.
Dynamische Variablen
Der Spaß beginnt, wenn wir in einer Phase einen Wert erhalten und ihn an die nächste weitergeben möchten.
Eine solche Funktionalität wurde uns nicht zur Verfügung gestellt. Aber unsere Hände sind nicht für Langeweile da und mit Hilfe von Google wurde eine Lösung gefunden. Gott sei Dank verfügt Azure DevOps über eine API, mit der wir etwas mehr tun können, als in der Schnittstelle dargestellt wurde.
Wir benötigen also einen Aufruf, um globale Variablen zu aktualisieren, was wir direkt aus der Pipeline heraus tun. Die Adresse wird aus Umgebungsvariablen entnommen, also denselben Variablen, über die in der Dokumentation, wie bereits erwähnt, kein Wort erwähnt wird. Sie können sie selbst festlegen oder, was noch wichtiger ist, fest codieren, wenn der Shop 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 übertragen möchten, setzen Scope - Release
Zum Beispiel erstellen wir einen Zufallswertgenerator. Achten Sie auf die Syntax der Deklaration einer Variablen in dieser Phase; diese Funktionalität wurde eingeführt.
Im nächsten Schritt übergeben wir die Variable an das Skript, ja, ja, das ist nicht direkt möglich, 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 verwendet die Variable myVar als Eingabe und verwendet die API, um den Wert dieser Variablen in stageVar einzugeben. Im nächsten Schritt können wir es uns mithilfe der Systemvariablensyntax ansehen.
Das Beispiel ist recht einfach, aber die Funktionalität eröffnet uns neben meinem bisherigen gute Möglichkeiten , wenn wir in der ersten Testphase eine virtuelle Maschine erstellen, einige weitere Manipulationen damit durchführen können, und zwar mehrere parallel. Und der letzte Schritt besteht darin, es zu zerstören. Jetzt führen wir jedes Mal Autotests des Produkts auf neuen virtuellen Maschinen durch. Wenn man bedenkt, dass sie etwa 10 Minuten leben, kostet das einen Cent.
Im nächsten Artikel werde ich bei Bedarf auf YAML-Pipelines eingehen, dort gab es in letzter Zeit ziemlich viele interessante Neuerungen.
Source: habr.com