إلغاء تأمين متغيرات Azure DevOps للتلقائية

إذا كنت قد قمت بإنشاء أنبوبة Azure DevOps كحل لأنبوبة CI/CD الخاصة بك ، فمن المؤكد أنك واجهت حالات تتطلب إدارة قيم التكوين ديناميكيًا في عمليات البناء والإصدار. سواء كان ذلك توفير إصدار البناء لنص PowerShell ، أو تمرير معلمات ديناميكية لمهام البناء ، أو استخدام سلاسل عبر عمليات البناء والإصدارات ، فإنك بحاجة إلى متغيرات.

إذا كنت قد طرحت على نفسك أسئلة مثل:

• كيف يمكنني استخدام متغيرات أنبوبة بناء Azure DevOps في نص PowerShell؟
• كيف يمكنني مشاركة المتغيرات عبر عمليات البناء والإصدارات؟
• ما هو الاختلاف بين المتغيرات المحددة مسبقًا والمتغيرات المحددة بواسطة المستخدم والمتغيرات السرية؟
• كيف تعمل مجموعات المتغيرات؟

…فأنت محظوظ! في هذه المقالة ، سنجيب على كل هذه الأسئلة وأكثر.

بحلول نهاية هذه المقالة ، ستفهم كيف تعمل متغيرات بناء Azure DevOps في أنابيب Azure!

ما هي متغيرات أنبوبة Azure DevOps؟

قبل أن ننغمس في تفاصيل المتغيرات ، ما هي وكيف تساعدك في بناء وتشغيل أنابيب البناء والإصدار بكفاءة؟

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

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

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

لا تقلق إذا لم تتفهم مفهوم المتغيرات في هذه المرحلة. سيعلمك بقية هذا المقال كل ما تحتاج إلى معرفته.

بيئات المتغيرات

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

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

البيئة الخاصة بالماسورة

عند تعريف أو قراءة المتغيرات في بناء تعريف YAML، يُطلق عليها البيئة الخاصة بالماسورة. على سبيل المثال، يمكنك أن ترى في الأسفل القسم variables المحدد في تعريف بناء YAML والذي يعين متغيرًا يسمى foo إلى bar. في هذا السياق، يتم تعريف المتغير ضمن بيئة الماسورة

variables:
  foo: 'bar'

بيئة النص

يمكنك أيضًا العمل مع المتغيرات من خلال الكود المحدد في تعريف YAML نفسه أو في النصوص. عندما لا تكون لديك نص موجود بالفعل، يمكنك تعريف وقراءة المتغيرات ضمن تعريف YAML كما هو موضح أدناه. ستتعلم بناء الجملة وكيفية التعامل مع هذه المتغيرات في هذا السياق في وقت لاحق.

steps:
 - bash: ## تعيين المتغيرات واسترجاعها هنا

بإمكانك أيضًا البقاء ضمن بيئة النص عن طريق إضافة نفس بناء الجملة هذا إلى نص Bash وتنفيذه. هذا هو نفس المفهوم العام.

متغيرات البيئة

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

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

variables:
  foo: 'bar'

• دفعة – %FOO%
• PowerShell – $env:FOO
• سكريبت باش – $FOO

مراحل “تنفيذ الأنابيب”

عندما تعمل أنبوبة ، فإنها لا تعمل فقط. مثل المراحل التي تحتويها ، تخضع الأنبوبة أيضًا لمراحل مختلفة عند تنفيذها. بسبب عدم وجود مصطلح رسمي في وثائق Microsoft ، أنا أطلق عليه “مراحل التنفيذ”.

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

وقت الانتظار

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

ستتمكن من تحديد المتغيرات في وقت الانتظار عند تشغيل الأنبوبة في الانتظار مثلما هو موضح أدناه. عند إضافة هذا المتغير ، سيتم جعله متغيرًا عامًا في الأنبوبة ويمكن استبداله بنفس اسم المتغير في ملف YAML.

تجميع

أخيرًا، عندما يقوم خط الأنابيب بمعالجة ملف YAML وينتقل إلى الخطوات التي تتطلب تنفيذ سكربت، فإن خط الأنابيب في “مرحلة” التجميع. في هذا السياق، يقوم الوكيل بتنفيذ الكود المحدد في خطوات السكربت.

