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