Coroid يتخذ العديد من القرارات أثناء معالجته لمهمة ما: ما إذا كان الطلب يستحق أن يتحول إلى عمل فعلي، وكيفية بنائه، وما إذا كان الناتج جيدًا بما يكفي لعرضه عليك. بعض القرارات لا تخرج أبدًا من يد البشر؛ والدمج هو أوضح مثال على ذلك.
القرارات التي يتخذها Coroid
- ما إذا كان الطلب سيتحول إلى عمل. التأهيل تتحقق من وجود نسخ مكررة، أو أشياء تم إصلاحها بالفعل، أو أشياء لا يمكن إعادة إنتاجها. أما بالنسبة للطلبات التي تصل بدون تدخل بشري، فإن عملية القبول تقرر بشأنها وفقًا لتوجيهاتك. توجيهات ما إذا كان يمكن بدء العمل الآن، أو لاحقًا، أو عدم بدئه أصلًا.
- كيفية بناء العمل والتحقق منه. الخطة، الكود، الاختبارات، عوائق الجودة، اختبارات ضمان الجودة وعملية المراجعة. اطلع على كيف يتحقق Coroid من عمله الخاص.
- ما كان سيقرره بشأن الدمج. Coroid يسجل حكمًا عن كل pull request يقوم بمراجعته، ولا يتخذ أي إجراء بناءً عليه. اطلع على كيف يتحقق Coroid من أحكامه.
القرارات التي تظل بيد البشر
| قرار | من يتخذه |
|---|---|
| دمج pull request في فرعك | شخص ما، في GitHub أو GitLab، أو مع الموافقة والدمج في Coroid |
| الإصدار والنشر | شخص ما، عبر خط أنابيبك أو إصدار في Coroid |
| حدد الغرض من العمل غير المراقب وميزانيته | مالك أو مسؤول، عبر نشر توجيه |
| حدد ما يعنيه الانتهاء بالنسبة لمهمة ما | الشخص الذي طلبها، في عقدها عقد النتيجة |
| إنشاء عمل - توقف التأهيل | شخص لديه صلاحيات، مع إنشاء العمل على أي حال وسبب |
Coroid لا يدمج أبدًا بشكل مستقل، ولا توجد إعدادات تسمح بذلك. اطلع على الدمج.
التوجيهات لا تغير من يقوم بالدمج
تسمح الولاية ببدء العمل دون الحاجة إلى طلب كل جزء على حدة. لكنها لا تسمح بقبول النتيجة دون موافقة شخص ما. العمل المقبول بموجب ولاية يخضع لنفس عملية التحقق مثل أي مهمة أخرى، وينتهي بنفس الطريقة: طلب سحب ينتظر موافقة شخص.
ما تضيفه الولاية هو المساءلة عن العمل غير المراقب: المشاريع التي يمكنه التعامل معها، الميزانية المسموح بها، وسجل كل قرار يتعلق به.
كيف تقوم Coroid بفحص حكمها الخاص؟
لكل مراجعة من pull request تقوم بها Coroid، ولكل مهمة تصبح جاهزة للدمج، تدوّن Coroid ما كانت ستقرره لو سُمح لها بالدمج:
- ستوافق. كل ما تحتاجه متوفر وبحالة جيدة: فحوصات الجودة على آخر إصدار من pull request، ومراجعة Coroid، وفحوصات مزودك، بالإضافة إلى دمج نظيف، وفي حالة المهمة، نتائج فحص الجودة وقرار المراجع.
- سترفض. على الأقل أحد هذه العوائق موجود.
- لا يمكن تحديد الأمر. كان هناك شيء مطلوب غير متوفر. عدم وجود دليل لا يعتبر موافقة أبدًا.
لا يتم نشر هذا الحكم على pull request، ولا يغيّر المهمة، ولا يدمج أي شيء. كما أنه غير ظاهر في Coroid حتى الآن.
ثم تقارن Coroid كل حكم بما حدث بعد الدمج:
- مراجعة لاحقة من pull request بعنوان تراجع… تُصنّف المراجعة السابقة على أنها مُتراجع عنها؛
- مراجعة لاحقة من pull request تقول إصلاح #n تُصنّف pull request n على أنها تم إصلاحها بشكل عاجل؛
- على شاشة مراجعة المهمة، تحت ما حدث بعد الدمج، يمكن لأي شخص في المؤسسة تصنيف pull request مدمج على أنه تم التراجع عنه، أو إصلاحه بشكل عاجل، أو تم الإبلاغ عن عيب.
الموافقة على pull request التي تم تراجعها أو إصلاحها لاحقًا تُعتبر موافقة خاطئة. في مستودعها الخاص، تقدم Coroid أيضًا نسخًا معطلة عمدًا من التغييرات الحقيقية لقياس مدى قدرتها على اكتشافها.
لماذا الاحتفاظ بهذا السجل؟
حتى يمكن الإجابة على سؤال «هل يمكن الوثوق بـ Coroid لدمج هذا النوع من التغييرات؟» باستخدام أدلة — كم مرة كانت موافقاتها خاطئة، وأي أنواع التغييرات، وعدد الأمثلة — بدلاً من الاعتماد على الثقة فقط. حتى اليوم، لا يتم اتخاذ أي إجراء بناءً على هذا السجل. وإذا تغير ذلك يومًا ما، فسيكون قرارًا يتخذه المالك صراحةً، وهذا السجل هو ما سيُبنى عليه هذا القرار.