Við höldum áfram endurskoðun okkar á frábæru tóli fyrir þróun fyrir Windows og fleira, Azure DevOps. Að þessu sinni, eftir að hafa þjáðst mikið af umhverfisbreytum, ákvað ég að setja alla reynsluna í eina grein.
Byrjar á því að þeir hafa mismunandi setningafræði fyrir hvert framkvæmdarumhverfi, endar með skorti á staðlaðri getu til að flytja breytur frá einu stigi leiðslunnar til annars.
Ég ætla að gera fyrirvara um að helstu dæmin verði á Release Pipelines, vegna þess að YAML er ekki enn komið þangað og ég þarf virkni margra stiga og margra gripa. Þetta virðist hafa orðið fáanlegt í venjulegum leiðslum, sem nánast jafnast á við þá í virkni. Í Pipelines YAML bættum við litlum grafískum tóli við textaframsetninguna með breytum sem hægt er að stilla. Það er mjög þægilegt; þú þarft ekki að fara í gegnum skjölin fyrir hverja einingu. En ég mun lýsa þessu í næstu grein, en í bili er hér mynd af nýjunginni sjálfri.
Geymsla og notkun
Við skulum byrja á því að við höfum sjálfgefnar breytur í kerfinu. Þeir byrja, allt eftir uppruna þeirra, á orðunum Release, System o.s.frv. Listinn í heild sinni (eins og það kemur í ljós, ekki), er fáanlegur á . Allur geðklofi með setningafræði er sýndur með dæmi úr skjölunum hér að neðan. Sama breytan hefur þrjár framsetningar, eftir því hvar við köllum hana.
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)Ef þú stillir breytu á umboðsmanninn sem verkefnið er keyrt á er það $(System.AccessToken). Ef þú vilt nota það í powershell skriftu á sama umboðsmanni, þá verður það nú þegar $env:SYSTEM_ACCESSTOKEN. Ef þú, guð forði frá sér, vilt nota þessa breytu á einhverjum ytri hýsil sem notar PowerShell á markvélarverkefnið þarftu að senda þetta í gegnum rök til handritsins með því að nota . Með bash er það einfaldara, þú getur einfaldlega sent það inn með því að nota rökin og setningafræðina $SYSTEM_ACCESSTOKEN.
Sömu lögmál gilda ekki um þínar eigin breytur; hér ertu nú þegar ábyrgur fyrir setningafræðinni. Hægt er að stilla breytur á staðnum í hverju verkefni.
Eða á heimsvísu við breytuverslunina og tengdu þær síðan úr versluninni. Mjög þægilegt.
Sem bónus, ef breyturnar eru mjög leyndar, er hægt að geyma þær í Azure skýinu í geymslu sem kallast Azure Vault; þú getur tengt Vault við verkefnið í bókasafninu.
Almennt séð er allt skýrt með breytum; í leiðslum er samt hægt að stilla þær handvirkt fyrir hverja sjósetningu; í útgáfu er engin slík virkni. Þú getur séð það sem þú ert að flytja yfir í leiðsluna aftur í upphafsskrám umboðsmanns, en hafðu í huga að þeir eru þegar til staðar í umbreyttu formi.
Dynamic Variables
Gamanið byrjar þegar við viljum fá einhver verðmæti á einu stigi og koma því yfir á það næsta.
Okkur var ekki veitt slík virkni. En hendur okkar eru ekki fyrir leiðindum og með hjálp Google fannst lausn. Guði sé lof, Azure DevOps er með API sem gerir okkur kleift að gera aðeins meira en það sem lýst var í viðmótinu.
Svo við þurfum að hringja til að uppfæra alþjóðlegar breytur, sem við munum gera beint innan leiðslunnar. Heimilisfangið er tekið úr umhverfisbreytum, þeim sömu og ekki er orð um í skjölunum eins og fyrr segir. Þú getur stillt þær sjálfur eða, það sem meira er, harðkóða þær ef þær loka búðinni.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Við stillum tómt gildi breytunnar sem við viljum flytja, stillum Scope - Release
Til dæmis gerum við einhvern tilviljunarkenndan gildisgjafa. Gefðu gaum að setningafræði að lýsa yfir breytu á þessu stigi; þessi virkni var kynnt.
Í næsta skrefi sendum við breytuna í handritið, já, já, það er ekki hægt beint, það verður að vera í gegnum rifrildi.
Handrit undir 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))
#endregionEða
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Í hnotskurn tekur handritið okkar breytuna myVar sem inntak og notar API til að setja gildi þessarar breytu í stageVar. Í næsta skrefi, með því að nota setningafræði kerfisbreytu, getum við skoðað það.
Dæmið er frekar einfalt, en virknin opnar okkur góð tækifæri, til viðbótar við mína fyrri , þegar við getum búið til sýndarvél á fyrsta stigi prófunar, framkvæmum nokkrar frekari meðhöndlun með henni og nokkrar samhliða. Og lokastigið er að eyða því. Nú keyrum við sjálfvirkar prófanir á vörunni í hvert skipti á ferskum sýndarvélum. Miðað við að þeir lifa í um það bil 10 mínútur kostar það eina krónu.
Í næstu grein, ef þörf krefur, mun ég tala um YAML leiðslur; það hefur verið töluvert mikið af áhugaverðum nýjungum þar undanfarið.
Heimild: www.habr.com