🥇Փոփոխականների օգտագործումը Azure DevOps խողովակաշարերում

Մենք շարունակում ենք Windows-ի և ավելին մշակելու հիանալի գործիքի՝ Azure DevOps-ի մեր վերանայումը: Այս անգամ, շատ տուժելով շրջակա միջավայրի փոփոխականներից, ես որոշեցի ամբողջ փորձը դնել մեկ հոդվածի մեջ:

Սկսած նրանից, որ նրանք ունեն տարբեր շարահյուսություն յուրաքանչյուր կատարման միջավայրի համար, ավարտվում է խողովակաշարի մի փուլից մյուսը փոփոխականները փոխանցելու ստանդարտ ունակության բացակայությամբ:

Ես վերապահում կանեմ, որ հիմնական օրինակները կլինեն Release Pipelines-ում, քանի որ YAML-ը դեռ այնտեղ չի հասել, և ինձ անհրաժեշտ են բազմաթիվ փուլերի և բազմաթիվ արտեֆակտների ֆունկցիոնալությունը: Սա, կարծես, հասանելի է դարձել սովորական խողովակաշարերում, ինչը գործնականում հավասարեցնում է նրանց ֆունկցիոնալությամբ: 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-ը գրադարանի նախագծին:

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

Դինամիկ փոփոխականներ

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

Մեզ նման ֆունկցիոնալություն չի տրամադրվել։ Բայց մեր ձեռքերը ձանձրույթի համար չեն ու 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

Կամ

Ուժեղ հարվածել

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 խողովակաշարերի մասին, վերջին շրջանում այնտեղ բավականին շատ հետաքրքիր նորամուծություններ կան։

Source: www.habr.com

Azure DevOps խողովակաշարերում փոփոխականների օգտագործումը

Պահպանման եւ օգտագործման համար

Դինամիկ փոփոխականներ

Добавить комментарий Չեղարկել պատասխանել