زمن التشغيل

المرحلة التالية هي زمن التشغيل. في هذه المرحلة، يتم معالجة كل مرحلة ووظيفة وخطوة في ملف YAML ولكنها لا تقوم بتشغيل أي سكربتات.

توسيع المتغيرات

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

سيظهر هذا المفهوم لتوسيع المتغيرات والتجميع مقابل زمن التشغيل كثيرًا عند فهم بناء جملة المتغيرات.

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

يمكنك رؤية مثال أدناه. يرتبط مفهوم هذه المراحل بشكل وثيق ببيئات المتغيرات.

steps:
  # يعين FOO قيمة "some value" في السكربت والسكربتات التالية
  - bash: |
      FOO="runtime value"
      echo "##vso[task.setvariable variable=FOO]$FOO"

  # باستخدام صيغة $() أثناء "زمن التجميع"، يقوم خط الأنابيب بتوسيع المتغير
  - bash: |
      echo "$(FOO)"

  # باستخدام متغير بيئة في سياق السكربت في "زمن التشغيل"، يقوم باش بتوسيع المتغير
  - bash: |
      echo "$FOO"

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

jobs:
- job: build
  variables:
  - foo: bar 
  steps:
    - bash: |
        echo $(foo)            # This will be bar
        echo '##vso[task.setvariable variable=foo]baz'
        echo $(foo)            # This will also be bar, $(foo) expands before the step
    - bash: echo $(foo)        # سيكون هذا السطر baz. يتم توسيع المتغير قبل بدء الخطوة

بناء تركيبة المتغيرات

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

المتغيرات في السلسلة النصية

يتم الإشارة إلى المتغيرات في تعاريف بناء YAML ويمكن الإشارة إليها باستخدام ثلاثة طرق متباينة في الصياغة – الماكرو وتعبير القالب وتعبير التشغيل.

صياغة الماكرو

أكثر صياغة ستجدها شيوعًا هي صياغة الماكرو. تُشير صياغة الماكرو إلى قيمة لمتغير بتنسيق $(foo). الأقواس تمثل تعبيرًا يتم تقييمه أثناء التشغيل.

عندما يقوم Azure Pipelines بمعالجة متغير معرف كتعبير ماكرو، سيقوم بتعويض التعبير بمحتويات المتغير. عند تعريف المتغيرات بصيغة الماكرو، تتبع نمطًا يكون عبارة عن <اسم المتغير>: $(<قيمة المتغير>) مثل foo: $(bar).

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

صياغة تعبير القالب

نوع آخر من بناء الجمل المتغيرة يسمى تعبير القالب. يتم تحديد متغيرات الأنابيب بهذه الطريقة في شكل ${{ variables.foo }} : ${{ variables.bar }}. كما ترون، فإنها أكثر تفصيلاً قليلاً من بناء الجمل العامة.

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

تتم معالجة متغيرات تعبير القالب في وقت الترجمة ومن ثم يتم استبدالها (إذا تم تحديدها) في وقت التنفيذ.

نحو التعبير أثناء التنفيذ

كما هو الحال في نوع النحو، يتم توسيع متغيرات تعبير التشغيل المقترحة فقط في وقت التنفيذ. يتم تمثيل هذه الأنواع من المتغيرات بتنسيق $[variables.foo]. مثل متغيرات نحو تعبير القالب، فإن هذه الأنواع من المتغيرات ستعيد سلسلة فارغة إذا لم تتم استبدالها.

مثل نحو بناء الجمل العامة، يتطلب نحو تعبير التشغيل تحديد اسم المتغير في الجانب الأيسر من التعريف مثل foo: $[variables.bar].

متغيرات النص البرمجي

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

أوامر تسجيل الدخول

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

وسيلة لتعيين متغير يسمى foo بقيمة bar باستخدام بناء جملة أمر التسجيل ستبدو على النحو التالي.

"##vso[task.setvariable variable=foo;]bar"

I could not find a way to get the value of variables using logging commands. If this exists, let me know!

متغيرات البيئة

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

