Változók használata az Azure DevOps folyamatokban

Folytatjuk a Windows és más rendszerek fejlesztésére szolgáló csodálatos eszköz, az Azure DevOps áttekintését. Ezúttal, miután sokat szenvedtem a környezeti változókkal, úgy döntöttem, hogy az összes tapasztalatot egy cikkbe foglalom.

Kezdve attól a ténytől, hogy minden végrehajtási környezethez eltérő szintaxisuk van, egészen a változók átviteli folyamat egyik szakaszából a másikba való szabványos képességének hiányáig.

Foglalkozom azzal, hogy a fő példák a Release Pipelines-en lesznek, mert a YAML még nem jutott el odáig, és sok szakasz és sok műtermék funkcionalitására van szükségem. Ez, úgy tűnik, elérhetővé vált a normál Pipeline-ekben, ami gyakorlatilag megegyezik velük funkcionalitásban. A Pipelines YAML-ben egy kis grafikus eszköztippet adtunk a szöveges megjelenítéshez, beállítható paraméterekkel. Nagyon kényelmes, nem kell minden modul dokumentációját végignéznie. De ezt a következő cikkben leírom, de egyelőre itt van egy kép magáról az újításról.

Változók használata az Azure DevOps folyamatokban

Tárolás és felhasználás

Kezdjük azzal, hogy vannak alapértelmezett változóink a rendszerben. Eredetüktől függően a Release, System stb. szavakkal kezdődnek. A teljes lista (mint kiderült, nem) elérhető a címen dokumentáció. Az összes szintaxissal rendelkező skizofréniát egy példa szemlélteti az alábbi dokumentációból. Ugyanannak a változónak három reprezentációja van, attól függően, hogy hol nevezzük.

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)

Ha beállít egy változót az ügynökön, amelyen a feladat végrehajtásra kerül, akkor az $(System.AccessToken). Ha egy powershell-szkripten belül szeretné használni ugyanazon az ügynökön, akkor már $env:SYSTEM_ACCESSTOKEN lesz. Ha ne adj isten, használni szeretné ezt a változót egy távoli gépen a PowerShell a célgépeken feladat használatával, akkor ezt egy argumentumon keresztül kell átadnia a szkriptnek az én pénzem. A bash segítségével egyszerűbb, egyszerűen átadhatja a $SYSTEM_ACCESSTOKEN argumentum és szintaxis használatával.

Ugyanezek a törvények nem vonatkoznak a saját változóidra, itt már te vagy a felelős a szintaxisért. Az egyes feladatokban helyileg beállíthatók a változók.

Változók használata az Azure DevOps folyamatokban

Vagy globálisan a változó tárolóba, majd linkelni őket az áruházból. Nagyon kényelmesen.

Változók használata az Azure DevOps folyamatokban

Bónuszként, ha a változók nagyon titkosak, az Azure-felhőben tárolhatók az Azure Vault nevű tárolóban; a Vault-ot a projekthez kapcsolhatja a könyvtárban.

Változók használata az Azure DevOps folyamatokban

Általánosságban elmondható, hogy a változókkal minden világos, a csővezetékekben továbbra is manuálisan beállíthatók minden indításhoz; kiadásban nincs ilyen funkció. Az ügynök inicializálási naplóiban újra láthatja, hogy mit visz át a folyamatba, de ne feledje, hogy konvertált formában már ott vannak.

Változók használata az Azure DevOps folyamatokban

Dinamikus változók

A móka akkor kezdődik, amikor az egyik szakaszban szeretnénk valamilyen értéket kapni, és átadni a következőnek.

Változók használata az Azure DevOps folyamatokban

Nem kaptunk ilyen funkciót. De a kezünk nem az unalomra való, és a Google segítségével meg is találtuk a megoldást. Hála Istennek, az Azure DevOps olyan API-val rendelkezik, amely lehetővé teszi számunkra, hogy egy kicsit többet tegyünk, mint amit a felületen ábrázoltunk.

Tehát szükségünk lesz egy hívásra a globális változók frissítéséhez, amit közvetlenül a folyamaton belül fogunk megtenni. A cím a környezeti változókból származik, ugyanazokból, amelyekről a dokumentációban szó sincs, ahogy korábban említettük. Beállíthatja őket saját kezűleg, vagy mi több, kódolhatja őket, ha bezárják az üzletet.

$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID)  )

Beállítjuk az átvinni kívánt változó üres értékét, a Scope - Release beállítást

Változók használata az Azure DevOps folyamatokban

Például készítünk valamilyen véletlenérték generátort. Ügyeljen a változó deklarálásának szintaxisára ebben a szakaszban; ezt a funkciót vezették be.

Változók használata az Azure DevOps folyamatokban

A következő lépésben a változót adjuk át a szkriptnek, igen, igen, ez közvetlenül nem lehetséges, argumentumon keresztül kell.

Változók használata az Azure DevOps folyamatokban

Szkript spoiler alatt

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))
#endregion

Vagy

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_URL

Dióhéjban: a szkriptünk a myVar változót veszi be bemenetként, és az API segítségével adja meg ennek a változónak az értékét a stageVar-ba. A következő lépésben a rendszerváltozó szintaxisát használva megnézhetjük.

Változók használata az Azure DevOps folyamatokban

A példa meglehetősen egyszerű, de a funkcionalitás jó lehetőségeket nyit meg előttünk az eddigiek mellett cikk, amikor a tesztelés első szakaszában létrehozhatunk egy virtuális gépet, elvégezhetünk vele néhány további manipulációt, és több párhuzamosan is. És az utolsó szakasz az elpusztítása. Mostantól minden alkalommal lefuttatjuk a termék automatikus tesztelését friss virtuális gépeken. Figyelembe véve, hogy körülbelül 10 percig élnek, ez egy fillérbe kerül.

A következő cikkben, ha szükséges, a YAML pipeline-okról fogok beszélni, ott az utóbbi időben elég sok érdekes újítás történt.

Forrás: will.com

Hozzászólás