وثائق

سياسات الجودة وضوابطها

حدد المتطلبات التي يجب أن تستوفيها الأعمال، واربطها بالمشاريع، وغيّرها بأمان.

سياسة سياسة السياسة هي مجموعة مسماة ومُرقّمة من بوابات الجودة. تُرفق السياسات بالمشاريع؛ أما البوابات فهي التي تعمل فعليًا.

للاطلاع على المفاهيم – الإيقاف مقابل التوصية، ومكان وجود البوابات في سير العمل – اقرأ بوابات الجودة أولاً. تغطي هذه الصفحة إدارتها.

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

مراقبة الجودة
حدد المعايير التي يتم وفقها فحص كل مشروع؛ يُطبق التغيير فورًا على الأعمال الجديدة بمجرد إعداده.
واجهة المتجرإعداد مخصص
يعمل عند فحص المهام، طلبات السحب، والتحقق من الإصدارات.
عمليات التفتيش على كل تغيير
أي تغيير يفشل في اجتياز عملية التفتيش يعود إلى المطور قبل أن يقوم أي شخص بمراجعته.
  • مكافحة الفوضىتُعيد التغيير إلى المصدر إذا أدى إلى إضعاف اختبارات الوحدة، أو إخفاء الأخطاء، أو نشر عناصر نائبة، أو إضافة ديون تقنية.
  • اختبارات الوحدةتكتشف اختبارات الوحدة الموجودة في المستودع وتنفذها مع كل تغيير يتم إدخاله.
  • اختبارات المتصفح2 من أصل 3يختلف عن الإعداد الافتراضيتشغل سيناريوهات التصفح الخاصة بك لتقييم التغييرات المدخلة.
  • الترجماتيختلف عن الإعداد الافتراضيتتحقق من ترجمة النصوص المعدلة والتأكد من تطابق العناصر النائبة وأشكال الجمع فيها.
  • عمليات تفتيش المستودعتنفذ الأوامر المخصصة لديك، مثل تنسيق الكود، وقياس حجم الملفات، وتشغيل اختبارات التكامل، وفحوصات الأمان.
ضمان الجودة
  • ضمان جودة شاملشاملتجمع أداة ضمان الجودة أدلة ولقطات شاشة حية مقارنةً بالمواصفات المحددة؛ وعند تعطيلها، يتم تطبيق إجراءات ضمان الجودة القياسية.

ضبط الجودة: السياسات المطبقة وآخر عملية تفتيش. بيانات توضيحية.

إنشاء سياسة

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

تحتاج معظم المنظمات إلى سياستين أو ثلاث سياسات، وليس سياسة لكل مشروع:

  • سياسة صارمة لخدمات الإنتاج
  • سياسة قياسية لجميع العمليات العادية
  • وأحيانًا سياسة خفيفة للأدوات الداخلية والنماذج الأولية

إذا زاد عدد السياسات عن ذلك، لن يتمكن أحد من تذكر أي مشروع تخصه أي سياسة.

الإعداد الافتراضي للمنظمة وإعدادات المشروع الخاصة

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

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

طلبات السحب

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

  • Coroid ضبط الجودة تُجرى عمليات الفحص المذكورة أعلاه على كل pull request وتُبلغ عن النتيجة كعملية فحص Coroid ضبط الجودة على GitHub.
  • Coroid مراجعة يقرأ مُراجع Coroid كل pull request ويُعلق على الأسطر التي يوجد بها اعتراض. وهو يقرأ طلبات السحب التي تفحصها عملية Coroid ضبط الجودة.

إعدادات Coroid مراجعة:

  • ما ينشره. التوصية، وهي الإعداد الافتراضي، تُضيف تعليقات دون أن تفشل في عملية الفحص الخاصة بها. يؤدي تفعيل خيار الإيقاف إلى تغيير السلوك عند اكتشاف مشكلة، فيفشل الفحص. اجعل عملية Coroid مراجعة عملية فحص إلزامية في GitHub إذا كان يجب أن يوقف الإيقاف عملية الدمج.
  • أي طلبات سحب. بشكل افتراضي، ينتظر حتى يتم تمييز المسودة كجاهزة، ويتجاهل طلبات السحب التي فتحها Coroid، لأن مُراجع Coroid قد راجعها بالفعل داخل المهمة. كما يمكنه تجاهل طلبات السحب الصادرة عن الروبوتات.
  • متى يقوم بالمراجعة. ينتظر فترة هدوء بعد آخر عملية دفع، وبشكل افتراضي خمس دقائق. تُلغي عملية دفع جديدة مراجعة لم تبدأ بعد. يبدأ تشغيل المراجعة على GitHub فورًا عند الطلب.
  • عمق المراجعة. مدى ما يمكن للمُراجع قراءته وكتابته خلال مراجعة واحدة.

يتبع قواعد مراجعة Coroid والقواعد الموجودة في مجلد review-rules لمشروع يتبع الإعداد الافتراضي للمنظمة، تُطبق إعدادات الإعداد الافتراضي، كما هو الحال مع أي عنصر تحكم آخر.

عند حدوث خلل ما

ثلاثة مفاتيح تبديل تحت الإعداد الافتراضي للمنظمة تحوّل حالات الفشل إلى مهام متابعة لكل مشروع. يُفعّل كل مفتاح تبديل أتمتة واحدة، مدرجة في مصنع تحت قسم الأتمتات؛ يقرأ الوكيل الكود ويفتح مهمة، وتمر المهمة بنفس المواصفات والبناء والتحقق والمراجعة مثل أي مهمة أخرى.

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

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

كانت هذه قوالب في عمل جديد. أي آلية أنشأتها من أحد هذه القوالب تستمر في العمل. إذا لم تعدلها، فإن تفعيل المفتاح المقابل سيتولى التحكم فيها بدلاً من بدء آلية ثانية. أما إذا عدلتها، فتبقى ملكًا لك: يسميها المفتاح باسمها، ويمكنك اعتمادها ليتم التحكم فيها عبر المفتاح.

النشر الآمن

مشكلة أوضاع الفشل المتعلقة بالبوابات لا تكمن في ضعفها، بل في أن بوابة الحجب ذات النوايا الحسنة قد تعطل جميع المهام في المؤسسة دفعة واحدة.

تسلسل آمن:

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

التحكم في الإصدارات والتراجع عنها

السياسات لها إصدارات. كل مفتاح ينشر إصدارًا جديدًا، ويمكن التراجع عنه عبر العودة إلى الإصدار السابق؛ كما يمكن استعادة الإصدارات القديمة من سجل الإصدارات في المحرر المتقدم.

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

التجاوزات

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

راقب معدل التجاوزات لديك. إذا تم تجاوز بوابة ما في معظم المرات التي تُفعّل فيها، فهي لا تفرض أي قيود، بل تخلق عوائق وتولد سجلات ورقية. إما أن تصحح البوابة أو تلغيها.