التطوير, ضمان الجودة, الاصدارات, النسخ الجاهزة


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


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

  1. يتم تنفيذ عملية تطوير الوركيوب على Git.
  2. يقوم المبرمجون بسحب التعليمات البرمجية المحدثة من الفرع الرئيسي في المستودع العام في سحابة Atlassian Bitbucket إلى أجهزة الكمبيوتر الخاصة بهم.
  3. يقومون بترميز المهام الموكلة إلى المبرمجين وإرسالها إلى فرع DEV مع "طلب سحب" بعد إجراء الاختبار الأول.
  4. يتم فتح فرع مهام مؤقت لكل مهمة لمتابعة تدفق تصنيع التعليمات البرمجية. يجب أن تحتوي كل مهمة على "طلب سحب".
  5. تتم مراجعة رمز "طلب السحب" ودمجه في فرع DEV من قبل المطورين الرئيسيين.
  6. يراقب فريق ضمان الجودة الرمز المدمج في فرع التطوير من خلال تسجيل المهام على بوابة networg.workcube.com.
  7. يقوم فريق ضمان جودة الواجهات IQA باختبار كل مهمة والتعليمات البرمجية المدمجة المرتبطة بها على dev.workcube.com.
  8. يقوم عضو فريق ضمان الجودة بإبلاغ المبرمج بنتيجة الاختبار كملاحظات.
  9. إذا كانت نتيجة الاختبار غير ناجحة ، يتم طلب "المراجعة".
  10. إذا كانت نتيجة الاختبار ناجحة، يتم منح الموافقة على "إضافة إلى الإصدار".
  11. يتم سحب المهمة ذات الحالة "إضافة إلى الإصدار" والرمز المرتبط بها إلى فرع "الرئيسي".
  12. بعد التحقق ، يقوم المطور الرئيسي بدمج الكود مع الفرع الرئيسي وحذف فروع المهام النهائية عن طريق إغلاق فرع المهمة.
  13. يقوم فريق ضمان الجودة بمراقبة الكود المدمج في الفرع الرئيسي من خلال تسجيل المهام على بوابة networg.workcube.com.
  14. يقوم عضو فريق ضمان الجودة باختبار نفس المهمة والتعليمات البرمجية ذات الصلة على بوابة qa.workcube.com.
  15. يقوم عضو فريق ضمان الجودة بالإبلاغ عن نتيجة الاختبار كملاحظات إلى المبرمج.
  16. إذا لم تنجح نتيجة الاختبار ، يتم طلب "المراجعة".
  17. إذا كانت نتيجة الاختبار ناجحة ، تتم إضافة "ملاحظة الإصدار" إلى تفاصيل المهمة.
  18. تم تجميع "ملاحظة الإصدار" كإصلاح عاجل وميزة ونشرها ضمن "ملاحظات الإصدار".
  19. يمكن للمستخدمين ومسؤولي النظام الوصول إلى "ملاحظات الإصدار" من الوكيوب وقراءة الملاحظات وترقية النظام.
  20. يتوفر نوعان من الترقيات كترقية الإصدار أو التصحيح.

كيفية التقديم على الوركيوب للحصول على اقتراحات وإصلاحات عاجلة؟

  1. إذا كنت ترغب في تقديم طلب حول صفحة في الوركيوب ، عندما تكون في تلك الصفحة ، انقر فوق "؟". عند النقر فوق الرمز، يتم فتح القائمة المنسدلة تحته.
  2. انقر فوق الارتباط "الإبلاغ عن مشكلة" في هذه القائمة للانتقال إلى شاشة wiki.workcube.com/addhelp.
  3. في شاشة إضافة تعليمات ، يتم إرسال المعلومات الفنية للصفحة المرتبطة بالخطأ أو الاقتراح إلى Workcube في الخلفية.
  4. يتم طلب لقطات شاشة إضافية وفيديو يلوح في الأفق من المستخدم.
  5. يتم تجميع التذاكر وتحديدها من قبل فريق الترحيب بضمان الجودة ويتم تقديم ملاحظات لمقدم الطلب
  6. تتم مقارنة إصدار وركيوب العميل الذي تم فتح التذكرة منه مع الإصدار الحالي والتصحيحات.
  7. في الإصدار الحالي ، يتم اختبار الحالة.
  8. إذا كان المستخدم (نظام العميل) في الإصدار الحالي ولكن لم يتم العثور على الخطأ في release.workcube.com ، يتم الرد على مقدم الطلب بالقول "احصل على التصحيح".
  9. إذا كان الخطأ موجودا في release.workcube.com ، أيضا التحقق من إصدار ضمان الجودة.
  10. إذا لم يتم العثور على الخطأ على qa.workcube.com ، يتم إعلام المستخدم ك "الإصلاح العاجل سيأتي مع الإصدار التالي".
  11. إذا كان الخطأ موجودا أيضا على qa.workcube.com ، إخطار المستخدم باسم قيد المراجعة.
  12. يتم التحقيق في الخطأ من قبل فريق ضمان الجودة ويتم الكشف عن النتائج ، ويتم تعيين مهمة لفريق DEV.
  13. يدير فريق DEV عملية التطوير على Workcube Project Management وسحابة Bitbucket المدمجة.

