كيف تتحول المهمة إلى pull request

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

المسار#

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

مواصفات#

Coroid لا يبدأ من جملتك. بل يحول وصفك أولاً إلى مواصفات: ما سيتم بناؤه، وما يقع خارج نطاق العمل بشكل صريح، ومعايير القبول التي تحدد ما إذا كان العمل قد نجح.

هذا أمر مهم لأن معايير القبول هي ما تختبره مرحلة التحقق لاحقًا. فالمواصفات الغامضة تنتج عملاً يصعب تقييمه.

يمكنك قراءة وتحرير المواصفات في علامة تبويب مواصفات قبل بدء التنفيذ.

دليل التطوير المدفوع بالمواصفات يشرح كيفية كتابة معايير قابلة للاختبار، وتحديد حدود النطاق، والحفاظ على نفس تعريف النجاح عبر مراحل التخطيط والتنفيذ والمراجعة. يوضح كيفية كتابة معايير قابلة للاختبار، وتحديد حدود النطاق، والحفاظ على تعريف موحد للنجاح خلال التخطيط والتنفيذ والمراجعة.

بالنسبة لأي تغيير يتجاوز الحجم الصغير، تتحول المواصفات إلى#

خطة **: مجموعة مرتبة من الخطوات، مجمعة في مراحل. وتمت الموافقة على الخطة قبل كتابة الكود.**رفض الخطة أمر غير مكلف، وهو الخيار الصحيح عندما يكون النهج خاطئًا. أما رفضها بعد كتابة الكود فهو مكلف. وهذه هي المرحلة التي يكون فيها حكمك ذا تأثير كبير.

رفض الخطة قليل التكلفة، وهو القرار الصحيح عندما يكون النهج خاطئًا. أما الرفض بعد كتابة الشفرة فمكلف. هذه هي المرحلة التي يكون لحُكمك فيها أكبر أثر.

يقوم الوكيل بنسخ المستودع إلى مساحة عمل معزولة والعمل فيها. فيقرأ الكود، ويكتب التغيير، ويكتب أو يحدّث الاختبارات.#

مساحة العمل قابلة للتصرف ومخصصة لكل مهمة. ولا يؤثر ما يفعله الوكيل على الفرع الافتراضي، كما لا يمكن لمهمتين تعملان في نفس الوقت رؤية عمل بعضهما البعض.

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

تُشغَّل مجموعة الاختبارات الخاصة بك أولاً — وهي أقوى إشارة متاحة، لأنها تعكس ما قرر فريقك أنّه مهم.#

بالإضافة إلى ذلك،

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

مراجعة#

يقرأ وكيل المراجعة الاختلافات كما يفعل زميل، ثم يسجل النتائج. تُعاد النتائج التي يمكن إصلاحها لإجراء التعديلات؛ أما البقية فتُرفق بـ pull request لتطلع عليها.

لهذا السبب يصل Coroid pull request وقد خضع للمراجعة بالفعل — ليس ليحل محل مراجعتك، بل لكيلا تكون مراجعتك الأولى.

طلب سحب#

تتوقف أتمتة المهام في pull request هنا. فالدمج من مسؤوليتك.

يتوقف التشغيل الآلي للمهام في Coroid عند هذه المرحلة. أما الدمج، فهو من مسؤوليتك.

افتح#

افتح إصدارات أو Coroid المدمج وحده لا يثبت إتمام النشر. COMPLETED أو لا تثبت حالة المهمة أو دمج pull request وحده حدوث النشر.

توضح حالة المهمة مكان وجودها في المسار أعلاه:#

المعنى

مساحة واحدة لـ#

وكيل خانة الوكيل تقوم بتنفيذ مهمة واحدة في كل مرة. تحدد الفواصل عدد المهام التي تُنجز بالتوازي؛ ولا تؤدي إلى إنهاء أي مهمة بشكل أسرع. يعتمد وقت إتمام المهمة على حجم التغييرات ومدة تشغيل مجموعة الاختبارات الخاصة بك.

التالي#

أدوار الوكلاء — أي وكيل يتولى كل مرحلة من مراحل العمل. ثم تابع القراءة. إصدارات لتحديد مسار ما بعد الدمج عبر بيئاتك.