🥇استخدام المتغيرات في مسارات 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 على الأجهزة المستهدفة، فستحتاج إلى تمرير هذا من خلال وسيطة إلى البرنامج النصي باستخدام المعلمة. مع bash يكون الأمر أبسط، يمكنك ببساطة تمريره إلى الداخل باستخدام الوسيطة وبناء الجملة $SYSTEM_ACCESSTOKEN.

نفس القوانين لا تنطبق على المتغيرات الخاصة بك، هنا أنت بالفعل مسؤول عن بناء الجملة. يمكن تعيين المتغيرات محليا في كل مهمة.

أو عالميًا إلى متغير المتجر، ومن ثم ربطهما من المتجر. بشكل مريح للغاية.

كمكافأة، إذا كانت المتغيرات سرية للغاية، فيمكن تخزينها في سحابة 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)  )

نقوم بتعيين القيمة الفارغة للمتغير الذي نريد نقله، وتعيين النطاق - الإصدار

على سبيل المثال، نقوم بإنشاء بعض مولدات القيمة العشوائية. انتبه إلى صيغة الإعلان عن المتغير داخل هذه المرحلة، فقد تم تقديم هذه الوظيفة.

في الخطوة التالية، نقوم بتمرير المتغير إلى البرنامج النصي، نعم، نعم، هذا غير ممكن بشكل مباشر، يجب أن يكون من خلال وسيطة.

السيناريو تحت المفسد

بوويرشيل

#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، فقد كان هناك الكثير من الابتكارات المثيرة للاهتمام مؤخرًا.

المصدر: www.habr.com

استخدام المتغيرات في خطوط أنابيب Azure DevOps

التخزين والاستخدام

المتغيرات الديناميكية

إضافة تعليق إلغاء الرد