تصميم التدفق

  • 11 دقائق

في هذه الوحدة، يمكنك متابعة فريق ويب Tailspin في أثناء تحديد مسار الإصدار الخاص بهم لموقع Space Game على الويب.

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

في هذه الوحدة النمطية، يمكنك ترقية التغييرات من مرحلة إلى أخرى. ضمن كل مرحلة، يمكنك نشر موقع Space Game على البيئة المقترنة بتلك المرحلة.

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

في هذا القسم، يمكنك:

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

الاجتماع

يتم جمع فريق الويب Tailspin بأكمله معا. في Create a release pipeline with Azure Pipelines، خطط الفريق لمهامهم للسباق المتكرر الحالي. تتعلق كل مهمة ببناء البنية الأساسية لبرنامج ربط العمليات التجارية للإصدار لموقع Space Game على الويب.

تذكر أن الفريق قرر هذه المهام الخمس لسباقاتهم المتكررة:

  • إنشاء مسار متعدد المراحل.
  • الاتصال تطبيق الويب إلى قاعدة بيانات.
  • أتمتة اختبارات الجودة.
  • أتمتة اختبارات الأداء.
  • تحسين إيقاع الإصدار.

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

تراقب أميتا وتيم أندي ومارا يوضحان مسار الإصدار مرة ثانية. يرون أن البيانات الاصطناعية مبنية ومثبتة على App Service.

ما هي مراحل البنية الأساسية لبرنامج ربط العمليات التجارية التي تحتاجها؟

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

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

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

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

أندي: بالتأكيد! الآن بعد أن أصبح الأمر سريعا بشأن ما يفعله مسار الإصدار، كيف نجعل هذا المسار يفعل ما نحتاجه؟

مارا: دعونا نرسم متطلباتنا لمساعدتنا في تخطيط خطواتنا التالية. لنبدأ بما لدينا.

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

Diagram of the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

مارا: تنشئ مرحلة الإنشاء التعليمات البرمجية المصدر وتنتج حزمة. في حالتنا، هذه الحزمة هي ملف .zip . تقوم مرحلة التوزيع بتثبيت ملف .zip ، وهو موقع ويب Space Game ، على مثيل App Service. ما الذي يفتقد إلى البنية الأساسية لبرنامج ربط العمليات التجارية للإصدار؟

إضافة مرحلة التطوير

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

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

مارا: أحب ذلك. لن ندمج مع قاعدة بيانات حقيقية حتى الآن. ولكن في مرحلة التطوير ، يمكننا النشر في بيئة حيث يمكننا إضافة قاعدة بيانات.

تقوم مارا بتحديث رسمها على السبورة البيضاء. تستبدل "Deploy" ب "Dev" لإظهار مرحلة التطوير .

Diagram that shows the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

أندي: أنت تحضر نقطة مثيرة للاهتمام. نقوم بإنشاء التطبيق في كل مرة ندفع فيها تغييرا إلى GitHub. هل يعني ذلك أنه يتم ترقية كل بنية إلى مرحلة التطوير بعد انتهائها؟

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

Diagram that shows whiteboard illustrating build and dev stages. A condition promotes to the Dev stage only when changes happen on a release branch.

مارا: أعتقد أن هذه الترقية ستكون سهلة الإنجاز. يمكننا تحديد شرط يتم ترقيته إلى مرحلة التطوير فقط عند حدوث تغييرات على فرع الإصدار.

ما هي الشروط؟

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

تذكر أن بعض الشروط التي يمكنك تحديدها هي:

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

وفيما يلي مثال أساسي:

steps:
  - script: echo Hello!
    condition: always()

يؤدي الشرط always() إلى طباعة هذه المهمة "Hello!" دون قيد أو شرط، حتى لو فشلت المهام السابقة.

يتم استخدام هذا الشرط إذا لم تحدد شرطا:

condition: succeeded()

succeeded() تتحقق الدالة المضمنة من نجاح المهمة السابقة. إذا فشلت المهمة السابقة، فسيتم تخطي هذه المهمة والمهام اللاحقة التي تستخدم نفس الشرط.

هنا تريد إنشاء شرط يحدد:

  • نجحت المهمة السابقة.
  • اسم فرع Git الحالي هو الإصدار.

لإنشاء هذا الشرط، يمكنك استخدام الدالة المضمنة and() . تتحقق هذه الدالة مما إذا كان كل شرط من شروطها صحيحا. إذا لم يكن أي شرط صحيحا، يفشل الشرط الكلي.

للحصول على اسم الفرع الحالي، يمكنك استخدام المتغير المضمن Build.SourceBranchName . يمكنك الوصول إلى المتغيرات ضمن شرط بعدة طرق. هنا يمكنك استخدام بناء الجملة variables[] .

لاختبار قيمة متغير، يمكنك استخدام الدالة المضمنة eq() . تتحقق هذه الدالة مما إذا كانت وسيطاتها متساوية.

