🥇การใช้ตัวแปรในไปป์ไลน์ Azure DevOps

เรายังคงตรวจสอบเครื่องมือที่ยอดเยี่ยมสำหรับการพัฒนาสำหรับ 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 บนเครื่องเป้าหมาย คุณจะต้องส่งผ่านสิ่งนี้ผ่านการโต้แย้งไปยังสคริปต์โดยใช้ พารามิเตอร์. ด้วย 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)  )

เราตั้งค่าว่างของตัวแปรที่เราต้องการถ่ายโอนกำหนดขอบเขต - ปล่อย

ตัวอย่างเช่น เราสร้างตัวสร้างค่าสุ่มขึ้นมา ให้ความสนใจกับไวยากรณ์ของการประกาศตัวแปรภายในขั้นตอนนี้ ซึ่งมีการนำฟังก์ชันนี้มาใช้

ในขั้นตอนถัดไป เราส่งตัวแปรไปที่สคริปต์ ใช่ ใช่ มันเป็นไปไม่ได้โดยตรง มันจะต้องผ่านการโต้แย้ง

สคริปต์ภายใต้สปอยเลอร์

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 มีนวัตกรรมที่น่าสนใจค่อนข้างมากเมื่อเร็ว ๆ นี้

ที่มา: will.com

การใช้ตัวแปรในไปป์ไลน์ Azure DevOps

การจัดเก็บและการใช้งาน

ตัวแปรไดนามิก

เพิ่มความคิดเห็น ยกเลิกการตอบ