السابق

التالي

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

مكتمل

عندما تبدأ في نشر تعليمة 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.

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

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

module-1

trigger:
  batch: true
  branches:
    include:
    - main
  paths:
    include:
    - 'module-1/**'

stages:
- template: pipeline-templates/publish-module.yml
  parameters:
    path: 'module-1/main.bicep'

module-2

trigger:
  batch: true
  branches:
    include:
    - main
  paths:
    include:
    - 'module-2/**'

stages:
- template: pipeline-templates/publish-module.yml
  parameters:
    path: 'module-2/main.bicep'

template-spec-1

trigger:
  batch: true
  branches:
    include:
    - main
  paths:
    include:
    - 'template-spec-1/**'

stages:
- template: pipeline-templates/publish-template-spec.yml
  parameters:
    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.

متابعة