التخطيط لعمليات الإنشاء والاختبار والتحكم في الجودة
تستعرض هذه الوحدة عمليات التطوير المستخدمة لإدارة عمليات الإنشاء والاختبار ومراقبة الجودة، كما تُقدّم معلومات حول كيفية التخطيط لإدارة هذه العمليات.
إنشاء خطة مشروع لعمليات الإنشاء
استناداً إلى المنهجية التي تختارها، ينبغي عليك تحديد أوقات عمليات الإنشاء ومواقعها. ويجب أيضاً تحديد الترتيب الذي ستتم به عمليات الإنشاء لديك. على سبيل المثال، لن ترغب في إنشاء كود من بيئة التطوير إلى بيئة التشغيل دون المرور ببيئة الاختبار أولاً.
ينبغي عليك أيضاً النظر في كيفية معالجة التطوير الذي لا يجتاز الاختبار لأنه سيلزم التراجع عن هذا التطوير والعودة إلى الحالة السابقة، وهذا سيمنعك من وجود أخطاء في الترقية. يمكنك استخدام Lifecycle Services (LCS) للمساعدة في إدارة عملية الإنشاء من بيئة إلى أخرى.
على سبيل المثال، قد تُعيد عملية الإنشاء أي كود على أخطاء من بيئة الاختبار إلى بيئة التطوير، وتعمل على ترقية الكود الناجح من بيئة الاختبار إلى بيئة التشغيل، وأخيراً ترقية الكود المنتهي من بيئة التطوير إلى بيئة الاختبار.
تحديد البيئات المطلوبة
يجب التخطيط لاختيار بيئتك في بداية التنفيذ. عند التخطيط لبيئاتك، يجب عليك ما يلي:
- تحديد غرض البيئة. النظر فيما إذا كانت البيئات ستُستخدَم للتطوير أو اختبار النظام أو اختبار قبول المستخدم (UAT) أو العمليات.
- مراعاة مخطط البيئة، مثل تطوير أو إنشاء واختبار.
- مراعاة طبقة البيئة (الطبقة 1 أو الطبقة 2).
بيئة الطبقة 1 هي بيئة أحادية المربع تحتوي على جميع المكونات المثبّتة على نفس الخادم، وهي تستخدم Microsoft SQL Server، كما أنها منظّمة لتحقيق أقصى قدر من الكفاءة في التطوير. لا تعد هذه الطبقة خياراً مناسباً لاختبار قبول المستخدم (UAT) أو اختبار الأداء.
أما البيئة من الطبقة 2، أو أعلى، فهي بيئة متعددة المربعات تحتوي على المكونات المثبّتة على خوادم متعددة. تستخدم بيئات الطبقة 2 قاعدة بيانات Azure SQL، وليس Microsoft SQL Server. كما أن البنية الموجودة في هذه البيئة تماثل بيئة التشغيل، لكنها لا تستخدم خاصية الاسترداد لمواجهة الكوارث. ويجب استخدام هذه البيئة لاختبار قبول المستخدم (UAT) واختبار الأداء.
يتضمن العرض القياسي للبيئات على الشبكة السحابية بيئة الطبقة 1 للتطوير والاختبار وبيئة الطبقة 2 اختبار قبول المستخدم (UAT) وبيئة التشغيل. وتتوفر هذه البيئات في أوقات مختلفة، حيث تتوفر بيئة الطبقة 2 أثناء الإعداد، بينما تتوفر بيئة التطوير والاختبار من الطبقة 1 عند بدء مرحلة التصميم وتكوين Microsoft Azure DevOps. وأخيراً، تتوفر بيئة التشغيل أثناء جاهزية نظام الإنتاج مع Microsoft. ويجب طلب هذه البيئة من خلال LCS.
ويمكنك أيضاً إضافة بيئة أخرى للوظائف الإضافية لبيئات من الطبقة 1 والطبقة 2 إذا لزم الأمر. يمكن أيضاً نشر بيئات من الطبقة 1 كبيئة مستضافة على الشبكة السحابية أو صورة بيئة. وهذه البيئات المستضافة على الشبكة السحابية يُديرها العميل أو الشريك. أما صورة البيئة، فهي بيئة محلية تستخدم قرصاً ثابتاً ظاهرياً.
يمكنك اختيار البيئات التي ستحتاج إليها ووقت ذلك. ينبغي عليك تلخيص قوائم البيئات المطلوبة في إحدى مصفوفات Microsoft.
بإمكانك استخدام خطة البيئة للمساعدة في اختيار عملية سير إنشاء الكود في جميع البيئات وتنظيم إدارة دورة حياة التطبيقات (ALM) لديك.
التخطيط للاختبارات المطلوبة
أثناء تنفيذ تطبيقات Finance and Operations، ينبغي تحديد كيفية اختبار التطوير للموافقة عليه ومَن سيجري الاختبار والمعايير التي ستستخدمها للحصول على الموافقة وكيفية تعقّب الاختبار. يمكن استخدام اختبارات الوحدة واختبارات التراجع واختبار الأداء من أجل اختبار النظام.
يُعد اختبار الوحدة مفيداً لاختبار ما إذا كانت هناك وظائف معينّة قيد العمل. لا يتحقق اختبار الوحدة مما إذا كان الكود الجديد يؤثر على الميزات الموجودة في النظام أم لا.
يعمل اختبار التراجع على إجراء اختبار للعملية بأكملها للتأكد من أن الميزات الحالية لا تزال تعمل مع التطوير الجديد. على سبيل المثال، إذا تم إجراء تعديل لإضافة وظائف متعلقة بالعملاء، فقد يجب عليك إجراء اختبارات التراجع للتأكد من أن الوظيفة الجديدة لا تتداخل مع الوظائف الحالية مثل أوامر المبيعات.
وقد يلزمك أيضاً مراعاة إجراء اختبار الأداء للنظام للتأكد من مدى استقراره من خلال دخول عدة مستخدمين إليه وإجراء عمليات هائلة مرهقة، ويساعدك هذا في إيجاد فرص لرفع مستوى الأداء.
تتضمن تطبيقات Finance and Operations أداة مسجل المهام لتوثيق خطوات العملية التي يتخذها المستخدم. يُتيح لك Azure DevOps أيضاً ربط المهام بحل مشروع التطوير. يمكن استخدام المهمة لتعقّب التحديثات ومستندات الاختبار والملاحظات الأخرى.
التحكم بالمصادر ومراقبة الجودة للمطورّين
قد يعمل أحياناً العديد من المطورّين في تطبيقات Finance and Operations في آنٍ واحد. لمنع المطورّين من تداخل عمل أحدهم مع عمل الآخر، يمكن إعداد التحكم بالمصادر باستخدام مشروع Azure DevOps.
سوف يستضيف هذا المشروع الكود المصدر للنموذج لديك، مما سيُتيح للمستخدمين إيداع الكائنات وسحبها. وعند سحب كائن، فإنك تخبر النظام أنك تُجري تغييرات. وعند إيداع الكائن مرةً أخرى، سيُنشئ النظام إصداراً جديداً لهذا الكائن.
يُتيح لك التحكم بالإصدار رؤية التغييرات السابقة التي تم إجراؤها. يمكنك التراجع عن التغييرات المعلقة لأحدث التغييرات التي تم إدخالها. بالإضافة إلى ذلك، يمكنك تحديد الحصول على الأحدث في الكائنات، وبالتالي سيتم سحب أحدث إصدار تم إيداعه للكائن. يجب على المطوّرين استخدام هذه الميزة بانتظام للتأكد من أنهم يستخدمون أحدث كود.
لضمان الجودة في التطوير، احرص على اتباع أفضل ممارسات Microsoft Dynamics X++. وقد تحتاج أيضاً إلى تطوير أفضل الممارسات الخاصة بك، مثل اصطلاحات التسمية، للحفاظ على توحيد جميع عمليات التطوير على مستوى المؤسسة باستمرار.
هل تحتاج إلى مساعدة؟ راجع دليل استكشاف الأخطاء وإصلاحها الذي نقدمه أو يمكنك توفير ملاحظات معينة عبر الإبلاغ عن مشكلة.