تصميم البنية الأساسية لبرنامج ربط العمليات التجارية
- 11 دقائق
في هذه الوحدة، يمكنك متابعة فريق ويب Tailspin في أثناء تحديد مسار الإصدار الخاص بهم لموقع Space Game على الويب.
عندما تخطط لبنية أساسية لبرنامج ربط العمليات التجارية للإصدار، تبدأ عادة بتحديد المراحل أو الأقسام الرئيسية لهذا المسار. عادة ما يتم تعيين كل مرحلة إلى بيئة. على سبيل المثال، في الوحدة السابقة، كان مسار أندي ومارا الأساسي مرحلة نشر تم تعيينها إلى مثيل Azure App Service.
في هذه الوحدة النمطية، يمكنك ترقية التغييرات من مرحلة إلى أخرى. ضمن كل مرحلة، يمكنك نشر موقع Space Game على البيئة المقترنة بتلك المرحلة.
بعد تحديد المراحل التي تحتاجها، ضع في اعتبارك كيفية ترقية التغييرات من مرحلة إلى أخرى. يمكن لكل مرحلة تحديد معايير النجاح التي يجب استيفاها قبل أن يتمكن البناء من الانتقال إلى المرحلة التالية. توفر Azure Pipelines عدة طرق لمساعدتك في التحكم في كيفية ووقت انتقال التغييرات عبر البنية الأساسية لبرنامج ربط العمليات التجارية. بشكل عام، تستخدم هذه الأساليب لإدارة الإصدار.
في هذا القسم، يمكنك:
- تعرف على الاختلافات بين مراحل البنية الأساسية لبرنامج ربط العمليات التجارية الشائعة، مثل البناءوالتطويروالاختباروالتقسيم المرحلي.
- فهم كيفية استخدام مشغلات النشر اليدوية والمجدولة والمستمرة للتحكم في وقت انتقال البيانات الاصطناعية إلى المرحلة التالية في المسار.
- راجع كيفية إيقاف الموافقة على الإصدار مؤقتا للبنية الأساسية لبرنامج ربط العمليات التجارية حتى يقبل الموافق الإصدار أو يرفضه.
الاجتماع
يتم جمع فريق الويب Tailspin بأكمله معا. في Create a release pipeline in Azure Pipelines، خطط الفريق لمهامهم للنسخة المتكررة الحالية. تتعلق كل مهمة ببناء البنية الأساسية لبرنامج ربط العمليات التجارية للإصدار لموقع Space Game على الويب.
تذكر أن الفريق قرر هذه المهام الخمس لسباقاتهم المتكررة:
- إنشاء مسار متعدد المراحل
- توصيل تطبيق الويب بقاعدة بيانات
- أتمتة اختبارات الجودة
- أتمتة اختبارات الأداء
- تحسين إيقاع الإصدار
يجتمع الفريق للتحدث عن المهمة الأولى، إنشاء مسار متعدد المراحل. بعد أن يحدد الفريق البنية الأساسية لبرنامج ربط العمليات التجارية، يمكنه الانتقال من إثبات المفهوم الأساسي الخاص به إلى مسار الإصدار الذي يتضمن المزيد من المراحل وفحوصات الجودة والموافقات.
تراقب أميتا وتيم أندي ومارا يوضحان مسار الإصدار مرة ثانية. يرون أن البيانات الاصطناعية مبنية ومثبتة على App Service.
ما هي مراحل البنية الأساسية لبرنامج ربط العمليات التجارية التي تحتاجها؟
عندما تريد تنفيذ مسار إصدار، من المهم أولا تحديد المراحل التي تحتاجها. تعتمد المراحل التي تختارها على متطلباتك. دعونا نتابع مع الفريق وهم يقررون مراحلهم.
تيم: حسنا، أفهم فكرة البنية الأساسية لبرنامج ربط العمليات التجارية المؤتمتة. أحب كيف أنه من السهل النشر إلى Azure. ولكن أين نذهب من هذا العرض التوضيحي؟ نحن بحاجة إلى شيء يمكننا استخدامه فعليا لإصداراتنا.
اميتا: يمين! نحن بحاجة إلى إضافة مراحل أخرى. على سبيل المثال، في الوقت الحالي، ليس لدينا مكان لمرحلة الاختبار.
تيم: بالإضافة إلى ذلك، نحن بحاجة إلى مرحلة حيث يمكننا إظهار ميزات جديدة للإدارة. لا يمكنني إرسال أي شيء إلى الإنتاج دون موافقة الإدارة.
أندي: تماما! الآن بعد أن أصبح الأمر سريعا بشأن ما يفعله مسار الإصدار، كيف نجعل هذا المسار يفعل ما نحتاجه؟
مارا: دعونا نرسم متطلباتنا لمساعدتنا في تخطيط خطواتنا التالية. لنبدأ بما لدينا.
تنتقل مارا إلى لوح المعلومات وترسم البنية الأساسية لبرنامج ربط العمليات التجارية الحالية.
مارا: تنشئ مرحلة الإنشاء التعليمات البرمجية المصدر وتنتج حزمة. في حالتنا، هذه الحزمة هي ملف .zip . تقوم مرحلة التوزيع بتثبيت ملف .zip ، وهو موقع ويب Space Game ، على مثيل App Service. ما الذي يفتقد إلى البنية الأساسية لبرنامج ربط العمليات التجارية للإصدار؟
إضافة مرحلة التطوير
اندي: قد أكون متحيزا، ولكن أعتقد أننا بحاجة إلى مرحلة التطوير . يجب أن تكون هذه المرحلة هي المحطة الأولى للبيانات الاصطناعية بعد إنشائها. لا يمكن للمطورين دائما تشغيل الخدمة بأكملها من بيئة التطوير المحلية الخاصة بهم. على سبيل المثال، قد يتطلب نظام التجارة الإلكترونية موقع ويب وقاعدة بيانات للمنتج ونظام دفع. نحن بحاجة إلى مرحلة تتضمن كل ما يحتاجه التطبيق.
في حالتنا، تقرأ ميزة لوحة المتصدرين لموقع Space Game درجات عالية من مصدر خارجي. في الوقت الحالي، يقرأ نتائج وهمية من ملف. من شأن إعداد مرحلة التطوير أن يعطينا بيئة حيث يمكننا دمج تطبيق الويب مع قاعدة بيانات حقيقية. قد لا تزال قاعدة البيانات هذه تحتوي على درجات وهمية، ولكنها تقربنا خطوة واحدة من تطبيقنا النهائي.
مارا: إنني أحبه. لن ندمج مع قاعدة بيانات حقيقية حتى الآن. ولكن في مرحلة التطوير ، يمكننا النشر في بيئة حيث يمكننا إضافة قاعدة بيانات.
تقوم مارا بتحديث رسمها على السبورة البيضاء. تستبدل "Deploy" ب "Dev" لإظهار مرحلة التطوير .
اندي: أنت تحضر نقطة مثيرة للاهتمام. نقوم بإنشاء التطبيق في كل مرة ندفع فيها تغييرا إلى GitHub. هل يعني ذلك أنه يتم ترقية كل بنية إلى مرحلة التطوير بعد انتهائها؟
مارا: يمنحنا البناء باستمرار ملاحظات مهمة حول صحة البناء والاختبار. ولكننا نريد الترقية إلى مرحلة التطوير فقط عندما نقوم بدمج التعليمات البرمجية في بعض الفروع المركزية: إما الفرع الرئيسي أو فرع إصدار آخر. سأحدث الرسم لإظهار هذا المطلب.
مارا: أعتقد أن هذه الترقية سيكون من السهل إنجازها. يمكننا تحديد شرط يتم ترقيته إلى مرحلة التطوير فقط عند حدوث تغييرات على فرع الإصدار.
ما هي الشروط؟
في 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، راجع وثائق التعبيرات.
مارا: باستخدام الشروط، يمكنك التحكم في التغييرات التي تتم ترقيتها إلى أي مراحل. يمكننا إنتاج أداة بناء لأي تغيير للتحقق من صحة بناءنا والتأكد من أنه سليم. عندما نكون مستعدين، يمكننا دمج هذه التغييرات في فرع إصدار وتعزيز هذا الإصدار إلى مرحلة التطوير .
إضافة مرحلة الاختبار
مارا: حتى الآن، لدينا مراحلالإنشاء والتطوير. ماذا يأتي بعد ذلك؟
اميتا: هل يمكننا إضافة مرحلة الاختبار التالية؟ يبدو أن المكان المناسب لي لاختبار أحدث التغييرات.
تضيف مارا مرحلة الاختبار إلى رسمها على لوح المعلومات.
اميتا: أحد مخاوفي هو عدد المرات التي أحتاج فيها إلى اختبار التطبيق. يقوم البريد الإلكتروني بإعلامي كلما قام مارا أو أندي بإجراء تغيير. تحدث التغييرات على مدار اليوم، ولا أعرف متى أقفز. أعتقد أنني أود أن أرى بناء مرة واحدة في اليوم، ربما عندما أدخل إلى المكتب. هل يمكننا فعل ذلك؟
أندي: بالتأكيد. لماذا لا نقوم بالنشر إلى Test أثناء ساعات العمل؟ لنفترض أننا نرسل لك بناء كل يوم في الساعة 3 صباحا.
مارا: هذا يبدو جيدا يمكننا دائما تشغيل العملية يدويا أيضا إذا كنا بحاجة إلى ذلك. على سبيل المثال، يمكننا تشغيله إذا كنا بحاجة إلى التحقق من إصلاح خطأ مهم على الفور.
تقوم مارا بتحديث رسمها لإظهار أن البناء ينتقل من مرحلة التطوير إلى مرحلة الاختبار في الساعة 3 صباحا كل يوم.
ما هي المشغلات؟
اميتا: أشعر بتحسن الآن بعد أن عرفنا كيف تنتقل مرحلة إلى أخرى. ولكن كيف نتحكم في وقت تشغيل المرحلة؟
مارا: في 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، تعمل فقط عند نجاح المرحلة السابقة ومتغير البنية الأساسية لبرنامج ربط العمليات التجارية المضمنة Build.ReasonSchedule يساوي .
سترى مثالا أكثر اكتمالا لاحقا في هذه الوحدة النمطية.
اميتا: أحب هذا. لست مضطرا حتى لالتقاط الإصدار يدويا وتثبيته. إنه جاهز لي.
اندي: وتذكر، إذا أردنا أتمتة المزيد لاحقا، يمكننا ذلك. لا شيء مكتوب بالحجر تتطور البنية الأساسية لبرنامج ربط العمليات التجارية بينما نتحسن ونتعلم.
إضافة مرحلة التقسيم المرحلي
تيم: إنه دوري. أحتاج إلى مرحلة لإجراء المزيد من اختبارات الإجهاد. نحتاج أيضا إلى مرحلة يمكننا فيها العرض التوضيحي للإدارة للحصول على موافقتهم. في الوقت الحالي، يمكننا دمج هذين المتطلبين في مرحلة يمكننا تسميتها بالتقسيم المرحلي.
اندي: حسنا، تيم. وجود بيئة التقسيم المرحلي أو ما قبل الإنتاج أمر مهم. غالبا ما تكون بيئة التقسيم المرحلي هذه هي المحطة الأخيرة قبل وصول الميزة أو إصلاح الأخطاء إلى مستخدمينا.
تضيف مارا التقسيم المرحلي إلى رسمها على لوح المعلومات.
اميتا: نستخدم مشغلا مجدولا لتعزيز التغييرات من مرحلة التطوير إلى مرحلة الاختبار . ولكن كيف يمكننا ترقية التغييرات من الاختبار إلى التقسيم المرحلي؟ هل يجب أن يحدث هذا العرض الترويجي أيضا في جدول زمني؟
مارا: أعتقد أن أفضل طريقة للتعامل مع ذلك ستكون الموافقة على الإصدار. تتيح لك الموافقة على الإصدار ترقية التغيير يدويا من مرحلة إلى أخرى.
اميتا: هذا يبدو بالضبط ما أحتاجه ستمنحني الموافقة على الإصدار الوقت لاختبار أحدث التغييرات قبل تقديم البناء للإدارة. يمكنني الترويج للبناء عندما أكون مستعدا.
تقوم مارا بتحديث رسمها لإظهار أن البناء ينتقل من Test إلى Staging فقط عندما توافق أميتا عليه.
تيم: ويمكنني أن أتخيل أيضا أننا نستخدم الموافقات على الإصدار للترقية من التقسيم المرحلي إلى الإنتاج بعد تسجيلات الإدارة. لا يمكنني التنبؤ بالمدة التي يستغرقها ذلك. بعد تسجيل الخروج، يمكنني الموافقة على الإصدار والترويج له للإنتاج يدويا. ولكن كيف تعمل الموافقات على الإصدار؟
ما هي الموافقات على الإصدار؟
الموافقة على الإصدار هي طريقة لإيقاف البنية الأساسية لبرنامج ربط العمليات التجارية مؤقتا حتى يقبل الموافق الإصدار أو يرفضه. لتعريف سير عمل الإصدار الخاص بك، يمكنك دمج الموافقات والشروط والمشغلات.
تذكر أنه في إنشاء مسار إصدار في 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 وهم يتحركون نحو الخطوات التالية.
مارا: إليك البنية الأساسية لبرنامج ربط العمليات التجارية للإصدار التي نريد بناءها.
تشير مارا إلى لوح المعلومات.
مارا: للتلخيص، خطواتنا هي:
- إنتاج أداة بناء في كل مرة ندفع فيها تغييرا إلى GitHub. تحدث هذه الخطوة في مرحلة الإنشاء .
- ترقية البيانات الاصطناعية للبناء إلى مرحلة التطوير . تحدث هذه الخطوة تلقائيا عند نجاح مرحلة الإنشاء ويكون التغيير في فرع الإصدار.
- ترقية البيانات الاصطناعية للبناء إلى مرحلة الاختبار كل صباح في الساعة 3 صباحا. نستخدم مشغلا مجدولا للترويج للبيانات الاصطناعية للبناء تلقائيا.
- ترقية البيانات الاصطناعية للبناء إلى التقسيم المرحلي بعد اختبارات أميتا والموافقة على البناء. نستخدم الموافقة على الإصدار للترويج للبيانات الاصطناعية للبناء.
بعد موافقة الإدارة على البنية، يمكننا نشر البيانات الاصطناعية للبناء في بيئة إنتاج.
اميتا: هل هذا سيكون من الصعب القيام به؟ يبدو وكأنه الكثير من العمل.
مارا: لا أعتقد أن الأمر سيء جدا كل مرحلة منفصلة عن كل مرحلة أخرى. المراحل منفصلة. كل مرحلة لها مجموعة المهام الخاصة بها. على سبيل المثال، يبقى ما يحدث في مرحلة الاختبار في مرحلة الاختبار .
كل مرحلة توزيع في البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بنا لها أيضا بيئتها الخاصة. على سبيل المثال، عندما ننشر التطبيق إلى Dev أو Test، تكون البيئة هي مثيل App Service.
وأخيرا، نختبر إصدارا واحدا فقط في كل مرة. لا نقوم أبدا بتغيير الإصدارات في منتصف البنية الأساسية لبرنامج ربط العمليات التجارية. نستخدم نفس الإصدار في مرحلة التطوير كما هو الحال في مرحلة التقسيم المرحلي ، ولكل إصدار رقم الإصدار الخاص به. إذا توقف الإصدار في إحدى المراحل، نقوم بإصلاحه وبنائه مرة أخرى برقم إصدار جديد. ثم يمر هذا الإصدار الجديد عبر البنية الأساسية لبرنامج ربط العمليات التجارية من البداية.
بضع كلمات حول الجودة
لقد رأيت للتو الفريق يصمم مسارا يأخذ تطبيقه على طول الطريق من الإنشاء إلى التشغيل المرحلي. الهدف من هذا المسار ليس فقط لجعل حياتهم أسهل. إنها لضمان جودة البرنامج الذي يقدمونه لعملائهم.
كيف يمكنك قياس جودة عملية الإصدار الخاصة بك؟ لا يمكنك قياسه مباشرة. ما يمكنك قياسه هو مدى جودة عمليتك. إذا كنت تغير العملية باستمرار، فقد يكون ذلك مؤشرا على وجود خطأ ما. قد تشير الإصدارات التي تفشل باستمرار في نقطة معينة في البنية الأساسية لبرنامج ربط العمليات التجارية إلى وجود مشكلة في عملية الإصدار.
هل تفشل الإصدارات دائما في يوم أو وقت معين؟ هل تفشل دائما بعد التوزيع إلى بيئة معينة؟ ابحث عن هذه الأنماط وغيرها لمعرفة ما إذا كانت بعض جوانب عملية الإصدار تابعة أو ذات صلة.
هناك طريقة جيدة لتتبع جودة عملية الإصدار الخاصة بك وهي إنشاء مرئيات لجودة الإصدارات. على سبيل المثال، أضف عنصر واجهة مستخدم لوحة معلومات يوضح لك حالة كل إصدار.
عندما تريد قياس جودة الإصدار نفسه، يمكنك إجراء جميع أنواع الفحوصات داخل البنية الأساسية لبرنامج ربط العمليات التجارية. على سبيل المثال، يمكنك تنفيذ أنواع مختلفة من الاختبارات، مثل اختبارات التحميل واختبارات واجهة المستخدم أثناء تشغيل البنية الأساسية لبرنامج ربط العمليات التجارية.
استخدام بوابة الجودة هو أيضا وسيلة رائعة للتحقق من جودة الإصدار الخاص بك. هناك العديد من بوابات الجودة المختلفة. على سبيل المثال، يمكن لبوابات عنصر العمل التحقق من جودة عملية المتطلبات الخاصة بك.
يمكنك أيضا إضافة المزيد من عمليات التحقق من الأمان والتوافق. على سبيل المثال، هل تمتثل لمبدأ العيون الأربع أو هل لديك إمكانية التتبع المناسبة؟
أثناء تقدمك خلال مسار التعلم هذا، ترى العديد من هذه التقنيات موضع التنفيذ.
وأخيرا، عند تصميم عملية إصدار ذات جودة، فكر في نوع الوثائق أو ملاحظات الإصدار التي تحتاج إلى توفيرها للمستخدم. قد يكون الاحتفاظ بالوثائق محدثة أمرا صعبا. قد تحتاج إلى التفكير في استخدام أداة، مثل منشئ ملاحظات إصدار Azure DevOps، وهو تطبيق دالة يحتوي على وظيفة يتم تشغيلها بواسطة HTTP. باستخدام Azure Blob Storage، فإنه ينشئ ملف Markdown كلما تم إنشاء إصدار جديد في Azure DevOps.