🥇Azure DevOps പൈപ്പ് ലൈനുകളിൽ വേരിയബിളുകൾ ഉപയോഗിക്കുന്നു

Windows-നും അതിലേറെ കാര്യങ്ങൾക്കുമുള്ള ഒരു അത്ഭുതകരമായ ഉപകരണത്തെക്കുറിച്ചുള്ള ഞങ്ങളുടെ അവലോകനം ഞങ്ങൾ തുടരുന്നു, Azure DevOps. ഇപ്രാവശ്യം, പരിസ്ഥിതി വേരിയബിളുകൾ കൊണ്ട് വളരെയധികം കഷ്ടപ്പെട്ടതിനാൽ, എല്ലാ അനുഭവങ്ങളും ഒരു ലേഖനത്തിൽ ഉൾപ്പെടുത്താൻ ഞാൻ തീരുമാനിച്ചു.

ഓരോ നിർവ്വഹണ പരിതസ്ഥിതിയിലും അവയ്ക്ക് വ്യത്യസ്ത വാക്യഘടനയുണ്ടെന്ന വസ്തുതയിൽ നിന്ന് ആരംഭിച്ച്, പൈപ്പ്ലൈനിന്റെ ഒരു ഘട്ടത്തിൽ നിന്ന് മറ്റൊന്നിലേക്ക് വേരിയബിളുകൾ കൈമാറുന്നതിനുള്ള ഒരു സ്റ്റാൻഡേർഡ് കഴിവിന്റെ അഭാവത്തിൽ അവസാനിക്കുന്നു.

പ്രധാന ഉദാഹരണങ്ങൾ റിലീസ് പൈപ്പ് ലൈനുകളിലായിരിക്കുമെന്ന് ഞാൻ റിസർവേഷൻ ചെയ്യും, കാരണം YAML ഇതുവരെ അവിടെ എത്തിയിട്ടില്ല, കൂടാതെ എനിക്ക് നിരവധി ഘട്ടങ്ങളുടെയും നിരവധി പുരാവസ്തുക്കളുടെയും പ്രവർത്തനക്ഷമത ആവശ്യമാണ്. ഇത് സാധാരണ പൈപ്പ്ലൈനുകളിൽ ലഭ്യമായതായി തോന്നുന്നു, ഇത് പ്രവർത്തനത്തിൽ പ്രായോഗികമായി തുല്യമാണ്. പൈപ്പ്‌ലൈനുകൾ YAML-ൽ, സജ്ജീകരിക്കാൻ കഴിയുന്ന പാരാമീറ്ററുകളുള്ള ടെക്സ്റ്റ് പ്രാതിനിധ്യത്തിലേക്ക് ഞങ്ങൾ ഒരു ചെറിയ ഗ്രാഫിക്കൽ ടൂൾടിപ്പ് ചേർത്തു. ഇത് വളരെ സൗകര്യപ്രദമാണ്; ഓരോ മൊഡ്യൂളിനും നിങ്ങൾ ഡോക്യുമെന്റേഷനിലൂടെ പോകേണ്ടതില്ല. എന്നാൽ ഞാൻ ഇത് അടുത്ത ലേഖനത്തിൽ വിവരിക്കും, എന്നാൽ ഇപ്പോൾ ഇവിടെ നവീകരണത്തിന്റെ തന്നെ ഒരു ചിത്രം ഉണ്ട്.

സംഭരണവും ഉപയോഗവും

നമുക്ക് സിസ്റ്റത്തിൽ സ്ഥിരസ്ഥിതി വേരിയബിളുകൾ ഉണ്ടെന്ന വസ്തുതയിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം. അവ ആരംഭിക്കുന്നത്, അവയുടെ ഉത്ഭവത്തെ ആശ്രയിച്ച്, റിലീസ്, സിസ്റ്റം മുതലായവയിൽ നിന്നാണ്. പൂർണ്ണമായ ലിസ്റ്റ് (അത് മാറുന്നതുപോലെ, അല്ല), ഇവിടെ ലഭ്യമാണ് പ്രമാണീകരണം. വാക്യഘടനയുള്ള എല്ലാ സ്കീസോഫ്രീനിയയും ചുവടെയുള്ള ഡോക്യുമെന്റേഷനിൽ നിന്നുള്ള ഒരു ഉദാഹരണം ഉപയോഗിച്ച് ചിത്രീകരിച്ചിരിക്കുന്നു. ഒരേ വേരിയബിളിന് മൂന്ന് പ്രതിനിധാനങ്ങളുണ്ട്, അത് നമ്മൾ എവിടെയാണ് വിളിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ച്.

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) ആണ്. അതേ ഏജന്റിൽ തന്നെ ഒരു പവർഷെൽ സ്ക്രിപ്റ്റിനുള്ളിൽ ഇത് ഉപയോഗിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, അത് ഇതിനകം തന്നെ $env:SYSTEM_ACCESSTOKEN ആയിരിക്കും. ടാർഗെറ്റ് മെഷീനുകൾ ടാസ്‌ക്കിലെ പവർഷെൽ ഉപയോഗിച്ച് ഏതെങ്കിലും റിമോട്ട് ഹോസ്റ്റിൽ ഈ വേരിയബിൾ ഉപയോഗിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങൾ ഇത് ഉപയോഗിച്ച് സ്‌ക്രിപ്റ്റിലേക്ക് ഒരു ആർഗ്യുമെന്റിലൂടെ കൈമാറേണ്ടതുണ്ട്. പരം. ബാഷ് ഉപയോഗിച്ച് ഇത് ലളിതമാണ്, $SYSTEM_ACCESSTOKEN എന്ന ആർഗ്യുമെന്റും വാക്യഘടനയും ഉപയോഗിച്ച് നിങ്ങൾക്ക് അത് ഉള്ളിലേക്ക് കടത്തിവിടാം.