مع وضع ذلك في الاعتبار، يمكنك تطبيق هذا الشرط لتشغيل مرحلة التطوير فقط عندما يكون اسم الفرع الحالي هو "release":

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

يتحقق الشرط الأول في الدالة and() ما إذا كانت المهمة السابقة قد نجحت أم لا. يتحقق الشرط الثاني ما إذا كان اسم الفرع الحالي يساوي الإصدار.

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

إشعار

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

في الوحدة التالية، عند إعداد مرحلة التطوير ، يمكنك العمل مع مثال أكثر اكتمالا.

للحصول على وصف أكثر اكتمالا للشروط في Azure Pipelines، راجع وثائق التعبيرات.

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

إضافة مرحلة الاختبار

مارا: حتى الآن، لدينا مراحل البناء والتطوير. ماذا يأتي بعد ذلك؟

أميتا: هل يمكننا إضافة مرحلة الاختبار التالية؟ يبدو أن المكان المناسب لي لاختبار أحدث التغييرات.

تضيف مارا مرحلة الاختبار إلى رسمها على لوح المعلومات.

Diagram that shows the whiteboard illustrating build, dev and test stages. The Test stage deploys the build to Azure App Service.

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

أندي: بالتأكيد. لماذا لا نقوم بالنشر إلى Test أثناء ساعات العمل؟ لنفترض أننا نرسل لك بناء كل يوم في الساعة 3 صباحا.

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

تقوم Mara بتحديث رسمها لإظهار أن البنية تنتقل من مرحلة التطوير إلى مرحلة الاختبار في الساعة 3 صباحاً كل صباح.

Diagram that shows the whiteboard showing Build, Dev, and Test stages. The schedule promotes the change from Dev to Test at 3 A.M. each morning.

ما هي المشغلات؟

أميتا: أشعر بتحسن الآن بعد أن عرفنا كيف تنتقل مرحلة إلى أخرى. ولكن كيف نتحكم في وقت تشغيل المرحلة؟

مارا: في Azure Pipelines، يمكننا استخدام المشغلات. يحدد المشغل وقت تشغيل المرحلة. توفر Azure Pipelines بعض أنواع المشغلات. فيما يلي خياراتنا:

  • مشغل التكامل المستمر (CI)
  • مشغل طلب السحب (PR)
  • مشغل مجدول
  • مشغل إكمال الإنشاء

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

ما هي المشغلات المجدولة؟

يستخدم المشغل المجدول بناء جملة cron للتسبب في تشغيل بنية وفقا لجدول زمني محدد.

في أنظمة Unix وLinux، يعتبر cron وسيلة شائعة لجدولة تشغيل الوظائف في فترة زمنية محددة أو في وقت معين. في Azure Pipelines، تستخدم المشغلات المجدولة بناء جملة cron لتحديد وقت تشغيل المرحلة.

يتضمن تعبير cron حقولا تطابق معلمات وقت معينة. فيما يلي الحقول:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

على سبيل المثال، يوصف تعبير cron في تمام "الساعة 3 صباحاً كل صباح": 0 3 * * *

يمكن أن يتضمن تعبير cron أحرفا خاصة لتحديد قائمة قيم أو نطاق من القيم. في هذا المثال، تطابق العلامة النجمية (*) كافة قيم حقول الأيام والأشهر وأيام الأسبوع.

بطريقة أخرى، يقرأ تعبير cron هذا على النحو التالي:

  • في الدقيقة 0،
  • في الساعة الثالثة
  • في أي يوم من الشهر
  • في أي شهر،
  • في أي يوم من أيام الأسبوع،
  • تشغيل المهمة

لتحديد الساعة 3 صباحاً فقط في أيام الاثنين إلى الجمعة، يمكنك استخدام هذا التعبير: 0 3 * * 1-5

إشعار

المنطقة الزمنية لجداول cron هي التوقيت العالمي المنسق (UTC)، لذلك في هذا المثال؛ 3 صباحاً تشير إلى الساعة 3 صباحاً بالتوقيت العالمي المنسق. في الممارسة العملية، قد ترغب في ضبط الوقت في جدول cron الخاص بك بالنسبة إلى UTC بحيث يتم تشغيل المسار في الوقت المتوقع لك ولفريقك.

لإعداد مشغل مجدول في Azure Pipelines، تحتاج إلى schedules قسم في ملف YAML. إليك مثال:

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

في هذا schedules القسم:

  • cron يحدد تعبير cron.
  • branches يحدد النشر فقط من release الفرع.
  • always يحدد ما إذا كان سيتم تشغيل النشر بشكل غير مشروط (true)، أو فقط عند release تغيير الفرع منذ التشغيل الأخير (false). هنا، يمكنك تحديد false لأنك تحتاج إلى النشر فقط عند release تغيير الفرع منذ التشغيل الأخير.

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

إليك مثال:

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

