أتمتة

تبدأ كل عملية أتمتة في العمل دون الحاجة إلى طلب من أحد، وتعمل وفق جدول زمني أو عند حدوث أمر ما: مثل فتح pull request، أو تسجيل مشكلة، أو فشل عملية تفتيش أو نشر.

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

نوعان من المحفزات#

استخدم الجدول الزمني عندما يكون المحفز مرتبطًا بالوقت، أو عندما يكون العنصر المراد مراقبته موجودًا في نظام آخر لا يرسل أحداث Coroid، مثل Sentry أو Jira. يقوم الجدول الزمني بطلب البيانات من ذلك النظام عبرك. خوادم MCP ويفتح مهامًا للعمل بناءً على ما يجده. انظر إلى جداول زمنية.

استخدم الحدث عندما يمكن إبلاغ Coroid فور حدوثه؛ فهو يقلل من العمل غير الضروري مقارنة بالجدول الزمني الذي يستمر في الاستفسار.

أحداث يمكن اختيارها ضمن عمل جديد#

من GitHub، والذي يتطلب وجود GitHub App:

• فتح pull request أو تحديثه أو دمجه.
• تسجيل مشكلة جديدة.
• ذكر Coroid في تعليق؛ ولا يُحتسب إلا إذا كان لدى كاتب التعليق صلاحيات كتابة في المستودع.

من Coroid:

• فشل مهمة، أو خطة، أو عملية تفتيش للجودة، أو عملية نشر، أو فحص صحة النشر.
• إلغاء إصدار ما.

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

ما تقوم به#

عند تفعيل الحدث، تقوم عملية الأتمتة بأحد الأمور الثلاثة التالية:

• مراجعة pull request. تقوم Coroid Check بمراجعته ونشر نتائج المراجعة على GitHub، مع تعليقات على الأسطر التي تم العثور عليها، واسم لعملية التفتيش هو Coroid Review. هذا الخيار متاح لطلبات السحب التي يتم فتحها أو تحديثها.
• تحويله إلى مهمة عمل. يتم تسجيل الحدث كطلب عمل. وبمجرد اجتيازه لمرحلة التأهيل، يقوم Coroid بإنشاء المهمة أو الخطة. هذا الخيار متاح للمشاكل والتعليقات التي تذكر فيها Coroid.
• اتباع التعليمات المحددة. يقوم وكيل باتباع التعليمات التي كتبتها، مع منحه صلاحيات قراءة فقط، ويمكنه فتح مهام. هذا الخيار متاح لكل الأحداث.

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

مراجعة كل pull request#

لجعل Coroid يراجع طلبات السحب التي يفتحها المستخدمون، وليس فقط طلباته الخاصة:

1. افتح قسم عمل جديد واختر خيار أتمتة.
2. اختر المشروع، أو اتركه فارغًا لتغطية جميع المشاريع.
3. تحت بند المحفز، اختر خيار ‘عند حدوث أمر ما’. تحت بند الحدث، اختر ‘فتح طلب سحب’، ثم اختر خيار ‘مراجعة pull request’.
4. أعطِ العملية عنوانًا ووصفًا مختصرًا، ثم تابع الإعدادات.

تراجع عملية الأتمتة كل pull request جديد، وكل تحديث له، ضمن ذلك المشروع. يتطلب المستودع تثبيت GitHub App، ويجب ألا يكون المشروع مُعدًّا لنمط Local فقط. طلبات السحب الناتجة عن مهام Coroid لا تخضع لمراجعة إضافية؛ لأن مراجعتها جزء من المهمة نفسها.

يمكنك أيضًا تفعيل خاصية طلبات السحب للمشروع ضمن ضبط الجودة. وبذلك تُجرى عمليات التفتيش على كل pull request، وتقوم Coroid Check بمراجعته كجزء من نفس العملية.

مراقبة عملية الأتمتة#

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

الحفاظ على فائدة عمليات الأتمتة#

المهام التي تفتحها عملية الأتمتة تنافس على نفس مساحات الوكلاء مع باقي الأعمال. عملية أتمتة تُفعَل بشكل متكرر قد تستهلك قدرات النظام دون أن تلاحظ.

1. خصص لها أولوية أقل من الأعمال التي يطلبها المستخدمون. P2 أو P3.
2. اجعل المحفز أكثر تحديدًا. عبارة ‘فشلت عملية تفتيش’ تُفعَل بشكل مستمر في مستودع نشط. بينما عبارة ‘فشلت هذه العملية في الفرع الأساسي’ تُفعَل فقط عند وجود خطأ حقيقي.
3. راقب ما أنتجته. إذا فتحت عملية الأتمتة عشرين مهمة ودمجتَ اثنتين فقط، فهي تخلق ضجيجًا واستهلاكًا دون أن تضيف قيمة.

المقياس الحقيقي لنجاح عملية أتمتة هو نسبة المهام التي تم دمجها من بين ما فتحته، وليس عدد مرات تفعيلها.

Sentinel#

وصفت النسخ السابقة من هذه الوثائق برنامج Sentinel، وهو أداة مراقبة تكتشف حدوث شرط معين. لكنه ليس ميزة منفصلة؛ فالشرط إما حدث يمكن لعملية الأتمتة التفاعل معه، أو شيء يتحقق منه الجدول الزمني.

ذات صلة#

• جداول زمنية
• الخطافات
• طرق بدء العمل
• مصنع البرمجيات