ما به بررسی یک ابزار فوق العاده برای توسعه ویندوز و موارد دیگر، 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 در ماشین های هدف استفاده کنید، باید این را از طریق یک آرگومان به اسکریپت با استفاده از
قوانین یکسانی برای متغیرهای خود شما اعمال نمی شود؛ در اینجا شما قبلاً مسئول نحو هستید. متغیرها را می توان به صورت محلی در هر کار تنظیم کرد.
یا به صورت سراسری به فروشگاه متغیر، و سپس آنها را از فروشگاه مرتبط کنید. خیلی راحت
به عنوان یک امتیاز، اگر متغیرها بسیار مخفی هستند، می توان آنها را در ابر Azure در فضای ذخیره سازی به نام Azure Vault ذخیره کرد؛ می توانید Vault را به پروژه در کتابخانه پیوند دهید.
به طور کلی، همه چیز با متغیرها مشخص است؛ در خطوط لوله هنوز هم می توان آنها را به صورت دستی برای هر راه اندازی تنظیم کرد؛ در نسخه انتشار چنین عملکردی وجود ندارد. میتوانید آنچه را که به خط لوله انتقال میدهید دوباره در گزارشهای اولیهسازی عامل مشاهده کنید، اما به خاطر داشته باشید که آنها قبلاً به شکل تبدیل شده وجود دارند.
متغیرهای پویا
سرگرمی زمانی شروع می شود که می خواهیم در یک مرحله مقداری ارزش دریافت کنیم و آن را به مرحله بعدی منتقل کنیم.
چنین عملکردی به ما ارائه نشده است. اما دست ما برای کسالت نیست و با کمک گوگل راه حلی پیدا شد. خدا را شکر، 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 استفاده می کند. در مرحله بعد با استفاده از سینتکس متغیر سیستم می توانیم به آن نگاه کنیم.
مثال بسیار ساده است، اما عملکرد، علاوه بر موارد قبلی، فرصت های خوبی را برای ما باز می کند
در مقاله بعدی، در صورت لزوم، در مورد خطوط لوله YAML صحبت خواهم کرد؛ اخیراً نوآوری های بسیار جالبی در آنجا وجود داشته است.
منبع: www.habr.com