നിങ്ങളുടെ സ്വന്തം വേരിയബിളുകൾക്ക് സമാന നിയമങ്ങൾ ബാധകമല്ല; ഇവിടെ നിങ്ങൾ ഇതിനകം തന്നെ വാക്യഘടനയ്ക്ക് ഉത്തരവാദിയാണ്. ഓരോ ടാസ്ക്കിലും പ്രാദേശികമായി വേരിയബിളുകൾ സജ്ജമാക്കാൻ കഴിയും.

അല്ലെങ്കിൽ ആഗോളതലത്തിൽ വേരിയബിൾ സ്റ്റോറിലേക്ക്, തുടർന്ന് അവ സ്റ്റോറിൽ നിന്ന് ലിങ്ക് ചെയ്യുക. വളരെ സുഖകരമായി.

ഒരു ബോണസ് എന്ന നിലയിൽ, വേരിയബിളുകൾ വളരെ രഹസ്യമാണെങ്കിൽ, അവ അസൂർ ക്ലൗഡിൽ അസൂർ വോൾട്ട് എന്ന സ്റ്റോറേജിൽ സൂക്ഷിക്കാം; ലൈബ്രറിയിലെ പ്രോജക്റ്റിലേക്ക് വോൾട്ട് ലിങ്ക് ചെയ്യാം.

പൊതുവേ, വേരിയബിളുകൾ ഉപയോഗിച്ച് എല്ലാം വ്യക്തമാണ്; പൈപ്പ്ലൈനുകളിൽ അവ ഓരോ ലോഞ്ചിനും സ്വമേധയാ സജ്ജീകരിക്കാൻ കഴിയും; റിലീസിൽ അത്തരം പ്രവർത്തനങ്ങളൊന്നുമില്ല. ഏജന്റ് ഇനീഷ്യലൈസേഷൻ ലോഗുകളിൽ നിങ്ങൾ വീണ്ടും പൈപ്പ്ലൈനിലേക്ക് എന്താണ് കൈമാറുന്നതെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും, എന്നാൽ അവ ഇതിനകം തന്നെ പരിവർത്തനം ചെയ്ത രൂപത്തിൽ ഉണ്ടെന്ന് ഓർമ്മിക്കുക.

ഡൈനാമിക് വേരിയബിളുകൾ

ഒരു ഘട്ടത്തിൽ കുറച്ച് മൂല്യം ലഭിക്കുകയും അത് അടുത്ത ഘട്ടത്തിലേക്ക് കൈമാറുകയും ചെയ്യുമ്പോഴാണ് തമാശ ആരംഭിക്കുന്നത്.

ഞങ്ങൾക്ക് അത്തരം പ്രവർത്തനക്ഷമത നൽകിയിട്ടില്ല. എന്നാൽ ഞങ്ങളുടെ കൈകൾ വിരസതയ്ക്കുള്ളതല്ല, ഗൂഗിളിന്റെ സഹായത്തോടെ ഒരു പരിഹാരം കണ്ടെത്തി. ദൈവത്തിന് നന്ദി, ഇന്റർഫേസിൽ ചിത്രീകരിച്ചിരിക്കുന്നതിനേക്കാൾ കുറച്ച് കൂടുതൽ ചെയ്യാൻ ഞങ്ങളെ അനുവദിക്കുന്ന ഒരു API Azure DevOps-നുണ്ട്.