لماذا يجب أن يكون لدينا دائما الإصدار الحالي؟

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

كيف نصل إلى الإصدار الحالي؟

  1. إذا كنت لا ترى رقم إصدار Workcube 19.12 وأعلى عند التمرير فوق شعار الوركيوب في الزاوية العلوية اليسرى ، فقد تستخدم نسخة من Master والأسوأ من ذلك ، من فرع DEV.
  2. فرع DEV هو التطوير ، وفرع ضمان الجودة هو بيئة الاختبار. ربما لا تقوم بالترقية بعد التثبيت الأول أو تحاول القيام بذلك يدويا.
  3. هذا وضع محفوف بالمخاطر للغاية لبيئات الإنتاج. إصدار مطور الوركيوب الذي لم يجتاز مراقبة الجودة ولا يزال قديما هو بالتأكيد غير مناسب للاستخدام كموقع إنتاج.
  4. يجب ترقية البيئات الحية (الإنتاج) التي تبقى في فرعي التطوير والرئيسي والمثبتة من إصدار المطور.
  5. تحقق من مقالة wiki التي تشرح الخطوات التي يجب اتخاذها لترقية عمليات تثبيت إصدار المطور في فرعي Dev و Master >> Link

لماذا يجب إعداد بيئة ضمان الجودة إلى جانب البيئة المباشرة (الإنتاجية) على خوادم العملاء؟

  1. يتم تثبيت اثنين من الوركيوب ، qa.domain و live.domain ، على نفس الخادم بدءا من مرحلة التنفيذ للعملاء مع التخصيص أو التعليمات البرمجية الإضافية.
  2. "qa.domain" و "live.domain" هما موقعان من مواقع الوركيوب متصلان بنفس قاعدة البيانات.
  3. يتم تحديث "qa.domain" دائما بأحدث إصدار.
  4. يمكن لمسؤولي النظام والمستخدمين فحص الميزات الجديدة الواردة أو المتوقعة في "qa. المجال" بنفس البيانات وتنفيذ الإجراءات عليها.
  5. من أجل منع الأخطاء المحتملة واختلافات البيانات وممارسات الاستخدام في الإصدار الجديد التي تؤثر على بيئة الإنتاج ؛ يعمل "live.domain" على الإصدار أو التصحيح السابق.
  6. يقوم المسؤول والمستخدمون الرئيسيون بترقية "live.domain" بعد إجراء الاختبارات الأساسية في بيئة ضمان الجودة.
  7. بهذه الطريقة ، بينما يعمل المستخدمون الرئيسيون في الإصدار الجديد من بيئة ضمان الجودة ، يعمل المستخدمون القياسيون بشكل مباشر في الإصدار السابق. ولا تتوقف العمليات الحيوية للمهمة.
  8. من الممكن أيضا الحفاظ على تحديث live.domain دائما ، وإنشاء old.domain وتركه في الإصدار السابق.
  9. يمكن لأولئك الذين لديهم الحق في استخدام شفرة مفتوحة المصدر أيضا تثبيت dev.domain بالإضافة إلى ذلك.
  10. بالنسبة للعملاء الذين لديهم ترخيص شفرة المصدر المفتوح ، يمكن تثبيت dev.domain بالإضافة إلى ذلك.
  11. يتم عزل قاعدة البيانات البيئة الفعلية من خلال إنشاء قاعدة بيانات تطوير لـ dev.domain.
  12. يمكن نقل التخصيص والتحسينات التي تم إجراؤها في بيئة التطوير إلى العميل أو البيئة الحية. هذا الالتزام ينتمي إلى العملاء وشركاء الأعمال.

كيف تتم ترقية الحلول القطاعية والإضافات؟

  1. توجد الحلول القطاعية أو الوظائف الإضافية في مجلد Addons/Partner_Name/Solution_Package في دليل الوركيوب.
  2. يجب أن يكون هذا المجلد في نفس المجلد وبنية الملف تماما مثل مجلد FactorySettings داخل مجلد WBP في الدليل الرئيسي.
  3. يتم التحكم في الترخيص في المنشآت ذات التراخيص الإضافية.
  4. يواصل مطورو الإضافات تطوير الملفات وملفات WRO في مجلدهم الخاص على Git.
  5. تتم ترقية الوظائف الإضافية تلقائيا لعمليات التثبيت المرخصة.

