Wir überprüfen weiterhin das wunderbare Tool für die Entwicklung für Windows und nicht nur Azure DevOps. Dieses Mal, gequält mit Umgebungsvariablen, beschloss ich, alle Erfahrungen in einem Artikel zusammenzufassen.Ausgehend von der Tatsache, dass sie für jede Laufzeitumgebung eine andere Syntax haben, endet dies mit dem Fehlen einer Standardfähigkeit zum Übertragen von Variablen von einer Stufe der Pipeline zu einer anderen.Ich werde reservieren, dass die Hauptbeispiele bei Release Pipelines sein werden, da YAML es noch nicht erreicht hat und ich die Funktionalität vieler Stufen und vieler Artefakte benötige. Dies wurde anscheinend in regulären Pipelines verfügbar, wodurch die Funktionalität praktisch ausgeglichen wurde. In Pipelines fügte YAML der Textansicht einen kleinen grafischen Tooltip mit einstellbaren Parametern hinzu und fügte ihn hinzu. Sehr praktisch, Sie müssen nicht für jedes Modul in die Dokumentation gehen. Aber ich werde dies im nächsten Artikel beschreiben, aber im Moment ist hier ein Bild der Innovation selbst.
Lagerung und Verwendung
Zunächst haben wir Standardvariablen im System. Sie beginnen je nach Herkunft mit den Worten Release, System usw. Eine vollständige Liste (wie sich herausstellte, nein) ist in der Dokumentation verfügbar . Jede 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 für den Agenten, der die Aufgabe ausführt, eine Variable festlegen, ist dies $ (System.AccessToken). Wenn Sie es in einem Powershell-Skript auf demselben Agenten verwenden möchten, lautet es bereits $ env: SYSTEM_ACCESSTOKEN. Wenn Sie, Gott bewahre, diese Variable auf einem Remote-Host mithilfe der PowerShell-Aufgabe auf Zielcomputern verwenden möchten, müssen Sie dies mithilfe von param über ein Argument an das Skript übergeben . Mit bash simpler können Sie es einfach mit dem Argument und der Syntax $ SYSTEM_ACCESSTOKEN einwerfen.Die gleichen Gesetze gelten nicht für Ihre eigenen Variablen, hier sind Sie bereits für die Syntax verantwortlich. Sie können Variablen in jeder Aufgabe lokal festlegen.
Oder global im Repository von Variablen und verknüpfen Sie sie dann aus dem Repository. Sehr bequem.
Wenn die Variablen sehr geheim sind, können sie als Bonus in der Azure-Cloud in einem Speicher namens Azure Vault gespeichert werden. Vault kann mit dem Projekt in der Bibliothek verknüpft werden.
Im Allgemeinen ist bei Variablen alles klar. In Pipelines können Sie sie immer noch manuell für jeden Start festlegen. In der Version gibt es keine solche Funktionalität. Sie können in den Agenteninitialisierungsprotokollen sehen, was Sie erneut in die Pipeline übertragen. Beachten Sie jedoch, dass diese bereits in der konvertierten Form vorliegen.
Dynamische Variablen
Der interessanteste Teil beginnt, wenn wir in einer Phase einen Wert erzielen und ihn an die nächste weitergeben möchten.
Eine solche Funktionalität wurde uns nicht geliefert. Aber unsere Hände sind nicht für Langeweile 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 wir in der Benutzeroberfläche gezeichnet haben.Wir brauchen also einen Aufruf, um globale Variablen zu aktualisieren, was wir direkt aus dem Inneren der Pipeline heraus tun werden. Die Adresse stammt aus Umgebungsvariablen, von denen in der Dokumentation, wie bereits erwähnt, kein Wort enthalten ist. Sie können sie selbst fragen oder, was da ist, Hardcode, wenn sie den Shop schließen.$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )
Legen Sie den leeren Wert der Variablen fest, die wir übergeben möchten, und legen Sie Scope - Release fest.Beispielsweise erstellen wir einen zufälligen Wertegenerator. Beachten Sie die Syntax der Variablendeklaration in dieser Phase. Diese Funktionalität wurde eingeführt.
Im nächsten Schritt übergeben wir die Variable an das Skript. Ja, ja, es ist direkt unmöglich, es ist durch das Argument notwendig.
Das Skript unter dem 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))
OderBashINPUT_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
Kurz gesagt, unser Skript verwendet die Eingabevariable myVar und setzt mithilfe der API den Wert dieser Variablen in stageVar. Im nächsten Schritt können wir uns die Syntax von Systemvariablen ansehen.
Das Beispiel ist recht einfach, aber die Funktionalität bietet uns insgesamt gute Möglichkeiten, insgesamt mit meinem letzten Artikel , wenn wir in der ersten Testphase eine virtuelle Maschine erstellen, einige weitere Manipulationen damit vornehmen und gleichzeitig mehrere. Und der letzte Schritt ist, es zu zerstören. Jetzt verfolgen wir jedes Mal Produkt-Selbsttests auf neuen virtuellen Maschinen. Da sie 10 Minuten leben, ist es einen Cent wert.Im nächsten Artikel werde ich bei Bedarf über YAML-Pipelines sprechen. In letzter Zeit gibt es eine Menge interessanter Innovationen.