اختبار القالب المحول وتوزيعه

مكتمل

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

Diagram that shows the test and deploy phases of the recommended workflow for migrating Azure resources to Bicep.

التركيز الرئيسي لهذين المرحلتين هو اختبار ملف Bicep الخاص بك باستخدام الأدوات المتوفرة ثم نشر الملف الخاص بك إلى بيئة Azure الخاصة بك.

مرحلة الاختبار

أهداف مرحلة الاختبار لترحيل مواردك إلى Bicep هي التحقق من تكامل القوالب التي تم ترحيلها والقيام بنشر اختبار.

تتكون مرحلة الاختبار من خطوتين تكملهما بهذا الترتيب:

  1. تشغيل عملية «ماذا لو» لتوزيع قالب ARM.
  2. توزيع الاختبار.

Diagram that shows a Bicep file being tested and deployed to Azure.

توفر عملية what-if معاينة للتغييرات التي سيتم إجراؤها عند نشر ملف Bicep. يمكنك استخدام توزيع اختبار لمقارنة الموارد الأصلية بالموارد المنشورة حديثا.

ما المقصود بعملية «ماذا لو» لتوزيع قالب ARM؟

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

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

إشعار

قد تسرد عملية what-if بعض خصائص المورد كما حذفت في حين أنها في الواقع لن تتغير. وتتمثل هذه النتائج في الضوضاء.

نشر الاختبار

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

تلميح

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

مرحلة التوزيع

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

تتكون مرحلة التوزيع من أربع خطوات، والتي تكملها بهذا الترتيب:

  1. إعداد خطة للعودة إلى الحالة السابقة.
  2. تشغيل عملية «ماذا لو» مقابل التشغيل.
  3. انشر ملف Bicep يدويا.
  4. قم بإجراء اختبارات قبول البناء.

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

Diagram that shows a Bicep file being deployed to Azure.

إعداد خطة للعودة إلى الحالة السابقة

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

تشغيل عملية «ماذا لو» مقابل التشغيل

لقد قمت بالفعل بتشغيل عملية «ماذا لو» مقابل بيئاتك الأخرى للتحقق من أن ملف Bicep الجديد لن يتسبب في أي تغييرات فاصلة. شغل عملية what-if قبل توزيع ملف Bicep الأخير للإنتاج ضد بيئة الإنتاج الخاصة بك. تأكد من استخدام قيم مقياس الإنتاج وضع في اعتبارك توثيق النتائج.

التوزيع يدوياً

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

إجراء اختبارات التحقق من البناء

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