السابق

التالي

تصميم استراتيجية سير عمل وتعيين الإصدار

مكتمل

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

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

أرقام الإصدارات

في وحدات تدريب Microsoft Learn السابقة، تعرفت على أهمية تعيين الإصدار لمواصفات القالب ووحدات Bicep النمطية. يمكنك الاختيار من بين العديد من نُهج تعيين الإصدار المختلفة. في العديد من الحالات، يكون من الممارسات الجيدة استخدام نظام تعيين إصدار متعدد الأجزاء. يتكون نظام تعيين الإصدار متعدد الأجزاء من إصدار رئيسي وإصدار ثانوي وعدد مراجعة، على غرار المثال التالي:

في المثال السابق، الإصدار الرئيسي هو 1، والإصدار الثانوي هو 4، وعدد المراجعة هو 106.

تنقل التغييرات في أجزاء مختلفة من أرقام الإصدارات معلومات مهمة عن أنواع التغييرات في التعليمات البرمجية:

• كلما أجريت تغييراً معطلاً للعمل، يجب عليك زيادة رقم الإصدار الرئيسي. على سبيل المثال، افترض أنك أضفت معلمة إلزامية جديدة أو أنك أزلت معلمة من ملف Bicep لديك. هذه أمثلة على التغييرات المعطلة للعمل، لأن Bicep يتطلب تحديد معلمات إلزامية في وقت التوزيع ولا يسمح بتعيين قيم للمعلمات غير الموجودة. لذلك، ستحدِّث رقم الإصدار الرئيسي.

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

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

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

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

إشعار

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

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

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

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

الإصدارات ومهام سير العمل

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

يتمثل أحد النُهج في تخزين ملف بيانات التعريف باستخدام تعليمة Bicep البرمجية خاصتك، كما هو موضح في الرسم البياني التالي:

كلما حدثت تعليمات Bicep البرمجية خاصتك، يمكنك تحديث معلومات الإصدار في ملف بيانات التعريف المقابلة. تأكد من تحديد التغييرات المعطلة للعمل وغير المعطلة للعمل تحديداً صحيحاً حتى تتمكن من زيادة أرقام الإصدارات على نحوٍ صحيحٍ.

تلميح

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

سترى كيف يمكنك استخدام ملف بيانات التعريف في التمرين التالي.

كم عدد حالات سير العمل؟

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

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

على سبيل المثال، افترض أن لديك بنية ملف مشابهة لتلك الموضحة سابقاً. يمكنك تكوين ثلاث مهام سير عمل منفصلة، واحدة لكل ملف Bicep. حدد كل علامة تبويب لرؤية تعريف سير العمل المقابل وعامل تصفية المسار خاصته:

module-1

name: 'publish-module-1'

on:
  push:
    branches:
      - main
    paths:
      - 'module-1/**'

jobs:
  publish:
    uses: ./.github/workflows/publish-module.yml
    with:
      path: 'module-1/main.bicep'

module-2

name: 'publish-module-2'

on:
  push:
    branches:
      - main
    paths:
      - 'module-2/**'

jobs:
  publish:
    uses: ./.github/workflows/publish-module.yml
    with:
      path: 'module-2/main.bicep'

template-spec-1

name: 'publish-template-spec-1'

on:
  push:
    branches:
      - main
    paths:
      - 'template-spec-1/**'

jobs:
  publish:
    uses: ./.github/workflows/publish-template-spec.yml
    with:
      path: 'template-spec-1/main.bicep'

لنفترض أنك غيرت ملف module-2/main.bicepفقط. يتم تشغيل سير العمل الخاص بالوحدة 2 فقط. ولكن إذا غيرت ملفات متعددة في التثبيت نفسه، يشغَّل كل سير عمل معني.

إشعار

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

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

بيئات لتعليمات Bicep البرمجية القابلة لإعادة الاستخدام

عندما توزع إلى Azure باستخدام Bicep، من الشائع استخدام بيئات متعددة لمساعدتك في التحقق من صحة التعليمات البرمجية واختبارها قبل نشرها في بيئة التشغيل. في وحدات تدريب Microsoft Learn السابقة، تعلمت كيفية العمل مع بيئات متعددة من سير عمل التوزيع.

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

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

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

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

• سجل وحدة تطوير عندما توزع في بيئة الاختبار المعزولة.
• سجل إنتاج عندما توزع في بيئات أخرى.

إشعار

لا تنطبق الأسماء المستعارة عندما تباشر بالنشر. وهي تعمل فقط عند استخدام مواصفات القالب أو الوحدات داخل ملف Bicep.

متابعة