وثائق

كيف يتحقق نظام 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. أضف البوابات واحدة تلو الأخرى، ابدأ بالاستشارية أولًا.

في هذا القسم