وثائق

كيف يتحقق نظام Coroid من جودة عمله بنفسه

لماذا يصل pull request من Coroid بعد أن تم التحقق منه مسبقًا، وما الذي تثبته كل طبقة من طبقات التحقق بالفعل؟

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

الطبقات

التحقق ليس عملية واحدة؛ هناك أربع طبقات تعمل كل منها للإجابة على سؤال مختلف.

مجموعة اختباراتك. هي أقوى إشارة متاحة، لأنها تحتوي بالفعل على ما حددته فرقتك كمعايير مهمة. يقوم Coroid بتشغيلها في بيئة عمل نظيفة مع كل مهمة.

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

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

الأدلة. عمليات النشر التجريبية، نتائج الفحص، وفروق تغطية الكود المرفقة بـ pull request نفسه، لذا يصل التحقق مع الكود. اطلع على أدلة المراجعة.

  1. مجموعة اختباراتكهل يؤدي التغيير إلى تعطيل ما يعمل حالياً؟
  2. بوابات الجودةهل يتوافق مع المعايير التي تحددها سياستك؟
  3. مراجعةهل يقبله قارئ دقيق للفروقات؟
  4. أدلةهل تم إرفاق الدليل بجانب الكود؟
  5. مراجعتكهل هذا هو التغيير الصحيح الذي يجب إجراؤه؟

تعمل كل طبقة آلية قبل ظهور pull request، لذا تظهر الإخفاقات كعمل إعادة في نفس العملية.

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

ما يثبته التحقق وما لا يثبته

يؤكد التحقق أن التغيير يحقق ما هو مطلوب، ولا يؤثر على الوظائف الحالية، ويتوافق مع المعايير التي حددتها.

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

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

السبب وراء تشغيله مسبقًا

تُشغل كل طبقة قبل ظهور pull request، لذا تُعاد الأخطاء كأعمال إضافية داخل العملية بدلاً من أن تكون pull request ترفضه.

من الأوفر أن تفشل في بيئة العمل بدلاً من أن تظهر على شاشتك. يجب أن تكون مراجعتك هي النظرة البشرية وليس النظرة الأولى.

من أين تبدأ؟

إذا كنت تقوم بتهيئته للمرة الأولى:

  1. تأكد من تشغيل مجموعة اختباراتك — اطلع على إعدادات البناء والاختبار. لا شيء آخر يهم إذا كان هذا غير صحيح.
  2. حدد سياسة افتراضية للمؤسسة على مستوى المعايير وليس على مستوى السياسات الأكثر صرامة.
  3. وصل مزودي الأدلة الذين تستخدمهم حاليًا.
  4. أضف البوابات واحدة تلو الأخرى، ابدأ بالبوابات الاستشارية.

في هذا القسم