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

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

المسار#

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

مواصفات#

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

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

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

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

تخطيط#

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

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

بناء#

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

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

تحقق#

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

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

مراجعة#

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

لهذا السبب يصل إليك طلب سحب Coroid pull request بعد مراجعته مسبقًا؛ وليس لاستبدال مراجعتك، بل لضمان أن مراجعتك ليست الأولى.

طلب سحب#

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

تتوقف أتمتة المهام في Coroid هنا؛ عملية الدمج من مسؤوليتك.

بعد عملية الدمج#

فتح إصدارات لتحضير الالتزام الدقيق الذي تنوي شحنه. يمكن أن يحتوي الإصدار على عدة طلبات سحب تم دمجها، أو التزام مباشر، أو عمل تم دمجه خارج Coroid. تتعلق بوابة الإصدار وموافقاتها بذلك الالتزام وببيئة محددة. يقوم خط أنابيب النشر الخاص بك بنشره؛ ويسجل Coroid نجاحًا ملاحظًا أو شهادة صريحة قبل عرضه كمنتج جاهز للشحن. المهمة المُ标记 بـ COMPLETED أو طلب سحب pull request المدمج وحده لا يثبت اكتمال عملية النشر.

حالات المهام#

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

ما الذي يحدد معدل إنجاز المهام؟#

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

التالي#

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