അതിനാൽ, ആഗോള വേരിയബിളുകൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് ഞങ്ങൾക്ക് ഒരു കോൾ ആവശ്യമാണ്, അത് ഞങ്ങൾ പൈപ്പ് ലൈനിനുള്ളിൽ നിന്ന് നേരിട്ട് ചെയ്യും. നേരത്തെ സൂചിപ്പിച്ചതുപോലെ, ഡോക്യുമെന്റേഷനിൽ ഒരു വാക്കുപോലും ഇല്ലാത്ത പരിസ്ഥിതി വേരിയബിളുകളിൽ നിന്നാണ് വിലാസം എടുത്തത്. നിങ്ങൾക്ക് അവ സ്വയം സജ്ജീകരിക്കാം അല്ലെങ്കിൽ, അവർ കട അടച്ചാൽ ഹാർഡ്കോഡ് ചെയ്യുക.

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

നമുക്ക് കൈമാറാൻ ആഗ്രഹിക്കുന്ന വേരിയബിളിന്റെ ശൂന്യമായ മൂല്യം ഞങ്ങൾ സജ്ജമാക്കി, സ്കോപ്പ് - റിലീസ് സജ്ജമാക്കുക

ഉദാഹരണത്തിന്, ഞങ്ങൾ ചില ക്രമരഹിത മൂല്യ ജനറേറ്റർ ഉണ്ടാക്കുന്നു. ഈ ഘട്ടത്തിനുള്ളിൽ ഒരു വേരിയബിൾ പ്രഖ്യാപിക്കുന്നതിനുള്ള വാക്യഘടന ശ്രദ്ധിക്കുക; ഈ പ്രവർത്തനം അവതരിപ്പിച്ചു.

അടുത്ത ഘട്ടത്തിൽ, ഞങ്ങൾ സ്ക്രിപ്റ്റിലേക്ക് വേരിയബിൾ കൈമാറുന്നു, അതെ, അതെ, ഇത് നേരിട്ട് സാധ്യമല്ല, അത് ഒരു ആർഗ്യുമെന്റിലൂടെ ആയിരിക്കണം.

സ്‌പോയ്‌ലറിന് കീഴിലുള്ള സ്‌ക്രിപ്റ്റ്

പവർഷെൽ

#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 എന്ന വേരിയബിളിനെ ഇൻപുട്ടായി എടുക്കുകയും ഈ വേരിയബിളിന്റെ മൂല്യം stageVar-ൽ ഉൾപ്പെടുത്താൻ API ഉപയോഗിക്കുകയും ചെയ്യുന്നു. അടുത്ത ഘട്ടത്തിൽ, സിസ്റ്റം വേരിയബിൾ സിന്റാക്സ് ഉപയോഗിച്ച്, നമുക്ക് അത് നോക്കാം.

ഉദാഹരണം വളരെ ലളിതമാണ്, എന്നാൽ പ്രവർത്തനം എന്റെ മുമ്പത്തേതിന് പുറമേ ഞങ്ങൾക്ക് നല്ല അവസരങ്ങൾ തുറക്കുന്നു ലേഖനങ്ങൾ, പരീക്ഷണത്തിന്റെ ആദ്യ ഘട്ടത്തിൽ നമുക്ക് ഒരു വെർച്വൽ മെഷീൻ സൃഷ്ടിക്കാൻ കഴിയുമ്പോൾ, അത് ഉപയോഗിച്ച് കൂടുതൽ കൃത്രിമങ്ങൾ നടത്തുക, കൂടാതെ നിരവധി സമാന്തരമായി. അവസാന ഘട്ടം അതിനെ നശിപ്പിക്കുക എന്നതാണ്. ഇപ്പോൾ ഞങ്ങൾ പുതിയ വെർച്വൽ മെഷീനുകളിൽ ഓരോ തവണയും ഉൽപ്പന്നത്തിന്റെ ഓട്ടോടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നു. അവർ ഏകദേശം 10 മിനിറ്റ് ജീവിക്കുന്നത് കണക്കിലെടുക്കുമ്പോൾ, ഇതിന് ഒരു പൈസ ചിലവാകും.

അടുത്ത ലേഖനത്തിൽ, ആവശ്യമെങ്കിൽ, ഞാൻ YAML പൈപ്പ്ലൈനുകളെ കുറിച്ച് സംസാരിക്കും; ഈയിടെയായി അവിടെ രസകരമായ ഒരുപാട് കണ്ടുപിടിത്തങ്ങൾ ഉണ്ടായിട്ടുണ്ട്.

അവലംബം: www.habr.com

Azure DevOps പൈപ്പ് ലൈനുകളിൽ വേരിയബിളുകൾ ഉപയോഗിക്കുന്നു

സംഭരണവും ഉപയോഗവും

ഡൈനാമിക് വേരിയബിളുകൾ

ഒരു അഭിപ്രായം ചേർക്കുക മറുപടി റദ്ദാക്കാൻ

ഒരു അഭിപ്രായം ചേർക്കുക