We vervolgen onze recensie van een prachtige tool voor ontwikkeling voor Windows en meer, Azure DevOps. Omdat ik deze keer veel te maken had gehad met omgevingsvariabelen, besloot ik alle ervaring in één artikel onder te brengen.
Beginnend met het feit dat ze voor elke uitvoeringsomgeving een andere syntaxis hebben, eindigend met het ontbreken van een standaardmogelijkheid om variabelen van de ene fase van de pijplijn naar de andere over te dragen.
Ik reserveer dat de belangrijkste voorbeelden op Release Pipelines zullen staan, omdat YAML er nog niet is, en ik de functionaliteit van veel fasen en veel artefacten nodig heb. Het lijkt erop dat dit beschikbaar is gekomen in reguliere Pipelines, wat qua functionaliteit vrijwel gelijk is aan hen. In Pipelines YAML hebben we een kleine grafische tooltip toegevoegd aan de tekstweergave met parameters die kunnen worden ingesteld. Heel handig, je hoeft niet bij elke module de documentatie door te nemen. Maar ik zal dit in het volgende artikel beschrijven, maar voor nu is hier een foto van de innovatie zelf.
Opslag en gebruik
Laten we beginnen met het feit dat we standaardvariabelen in het systeem hebben. Ze beginnen, afhankelijk van hun herkomst, met de woorden Release, System, etc. De volledige lijst (zo blijkt niet) is beschikbaar op . Alle schizofrenie met syntaxis wordt geïllustreerd aan de hand van een voorbeeld uit de onderstaande documentatie. Dezelfde variabele heeft drie representaties, afhankelijk van waar we hem noemen.
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)Als u een variabele instelt voor de agent waarop de taak wordt uitgevoerd, is dit $(System.AccessToken). Als je het in een powershell-script op dezelfde agent wilt gebruiken, zal het al $env:SYSTEM_ACCESSTOKEN zijn. Als je, God verhoede, deze variabele op een externe host wilt gebruiken met behulp van de PowerShell-taak op doelmachines, moet je dit via een argument doorgeven aan het script met behulp van . Met bash is het eenvoudiger, je kunt het eenvoudigweg doorgeven met behulp van het argument en de syntaxis $SYSTEM_ACCESSTOKEN.
Dezelfde wetten zijn niet van toepassing op uw eigen variabelen; hier bent u al verantwoordelijk voor de syntaxis. Variabelen kunnen in elke taak lokaal worden ingesteld.
Of globaal naar de variabele winkel en koppel ze vervolgens vanuit de winkel. Zeer comfortabel.
Als bonus kunnen de variabelen, als ze erg geheim zijn, worden opgeslagen in de Azure-cloud in een opslag genaamd Azure Vault; u kunt Vault koppelen aan het project in de bibliotheek.
Over het algemeen is alles duidelijk met variabelen; in pijplijnen kunnen ze nog steeds handmatig worden ingesteld voor elke lancering; in release is er geen dergelijke functionaliteit. U kunt in de agentinitialisatielogboeken weer zien wat u naar de pijplijn overdraagt, maar houd er rekening mee dat deze er al in geconverteerde vorm zijn.
Dynamische variabelen
Het plezier begint wanneer we in de ene fase wat waarde willen ontvangen en deze willen doorgeven aan de volgende.
Wij waren niet voorzien van dergelijke functionaliteit. Maar onze handen zijn niet voor verveling en met hulp van Google werd er een oplossing gevonden. Godzijdank heeft Azure DevOps een API waarmee we iets meer kunnen doen dan wat in de interface werd weergegeven.
We hebben dus een oproep nodig om globale variabelen bij te werken, wat we rechtstreeks vanuit de pijplijn zullen doen. Het adres is ontleend aan omgevingsvariabelen, dezelfde waarover in de documentatie niets wordt gezegd, zoals eerder vermeld. Je kunt ze zelf instellen of, sterker nog, ze hardcoderen als ze de winkel sluiten.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )We stellen de lege waarde in van de variabele die we willen overbrengen, stellen Scope - Release in
We maken bijvoorbeeld een generator voor willekeurige waarden. Besteed aandacht aan de syntaxis van het declareren van een variabele in deze fase; deze functionaliteit is geïntroduceerd.
In de volgende stap geven we de variabele door aan het script. Ja, ja, dat is niet rechtstreeks mogelijk, het moet via een argument gebeuren.
Script onder 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))
#endregionOf
Slaan
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_URLKort gezegd neemt ons script de variabele myVar als invoer en gebruikt het de API om de waarde van deze variabele in stageVar te plaatsen. In de volgende stap kunnen we, met behulp van de syntaxis van systeemvariabelen, ernaar kijken.
Het voorbeeld is vrij eenvoudig, maar de functionaliteit biedt goede mogelijkheden voor ons, naast mijn vorige , wanneer we in de eerste testfase een virtuele machine kunnen maken, er nog enkele manipulaties mee kunnen uitvoeren, en meerdere parallel. En de laatste fase is het vernietigen ervan. Nu voeren we elke keer autotests van het product uit op nieuwe virtuele machines. Gezien het feit dat ze ongeveer 10 minuten leven, kost het een cent.
In het volgende artikel zal ik, indien nodig, praten over YAML-pijplijnen; daar zijn de laatste tijd behoorlijk wat interessante innovaties geweest.
Bron: www.habr.com