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

نواصل مراجعة الأداة الرائعة لتطوير Windows وليس فقط Azure DevOps. هذه المرة ، معذبة بمتغيرات البيئة ، قررت أن أضع كل الخبرة في مقال واحد.

بدءًا من حقيقة أن لكل بيئة وقت تشغيل بنية مختلفة ، تنتهي بنقص القدرة القياسية على نقل المتغيرات من مرحلة من خط الأنابيب إلى مرحلة أخرى.

سأبدي تحفظًا بأن الأمثلة الرئيسية ستكون في خطوط أنابيب الإصدار ، لأن YAML لم تصل إليها بعد ، وأحتاج إلى وظائف العديد من المراحل والعديد من القطع الأثرية. هذا ، على ما يبدو ، أصبح متاحًا في خطوط الأنابيب العادية ، والتي سوتهم عمليًا في الوظائف. في خطوط الأنابيب ، أضافت 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). إذا كنت تريد استخدامه داخل البرنامج النصي powerhell على نفس الوكيل ، فسيكون بالفعل $ env: SYSTEM_ACCESSTOKEN. إذا كنت لا ترغب في استخدام هذا المتغير على بعض المضيف البعيد باستخدام مهمة PowerShell على الأجهزة المستهدفة ، فأنت بحاجة إلى تمرير هذا من خلال وسيطة إلى البرنامج النصي باستخدام المعلمة . نظرًا لأن bash أبسط ، يمكنك ببساطة رميها باستخدام الوسيطة وبناء الجملة $ SYSTEM_ACCESSTOKEN.

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



أو عالميًا في مستودع المتغيرات ، ثم ربطها من المستودع. مريح للغاية.



كمكافأة على ذلك ، إذا كانت المتغيرات سرية للغاية ، فيمكن تخزينها في سحابة Azure في وحدة تخزين تسمى Azure Vault ، يمكن ربط Vault بالمشروع في المكتبة.



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



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


يبدأ الجزء الأكثر إثارة للاهتمام عندما نريد الحصول على بعض القيمة في مرحلة واحدة ونقلها إلى المرحلة التالية.



لم يتم تسليم هذه الوظيفة لنا. لكن أيدينا ليست للملل وتم العثور على حل بمساعدة Google. الحمد لله ، يحتوي 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 واستخدام API يضع قيمة هذا المتغير في stageVar. في الخطوة التالية ، باستخدام بنية متغيرات النظام ، يمكننا النظر إليها.



على سبيل المثال بسيط جدا، ولكن وظيفة تتيح لنا فرص جيدة، في المجموع مع تقريري الأخير المادة ، عندما نتمكن من إنشاء جهاز ظاهري في المرحلة الأولى من التجارب، والقيام ببعض التلاعب مزيد معها، وفي الوقت نفسه عدة. والخطوة الأخيرة هي تدميرها. نحن الآن نتابع الاختبارات الذاتية للمنتج في كل مرة على أجهزة افتراضية جديدة. بالنظر إلى أنهم يعيشون لمدة 10 دقائق ، فإن الأمر يستحق فلسا واحدا.

في المقالة التالية ، إذا لزم الأمر ، سأتحدث عن خطوط أنابيب YAML ، هناك الكثير من الابتكارات المثيرة للاهتمام مؤخرًا.

All Articles