هذه المرحلة، Test، تعمل فقط عند نجاح المرحلة السابقة ومتغير البنية الأساسية لبرنامج ربط العمليات التجارية المضمنة ScheduleBuild.Reason يساوي .

سترى مثالا أكثر اكتمالا لاحقا في هذه الوحدة النمطية.

أميتا: أحب هذا. لست مضطرا حتى لالتقاط الإصدار يدويا وتثبيته. إنه جاهز لي.

أندي: وتذكر، إذا أردنا أتمتة المزيد لاحقا، يمكننا ذلك. لا شيء مكتوب بالحجر تتطور البنية الأساسية لبرنامج ربط العمليات التجارية بينما نتحسن ونتعلم.

إضافة مرحلة التقسيم المرحلي

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

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

تضيف مارا التقسيم المرحلي إلى رسمها على لوح المعلومات.

Diagram where the whiteboard is showing the Build, Dev, Test, and Staging stages. The Staging stage deploys the build to Azure App Service.

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

مارا: أعتقد أن أفضل طريقة للتعامل مع ذلك هي الموافقة على الإصدار. تتيح لك الموافقة على الإصدار ترقية التغيير يدويا من مرحلة إلى أخرى.

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

تقوم مارا بتحديث رسمها لإظهار أن البناء ينتقل من Test إلى Staging فقط عندما توافق أميتا عليه.

Diagram where the whiteboard shows the Build, Dev, Test, and Staging stages. Changes move from Test to Staging only after approval.

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

ما هي الموافقات على الإصدار؟

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

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

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

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

لاحقا في هذه الوحدة النمطية ، يمكنك تعريف بيئة التقسيم المرحلي، وتعيين نفسك كمعتمد للترويج لتطبيق ويب Space Game من مرحلة الاختبار إلى التقسيم المرحلي.

أتمتة أقل أو بقدر ما تحتاج

تمنحك Azure Pipelines المرونة لأتمتة بعض المراحل مع التحكم يدويا في المراحل غير الجاهزة للأتمتة.

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

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

تيم: يبدو رائعا. دعونا نذهب مع هذه الخطة في الوقت الحالي، ونرى كيف يمكننا تسريع النظام في وقت لاحق.

أميتا: بالحديث عن خطتنا، هل يمكننا تلخيص خطواتنا التالية؟

الخطة

دعونا نراجع خطة فريق Tailspin وهم يتحركون نحو الخطوات التالية.

مارا: إليك مسار الإصدار الذي نريد بناءه.

تشير مارا إلى لوح المعلومات.

Diagram of the final whiteboard showing the Build, Dev, Test, and Staging stages.

مارا: للتلخيص، خطواتنا هي:

  1. إنتاج أداة بناء في كل مرة ندفع فيها تغييرا إلى GitHub. تحدث هذه الخطوة في مرحلة الإنشاء.
  2. ترقية البيانات الاصطناعية للبناء إلى مرحلة التطوير . تحدث هذه الخطوة تلقائيا عند نجاح مرحلة الإنشاء ويكون التغيير في فرع الإصدار.
  3. قم بترقية أداة الإنشاء إلى مرحلة الاختبار كل صباح في الساعة 3 صباحاً. نستخدم مشغلاً مجدولاً للترويج لأداة الإنشاء تلقائياً.
  4. ترقية البيانات الاصطناعية للبناء إلى التقسيم المرحلي بعد اختبارات أميتا والموافقة على البناء. نستخدم الموافقة على الإصدار للترويج للبيانات الاصطناعية للبناء.

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

أميتا: هل سيكون من الصعب القيام بذلك؟ يبدو وكأنه الكثير من العمل.

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

كل مرحلة توزيع في البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بنا لها أيضا بيئتها الخاصة. على سبيل المثال، عندما ننشر التطبيق إلى Dev أو Test، تكون البيئة هي مثيل App Service.

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

بضع كلمات حول الجودة

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

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

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

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

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

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

أثناء تقدمك خلال مسار التعلم هذا، ترى العديد من هذه التقنيات موضع التنفيذ.

وأخيرا، عند تصميم عملية إصدار ذات جودة، فكر في نوع الوثائق أو ملاحظات الإصدار التي تحتاج إلى توفيرها للمستخدم. قد يكون الاحتفاظ بالوثائق محدثة أمرا صعبا. قد تحتاج إلى التفكير في استخدام أداة، مثل منشئ ملاحظات إصدار Azure DevOps. المُنشئ هو تطبيق الوظائف الذي يحتوي على وظيفة يتم تشغيلها بواسطة HTTP. إنه ينشئ ملف Markdown كلما تم إنشاء إصدار جديد في Azure DevOps باستخدام Azure Blob Storage.

‏‫اختبر معلوماتك

1.

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

2.

ما هي أفضل طريقة لإيقاف البنية الأساسية لبرنامج ربط العمليات التجارية مؤقتا حتى يقوم الموافق بتسجيل الخروج عند إجراء تغيير؟

3.

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