كيفية التعريب؟

  1. يتم تضمين واجهة الإنجليزية والتركية في المكتبة القياسية. هذه هي جزء من التثبيت القياسي.
  2. يتم إجراء تطورات في بيئة التطوير وضمان الجودة ، ويقوم فريق ضمان الجودة بانتظام بتطوير قاموس للواجهة.
  3. يتم تطوير القواميس الألمانية والفرنسية والعربية والروسية والإيطالية وغيرها بانتظام في بيئة التطوير والتقييم بالتعاون مع شركاء الأعمال المحليين.
  4. تتم إضافة الكلمات والتعاريف والعبارات في التطبيقات القياسية بانتظام إلى فرع التطوير والفرع الرئيسي من قبل الشريك المحلي.
  5. يتم وضع الوظائف الإضافية التي تم تطويرها للامتثال للقوانين واللوائح المحلية والملفات المخصصة وفقا لذلك تحت مجلد Addons / Partner / Country وإضافتها إلى فرع DEV و Master على Git.
  6. لرؤية الكلمات القادمة من القاموس على صفحة ، انقر فوق رمز الإعدادات في الزاوية اليمنى العليا. يتم تحديد خانة الاختيار "وضع التطوير" ضمن العنوان "أخرى" في علامة التبويب إعداد.
  7. عند تحديث الصفحة ، تظهر الكلمات من القاموس على أنها | كلمة |. يؤدي النقر فوق الكلمة إلى نقلك إلى القاموس.

كيف يتم التخصيص على مستوى التعليمات البرمجية؟

  1. يمكن تمديده عن طريق إضافة 4 ملفات رأس إلى كائن الوركيوب (WO: fuseaction).
  2. في DevTools ، يوجد WO-Fuseaction في قائمة كائنات الوركيوب. تتم كتابة مسارات الملفات الإضافية إلى المدخلات الممتدة في تفاصيل WO.
  3. وبالتالي ، عندما يتم طلب WO-Fuseaction ، يتم تشغيل ملفات "قبل التوسع". مع حفظ أو تحديث ، يتم تشغيل الملفات "بعد التوسع".
  4. Addoptions هو عمل ملف مخصص بدلا من الملف القياسي.
  5. عندما تتم كتابة مسار الملف المخصص ضمن WO-Fuseaction في حقل مسار التحكم في الإضافات ؛ addoption ملف يعمل بدلا من القياسية.
  6. لا ينصح ب Addoptions لأنه يفصل التطبيق عن الإصدار القياسي. لا تستخدم هذه الطريقة إلا إذا كان ذلك ضروريا حقا. في عام 2022 ، ستتم إزالة هذه الميزة.
  7. ضمن تطبيق BPM ، تتم إضافة ملف العرض أو ملف الإجراء إلى شاشات مرحلة العملية.
  8. تتم إضافة التقارير الخاصة عن طريق تحميل الملفات إلى التقارير الخاصة.
  9. تتم إضافة الملفات المطورة خصيصا إلى مستندات وقوالب طابعة النظام ضمن الإعدادات العامة.
  10. تتم إضافة كلمات جديدة إلى القاموس لتغيير الكلمات في الواجهة. لكي لا تتأثر بالترقيات، يجب وضع علامة على خانة الاختيار "عدم السماح بالتأثر بالترقية".

أين يجب أن أخزن الرموز التي قمت بتطويرها خصيصا لعميلي؟

  1. يجب عليك فتح وتخزين فرع خاص بالعميل في مستودع Bitbucket التابع لمجتمع مطوري Workcube.
  2. تخزين التعليمات البرمجية على خادم العميل ليس طريقة حديثة لاستمرارية التعليمات البرمجية والنسخ الاحتياطي.
  3. قد يتغير شريك الخدمة ، وقد يغادر المطورون المشروع وقد تتعطل الخوادم. لهذه الأسباب ، يجب عليك الاحتفاظ بمشروعك في فرع حتى لا تعتمد على شخص وتقلل من المخاطر.
  4. يتم فتح الفرع الخاص بالعميل في المستودع كمشروع / اسم المشروع. في Networg.workcube.com ، يجب إدخال عنوان Bitbucket للمشروع ذي الصلة.
  5. إذا كنت تريد تطوير الرمز خصيصا للعميل للعمل مع الإصدار ، فيجب عليك وضعه في مجلد Addons / Custom / ProjectName في فرع "Master".
  6. تتم ترقية كل تعديل يقوم به المطور في مجلد Addons / Custom / ProjectName تلقائيا أثناء انتقالات الإصدار.

كيفية مشاركة المعلومات وفقا لقواعد الناتج المحلي الإجمالي؟

  1. يمكن فقط للموظفين المصرح لهم وشركاء الأعمال المعتمدين للشركات المستخدمة الذين لديهم تسجيل اشتراك في networg.workcube.com إنشاء تذكرة للحصول على الدعم
  2. يجب تسجيل الأشخاص المصرح لهم عن طريق ملء وثيقة الاتصال الخاصة بالنظام - الوصول - اللائحة العامة لحماية البيانات (GDPR).
  3. من الضروري ملء جميع المعلومات الموجودة في الإعدادات العامة > نموذج معلومات الطلب لكل تثبيت الوركيوب.
  4. وفقا لقواعد الناتج المحلي الإجمالي ، لا يتم تقديم أي معلومات من قسم الدعم إلى الإخطارات المقدمة دون الامتثال لهذه القواعد.

?

?