التخطيط لعمليات الإنشاء والاختبار والتحكم فِي الجودة
تستعرض هذه الوحدة عمليات التطوير التي يُمكنك استخدامها لإدارة عمليات الإنشاء والاختبار والتحكم فِي الجودة. بالإضافة إلى أنها توفر معلومات حول كيفية التخطيط لإدارة هذه العمليات.
إنشاء خطة مشروع لعمليات الإنشاء
استنادًا إِلى المنهجية التي تختارها، ينبغي عليك تحديد أوقات عمليات الإنشاء ومواقعها. ويجب أيضاً تحديد الترتيب الذي ستتم به عمليات الإنشاء لديك. عَلى سَبِيلِ المِثالِ، لن ترغب فِي إنشاء شفرة من بيئة التطوير إِلى بيئة التشغيل دون المرور ببيئة الاختبار أولاً.
تحتاج أيضاً إلى التفكير فِي كيفية التعامل مع التطوير الذي لا يجتاز الاختبار لأنك ستحتاج إلى التراجع عن هذا التطوير. سيمنعك هذا النهج من الوقوع في الأخطاء. يمكنك استخدام Microsoft Dynamics 365 Lifecycle Services للمساعدة على إدارة عملية الإنشاء من بيئة إِلى أخرى.
على سبيل المثال، قد تُعيد عملية الإنشاء أي كود على أخطاء من بيئة الاختبار إلى بيئة التطوير، وتعمل على ترقية الرمز الناجح من بيئة الاختبار إلى بيئة التشغيل، وأخيراً ترقية الرمز المنتهي من بيئة التطوير إلى بيئة الاختبار.
تحديد البيئات المطلوبة
يجب عليك التخطيط لاختيار البيئات الخاصة بك فِي بداية التنفيذ. عند التخطيط لبيئاتك، يجب عليك ما يلي:
- تحديد غرض البيئة. النظر فيما إذا كنت تخطط لاستخدام البيئات من أجل التطوير أو اختبار النظام أو اختبار قبول المستخدم (UAT) أو العمليات.
- مراعاة مخطط البيئة، مثل تطوير أو إنشاء واختبار.
- مراعاة طبقة البيئة (الطبقة 1 أو الطبقة 2).
بيئة الطبقة 1 هي بيئة أحادية المربع تحتوي على جميع المكونات المثبّتة على نفس الخادم، بيئة الطبقة 1 تَستخدِمُ Microsoft SQL Server، كمَا أنَّها منظّمةً من أجل تحقيقِ أقصى قدرِ مِن الكفاءةِ فِي التطويرِ. لا تُعدُّ هذه الطبقة خياراً مناسباً لاختبار قبول المستخدم (UAT) أو اختبار الأداء.
أما البيئة من الطبقة 2 أو أعلى فهي بيئة متعددة المربعات تحتوي على المكونات المثبّتة على خوادم متعددة. وبدلاً من Microsoft SQL Server، تستخدم بيئات الطبقة 2 قاعدة بيانات Microsoft Azure SQL. كما أن البنية الموجودة في هذه البيئة تماثل بيئة التشغيل، لكنها لا تستخدم خاصية الإصلاح بعد كارثة. يجب عليك استخدام هذه البيئة لاختبار قبول المستخدم (UAT) واختبار الأداء.
يتضمن العرض القياسي للبيئات على الشبكة السحابية بيئة الطبقة 1 للتطوير والاختبار وبيئة الطبقة 2 اختبار قبول المستخدم (UAT) وبيئة التشغيل. يوفر النظام هذه البيئات في أوقات مختلفة:
- بيئة المستوى 2 - أثناء عملية التثبيت.
- بيئة التطوير والاختبار من الطبقة 1 - عند بدء مرحلة التصميم وتكوين Microsoft Azure DevOps.
- بيئة التشغيل - أثناء استعداد نظام التشغيل مع Microsoft. يجب أن تطلب هذه البيئة من خلال Lifecycle Services.
ويمكنك أيضاً إضافة بيئة أخرى للوظائف الإضافية لبيئات من الطبقة 1 والطبقة 2 إذا لزم الأمر. بالإضافة إلى ذلك، يُمكنك نشر بيئات من الطبقة 1 كبيئة مستضافة على الشبكة السحابية أو صورة بيئة. يدير العملاء أو الشركاء البيئات المستضافة على الشبكة السحابية. أما صورة البيئة، فهي بيئة محلية تستخدم قرصًا ثابتًا ظاهريًا.
يمكنك اختيار البيئات التي سوف تحتاج إليها ووقت ذلك. يجبُ عليك تلخيص قوائم البيئات المطلوبة فِي إحدى مصفوفات Microsoft.
بإمكانك استخدام خطة البيئة للمساعدة في اختيار عملية سير إنشاء الكود في جميع البيئات وتنظيم إدارة دورة حياة التطبيقات (ALM) لديك.
التخطيط للاختبارات المطلوبة
في أثناء تنفيذ تطبيقات التمويل والعمليات، ينبغي تحديد كيفية اختبار التطوير للموافقة عليه، ومَن سيجري الاختبار والمعايير التي ستستخدمها للحصول على الموافقة وكيفية تعقّب الاختبار. يُمكنك استخدام اختبارات الوحدة واختبارات التراجع واختبار الأداء من أجل اختبار النظام.
يُعد اختبار الوحدة مفيداً لاختبار ما إذا كانت هناك وظائف معينّة قيد العمل. لا يتحقق اختبار الوحدة مما إذا كان الكود الجديد يؤثر على الميزات الموجودة في النظام أم لا.
يعمل اختبار التراجع على إجراء اختبار للعملية بأكملها للتأكد من أن الميزات الحالية لا تزال تعمل مع التطوير الجديد. على سبيل المثال، إذا قمتَ بإجراء تعديل لإضافة وظائف متعلقة بالعملاء، فقد يجب عليك إجراء اختبارات التراجع للتأكد من أن الوظيفة الجديدة لا تتداخل مع الوظائف الحالية مثل أوامر المبيعات.
قد ترغب أيضاً فِي اختبار أداء النظام للتأكد مِن استقرار النظام. للقيام بذلك، اطلب من عِدة مستخدمين الدخول إلَى النظام وإجراء عمليات ضريبية كبيرة الحجم. يمكن أن يساعدك هذا النهج في العثور على فرص لزيادة مستوى الأداء.
تشملُ تطبيقات التمويل والعمليات أداة مسجل المهام لمساعدتك فِي توثيق خطوات العملية التي يتخذها المستخدم. مع Microsoft Azure DevOps، يُمكنك أيضاً ربط المهام بحل مشروع التطوير. ثُم، يُمكنك استخدام المهمة لتعقّب التحديثات ومستندات الاختبار والملاحظات الأخرى.
التحكم بالمصادر ومراقبة الجودة للمطورّين
قد يعمل أحياناً العديد مِن المطورّين في تطبيقات التمويل والعمليات في وقت واحد. من أجلِ منعِ المطورّين من تداخلِ عملِ أحدِهم مَع عملِ الآخرِ، يُمكنك إعداد التحكم بالمصادر باستخدام مشروع Azure DevOps.
سيستضيف مشروع Azure DevOps الكود المصدر للنموذج لديك، مما سيُتيح للمستخدمين إيداع الكائنات وسحبها. وعند سحب كائن، فإنك تخبر النظام أنك تُجري تغييرات. عند تسجيل الدخول إلَى الكائن، يُنشئ النظام إصدارًا جديدًا لهذا الكائن.
يتيح لك التحكم فِي الإصدار عرض التغييرات السابقة التي أجراها أحد الأشخاص. يمكنك التراجع عَن التغييرات المعلقة لأحدث التغييرات التي تم إدخالها. علاوةً على هذا، يمكنك تحديد الحصول على الأحدث فِي الكائنات، وبالتالي سيتم سحب أحدث إصدار تم إيداعه للكائن. يجب أن يستخدم المطوّرون هذه الميزة بانتظام للتأكد من أنهم يستخدمون أحدث كود.
لضمان الجودة في التطوير، احرص على اتباع أفضل ممارسات Microsoft Dynamics 365 X++. وقد تحتاج أيضاً إِلى تطوير أفضل الممارسات الخاصة بك، مثل اصطلاحات التسمية، للحفاظ على توحيد جميع عمليات التطوير في جميع أنحاء المؤسسة باستمرار.
حدّد نظام التحكم فِي الإصدار.
في تطبيقات التمويل والعمليات، إن نظام التحكم فِي الإصدار أمر ضروري. Azure DevOps يدعم نظام التحكم فِي إصدار Team Foundation (TFVC) وGit.
التحكم فِي إصدار Team Foundation من Azure DevOps
إنَّ نظام التحكم فِي إصدار Team Foundation مِن Azure DevOps هو نظام تحكم فِي إصدار واحد لتطبيقات التمويل والعمليات. إنَّه نظامُ تحكمٍ مركزِي فِي الإصدارِ، ما يعنِي أنَّ المُطورِين يعمَلون فِي فرعٍ واحدٍ، ولديهم إصدارٌ واحدٌ من كل ملفٍ على أجهزة التطوير الخاصة بهم. ينتمِي كلُ فرعٍ إِلى مساحةِ عملِ خادمٍ، ويعمل كلُ مطورٍ فِي مساحةِ عملٍ محليةٍ. عندما يتحققُ مطورُ البرامجٍ مِن شفرةِ المَصدرِ، يجبُ عليه التأكدُ مِن التحققِ مِن أحدثِ إصدارٍ وحلِ التعارضات الحالية.
بشكل افتراضي، يتم إلغاء تنشيط مستودعات TFVC في منطقة إعدادات المؤسسة فِي Azure DevOps. أنت بحاجة إلَى تنشيط المستودعات قبل أن تتمكن مِن إنشاء مشروع Azure DevOps جديد باستخدام TFVC كنظام للتحكم فِي الإصدار.
لتنشيط التحكم فِي إصدار Team Foundation (TFVC) فِي مؤسستِك، اتبع الخطواتِ التاليةَ:
- افتَح Azure DevOps مِن خلال الانتقال إلَى dev.azure.com/<your organization>.
- حدّد إعدادات المؤسسة فِي الزاوية اليسرى السفلية من لوحة المعلومات.
- افتح المستودعات > Repos.
- قم بإيقاف تشغيل تبديل تعطيل إنشاء مستودعات TFVC فِي القسم جميع إعدادات المستودع.
يمكنُك إنشاءُ مشاريعِ Azure DevOps جديدةٍ عَن طريقِ استخدامِ TFVC كنظامٍ للتحكمِ فِي الإصدارِ.
Git
Git هو نِظامُ التَحكمُ الموصى به فِي الإصدَارِ الافتِراضِي مِن Microsoft للتَطويرِ.
فِي حِينِ أنَّ TFVC هو نظامُ تحكمٍ مَركَزي فِي الإصدارِ، فإن Git هو نظامٌ موزعٌ. لدَى كلِّ مطورٍ نسختُه الخاصةُ مِن مُستودعِ المصدرِ (أو إصدارٍ فرعي خفيفِ الوزن) ويمكنُه إجراءُ تغييراتٍ عليه. يمكنُ للمطورين إنشاءُ إصداراتٍ فرعيةٍ خاصةٍ جديدةٍ والتبديلُ من إصدارٍ فرعي إِلى آخر. فِي TFVC، مِن الصعبِ التبديل من إصدارٍ فرعي إِلى آخر، وغالبًا ما يتطلب بيئاتِ تطويرٍ متعددةً.
مِن المُهم ملاحظةُ أنَّه يمكنُك الانتقالُ مِن TFVC إِلى Git، والعَكسُ صحيحٌ.