على سبيل المثال، إذا تم تعريف متغير الأنابيب المسمى [foo.bar](<http://foo.bar>)، يمكنك الإشارة إلى هذا المتغير باستخدام طريقة الإشارة الأصلية لمتغير البيئة في النص البرمجي مثل $env:FOO_BAR في PowerShell أو $FOO_BAR في Bash.

لقد تناولنا المزيد حول متغيرات البيئة في الجزء بيئة النص البرمجي أعلاه.

نطاق المتغير

A pipeline has various stages, tasks and jobs running. Many areas have predefined variable scopes. A scope is namespace where when a variable is defined, its value can be referenced.

هناك ثلاثة نطاقات متغيرات مختلفة تتبع تسلسلًا هرميًا. يتم تعريف المتغيرات على مستوى:

• المستوى الجذري الذي يجعل المتغيرات متاحة لجميع الوظائف في الأنبوبة
• مستوى المرحلة الذي يجعل المتغيرات متاحة لمرحلة محددة
• مستوى الوظيفة الذي يجعل المتغيرات متاحة لوظيفة محددة

المتغيرات المعرفة على المستويات “الأدنى” مثل الوظيفة ستتجاوز نفس المتغير المعرف على المستوى المرحلة والجذر، على سبيل المثال. المتغيرات المعرفة على مستوى المرحلة ستتجاوز المتغيرات المعرفة على مستوى “الجذر” ولكنها ستتجاوزها بدورها المتغيرات المعرفة على مستوى الوظيفة.

أدناه يمكنك رؤية مثال على تعريف بناء YAML باستخدام كل نطاق.

variables:
  global_variable: value  # هذا هو متغير عالمي متاح لجميع المراحل والوظائف

stages:
- stage: Build
  variables:
    stage_variable1: value3 # متاح في مرحلة البناء وجميع الوظائف
  jobs:
  - job: BuildJob
    variables:
      job_variable1: value1    # هذا متاح فقط في BuildJob
    steps:
    - bash: echo $(stage_variable1) ## يعمل
    - bash: echo $(global_variable) ## يعمل
    - bash: echo $(job_variable1) ## يعمل

أولوية المتغيرات

في بعض الحالات قد ترى أن المتغير بنفس الاسم يتم تعيينه في نطاقات مختلفة. عند حدوث ذلك، سيتم استبدال قيمة هذا المتغير وفقًا لتسلسل محدد يعطي الأولوية لـ “الإجراء” الأقرب.

أدناه ستجد الترتيب الذي سيتم به استدعاء المتغيرات بدءًا من المتغير المعين داخل وظيفة. وهذا الأمر يتمتع بأولوية أكبر.

1. متغير معين على مستوى الوظيفة (معين في ملف YAML)
2. متغير معين على مستوى المرحلة (معين في ملف YAML)
3. متغير معين على مستوى الخط الأساسي للأنابيب (عام) (معين في ملف YAML)
4. متغير معين في وقت الانتظار
5. متغير الأنابيب المعين في واجهة المستخدم لإعدادات الأنابيب

على سبيل المثال، دعنا نلقي نظرة على تعريف YAML أدناه. في هذا المثال، يتم تعيين نفس المتغير في العديد من المناطق المختلفة ولكن في النهاية ينتهي بالقيمة المحددة في الوظيفة. مع كل إجراء، يتم استبدال قيمة المتغير عندما ينتقل خط الأنابيب إلى الوظيفة.

variables:
  foo: 'global variable'

stages:
- stage: build
  variables:
   - name: foo
     value: 'defined at stage level'

  jobs:
  - job: compile
    variables:
    - name: foo
      value: 'defined at job level'
    steps:
      - bash: echo $(foo) # ستكون هذه 'محددة على مستوى الوظيفة'

أنواع المتغيرات

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

هناك أربعة أنواع عامة من المتغيرات – المتغيرات المحددة مسبقًا أو المتغيرات النظامية، والمتغيرات المعرفة بواسطة المستخدم، والمتغيرات الناتجة، والمتغيرات السرية. دعنا نغطي كل من هذه الأنواع ونفهم كل نوع من المتغيرات.

المتغيرات المحددة مسبقًا

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

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

• الوكيل
• البناء
• خط الأنابيب
• وظيفة النشر
• النظام

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

المتغيرات المحددة بواسطة المستخدم

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

لا يمكنك تعريف متغيرات تبدأ بكلمة endpoint، input، secret، أو securefile. هذه التسميات غير متاحة للاستخدام لأنها محجوزة للاستخدام النظامي وغير حساسة للحالة الأحرف.

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

المتغيرات الناتجة

A build definition contains one or more tasks. Sometimes a task sends a variable out to be made available to downstream steps and jobs within the same stage. These types of variables are called output variables.

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

ملاحظة: تتم إقامة المتغيرات المخرجة لمرحلة محددة. لا تتوقع توافر متغير مخرج في مرحلة “بناء” وأيضًا في مرحلة “اختبار” الخاصة بك، على سبيل المثال.

المتغيرات السرية

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

A secret variable is a standard variable that’s encrypted. Secret variables typically contain sensitive information like API keys, passwords, etc. These variables are encrypted at rest with a 2048-bit RSA key and are available on the agent for all tasks and scripts to use.

– لا تقم بتحديد المتغيرات السرية داخل ملفات YAML الخاصة بك
– لا تعيد الكشف عن الأسرار كمتغيرات مخرجة أو معلومات تسجيل

يجب تعريف المتغيرات السرية في محرر الأنابيب. يتم إقامة المتغيرات السرية على مستوى عالمي مما يجعلها متاحة للمهام في الأنبوبة.

يتم إخفاء القيم السرية في السجلات ولكن ليس بشكل كامل. لذلك من المهم عدم تضمينها في ملف YAML. يجب أيضًا أن تعلم ألا تتضمن أي بيانات “منظمة” كسرية. إذا كان، على سبيل المثال، { "foo": "bar" } تم تعيينها كسرية، فإن bar لن يتم إخفاءه من السجلات.

الأسرار لا يتم فك تشفيرها وربطها تلقائيًا بمتغيرات البيئة. إذا قمت بتعريف متغير سري، فلا تتوقع توافره عبر $env:FOO في نص PowerShell، على سبيل المثال.

مجموعات المتغيرات

أخيرًا، نصل إلى مجموعات المتغيرات. مجموعات المتغيرات، كما قد تتوقع، هي “مجموعات” من المتغيرات التي يمكن الإشارة إليها كواحدة. الغرض الأساسي من مجموعة المتغيرات هو تخزين القيم التي ترغب في جعلها متاحة عبر عدة أنابيب.

على عكس المتغيرات، فإن مجموعات المتغيرات ليست محددة في ملف YAML. بدلاً من ذلك، يتم تعريفها في صفحة المكتبة تحت الأنابيب في واجهة المستخدم.

استخدم مجموعة متغيرات لتخزين القيم التي ترغب في التحكم فيها وجعلها متاحة عبر العديد من الأنابيب. يمكنك أيضًا استخدام مجموعات المتغيرات لتخزين الأسرار والقيم الأخرى التي قد تحتاج إلى تمريرها إلى أنبوب YAML. تتم تعريف وإدارة مجموعات المتغيرات في صفحة المكتبة تحت الأنابيب كما هو موضح أدناه.

بمجرد تعريف مجموعة المتغيرات في مكتبة الأنابيب، يمكنك ثم جعل تلك المجموعة متاحة في ملف YAML باستخدام الصيغة أدناه.

variables:
- group: group1

عادةً ما لا تكون مجموعات المتغيرات متاحة لجميع الأنابيب بشكل افتراضي. يتم توفير هذا الإعداد عند إنشاء المجموعة. يجب أن تكون الأنابيب مصرح لها باستخدام مجموعة متغيرات.

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

على سبيل المثال، إذا قمت بتعريف مجموعة متغيرات تسمى group1 تحتوي على متغير يسمى foo، يمكنك الإشارة إلى المتغير foo مثل أي متغير آخر مثل $(foo).

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

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

ملخص

يجب أن تكون الآن لديك معرفة قوية بمتغيرات أنابيب Azure. لقد تعلمت تقريبًا كل المفاهيم المتعلقة بالمتغيرات في هذا المقال! الآن انطلق، وطبق هذه المعرفة على أنابيب Azure DevOps الخاصة بك وأتمت كل الأشياء!