Մենք շարունակում ենք Windows-ով և ոչ միայն նախատեսված զարգացնում ստեղծագործությունների լուսանկարները Azure DevOps-ի վերանայումը: Այս անգամ, ծանոթանալով միջավայրերի փոփոխականներին, ես որոշեցի ամբողջ փորձը տանել մի հոդված:
Սկսելով նրանից, որ յուրաքանչյուր գործառնական միջավայր ունի իր տարբերախոսությունը, և ավարտելով այդ պայմաններում փոփոխականների տեղափոխման ստանդարտ միջոցների բացակայությամբ:
Մի քանի խոսքեր ասեմ, որ հիմնական օրինակները կլինեն Release Pipelines- ում, քանի որ YAML-ը դեռ ուշանում է, իսկ ինձ անհրաժեշտ են բազմաթիվ օրերի և բազմաթիվ արվարձանների գործառույթներ: Դա, կարծես, հասանելի է դարձել սովորական Pipelines- ում, ինչը գրեթե հավասարեցրեց նրանց գործառույթի վերևում: Pipelines YAML-ը նաև բարելավվել է և ավելացվել է տեքստային ներկայացմանը, փոքր գրաֆիկական նշումով պարամետրերի անվտանգության համար: Դա շատ հարմար է, անհրաժեշտ է մուտք գործել յուրաքանչյուր մոդուլի փաստաթղթում: Բայց դա կբերեմ հաջորդ հոդվածում, իսկ մինչ այժմ ահա նորության նկար:

Պահպանման և օգտագործման
Թողեք ասել, որ համակարգում ունենք նախնական փոփոխականներ: Նրանք տարբերություն ունեն, կախված ծագումից, սկսվում են բառերով Release, System և այլն: Լիակատար ցուցակ (ինչպես պարզվեց, չկա) հասանելի է . Չի ստացվում, որ հայտարարված իմաստությունը ունի մեկ փոփոխական երեք ներկայացում, կախված նրանից, թե որտեղ ենք կանչում այն:
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)Եթե դուք փոփոխականը սահմանում եք գործարանի վրա, որտեղ կատարվում է առաջադրանքը, դա $(System.AccessToken) կլինի: Եթե ցանկանում եք օգտագործել այն PowerShell սցենարի ներսում նույն գործարանում, դա արդեն կլինի $env:SYSTEM_ACCESSTOKEN: Եթե դուք, ճշմարիտ մինչև, ցանկանում եք օգտագործել այդ փոփոխականը ինչ-որ հեռավոր հոստում, օգտագործելով PowerShell on target machines առաջադրանքը, դա պետք է փոխանցվի սցենարի արգումենտի միջոցով, օգտագործելով . Bash- ում բոլորն ավելի պարզ է, պարզապես պետք է ներարկել այն արգումենտի միջոցով և $SYSTEM_ACCESSTOKEN սինտեքսով:
Այս օրենքները չեն տարածվում ձեր սեփական փոփոխականների վրա, այստեղ արդեն դուք պետք է լինեք պատասխանատու սինտեքսի համար: Դուք կարող եք սահմանել փոփոխականները տեղային յուրաքանչյուր առաջադրանքում:

Կամ համաշխարհային փոփոխականների պահոցում, ապա դրանք կապակցել պահոցի միջոցով: Դժվար չէ:

Այս ամենի շնորհիվ, եթե փոփոխականները չափազանց գաղտնի են, դրանք կարելի է պահել Azure ծրագրից Azure Vault-ում, Vault- ը նախագծին կապելու հնարքը Library-ում է:

Ընդհանուր առմամբ, փոփոխականների մեջ գրավում է, որ pipelines-ում դրանք կարելի է սահմանել ձեռքով յուրաքանչյուր մեկնարկի համար, release-ում այդպիսի գործառույթ չկա: Դուք կարող եք տեսնել, թե ինչ եք փոխանցում pipelines-ին, ոչ մի տեղում առաջադրված արգումենտներով, բայց նկատեք, դրանք արդեն փոխակերպված ձևերի մեջ են:

Դինամիկ փոփոխականներ
Ամենա հետաքրքիր բան սկսվում է, երբ ցանկանում ենք ստանալ որոշ արժեք մեկ փուլում և փոխանցել այն հաջորդին:

Ամանավայրում այդ հնարավորությունը չունեինք։ Բայց մեր ձեռքերը չեն քնի համար, ու մենք լուծում ենք գտել Google-ի միջոցով։ Շնորհիվ Աստվածային ծառայություն Azure DevOps-ի API-ն մեզ հնարավորություն է տալիս անել ավելին, քան ինչ նշված է ինտերֆեյսում։
Ուստի, մեզ անհրաժեշտ է գլոբալ փոփոխականների թարմացման զանգ, որը մենք կկատարենք ուղղակի նախապատրաստության ընթացքում։ Հասցեն վերցվում է մթնոլորտային փոփոխականներից, որոնց մասին ոչ մի բառ չկա փաստաթղթերում, ինչպես նշվել է ավելի վաղ։ Դուք կարող եք դրանք ինքնուրույն պարունակել կամ, ինչ խոսք, խստորեն գրել, եթե դրանք փակեն։
$releaseurl = ('{0}{1}\/ _apis\/release\/releases\/ {2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID))Սահմանում ենք դատարկ արժեք փոփոխականի համար, որը ցանկանում ենք փոխանցել, դնում ենք Scope — Release

Օգտագործելով ինչ-որ պատահական արժեքների գեներատոր։ Նշեք փոփոխականի հայտարարության սինտաքսը այս փուլում, այդ հնարավորությունը ունենք։

Հաջորդ փուլում մենք փոխանցում ենք փոփոխականը սկրիպտին, այո, այո, ուղղակի հնարավոր չէ, պետք է արգումենտով։

Սկրիպտը սփոյլերում
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Կամ
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Երկու բառով, մեր սկրիպտը վերցնում է myVar փոփոխականը և օգտագործում է API-ը՝ այդ փոփոխականի արժեքը դնելու stageVar-ում։ Հաջորդ փուլում, օգտագործելով համակարգային փոփոխականների սինտաքսը, մենք կարող ենք այն տեսնել։

Օրինակն բավականին պարզ է, սակայն այս հնարավորությունը մեզ տալիս է լավ հնարավորություններ, ի մի իմ անցյալին , երբ մենք կարող ենք ստեղծել виртуալ մեքենա առաջին փորձաշրջանում, կատարելով որոշ գործողություններ հետագայում, և զուգահեռաբար մի քանիսը։ Եվ վերջնական փուլում այն խորտակել։ Հիմա մեր ավտոտեստերը գործարկվում են ապրանքին ամեն անգամ նոր սինոնիմների վրա։ Հաշվի առնելով, որ նրանք ապրում են 10 րոպե, սա արժե մի կոպեկ։
Հաջորդ հոդվածում, եթե անհրաժեշտություն լինի, կպատմեմ YAML pipeline-ների մասին, այնտեղ բավականին հետաքրքիր նորույթներ են եղել վերջին շրջանում։
Ընտանիք: habr.com
