يبدأ أي تلقائي عمله دون طلب من أحد في كل مرة؛ حيث يعمل وفق جدول زمني، أو عند حدوث شيء ما: مثل فتح pull request، أو تسجيل مشكلة، أو فشل في عملية التحقق أو النشر.
يتم سرد كل تلقائي في المصنع تحت قسم التلقائيات، مع توضيح ما يُفعِله وما يبدأه. يمكن إنشاء تلقائي في قسم العمل الجديد: اختر خيار التلقائي، ثم حدد متى يعمل وما يفعله، بكلماتك الخاصة.
- جدولةوقت
- أتمتة الأحداثعندما يحدث شيء ما
مهمة عادية
مواصفات، خطة، بناء، تحقق، مراجعة. تستخدم مساحة للوكيل؛ حدد لها أولوية أقل.
P2P3طلب سحب من pull request
لا يمكنه دمج نفسه أو الالتزام بفرعك الأساسي.
أنت تقرّ
نوعان من المحفزات
| محفز | عمليات تنفيذ | مثال |
|---|---|---|
| جدول زمني | كل بضع ساعات، أو يوميًا، أو أسبوعيًا، أو شهريًا | اطلب من Sentry تزويدك بأخطاء جديدة كل ساعة وافتح مهمة لكل خطأ منها. |
| حدوث شيء ما | عندما يرسل GitHub أو Coroid الحدث المطلوب. | عند فشل مهمة ما، يتم تحديد السبب وفتح مهمة لإصلاحه. |
استخدم الجدول الزمني عندما يكون المحفز هو الوقت بالفعل، أو عندما يكون العنصر المراد مراقبته موجودًا في نظام آخر لا يرسل أحداث Coroid، مثل Sentry أو Jira. يقوم الجدول الزمني بطلب البيانات من ذلك النظام عبرك. خوادم MCP ويفتح مهامًا للعمل على ما يجده. انظر إلى جداول زمنية.
استخدم الحدث عندما يمكن إخبار Coroid بحدوثه فورًا؛ فهو يقوم بعمل أقل عديم الفائدة مقارنة بالجدول الزمني الذي يستمر في الطلب المتكرر.
أحداث يمكن اختيارها في قسم العمل الجديد
من GitHub، الذي يحتاج إلى تطبيق GitHub:
- فتح pull request أو تحديثه أو دمجه
- تسجيل مشكلة جديدة
- ذكر Coroid في تعليق؛ ولا يُحتسب إلا إذا كان لدى كاتب التعليق صلاحيات كتابة على المستودع.
من Coroid:
- فشل مهمة، أو خطة، أو عملية تحقق من الجودة، أو نشر، أو فحص صحة النشر
- نجاح النشر
- إلغاء إصدار برمجي
الأحداث التي تطلقها أنظمتك الخاصة تتطلب حساب خدمة، وأحداث Slack وTelegram وJira تتطلب مرشحًا: يمكن تغيير حدث التلقائي في محرره. انظر إلى خطوط الربط.
ما يفعله
يتبع الوكيل تعليماتك؛ يمكنه قراءة كود المشروع وفتح مهام، لكنه لا يغير أي شيء مباشرةً. المهام التي يفتحها تمر بنفس مسار التحديد والتخطيط والبناء والتحقق والمراجعة مثل أي مهمة أخرى، وتنتهي بـ pull request توافق عليه.
وفق جدول زمني، يمكن للتلقائي بدلاً من ذلك تشغيل اختبارات المتصفح الخاصة بك على سطح اختبار.
التلقائيات الثابتة التي يكتبها Coroid لك هي مفاتيح تبديل في ضبط الجودة، وليست للإنشاء في قسم العمل الجديد:
- مراجعة طلبات السحب. ضبط الجودة طلبات السحب يقوم بتشغيل فحوصات المشروع على كل pull request (Coroid ضبط الجودة) ويضيف تعليق Coroid مراجعة عليه.
- تحويل الرسائل والمشاكل إلى طلبات. رسائل Slack وTelegram، وتعليقات GitHub التي تذكر Coroid، ومشاكل Jira الجديدة تتحول إلى طلبات عند تفعيل مصدرها في ضبط الجودة، ضمن قسم قبل بدء العمل. انظر إلى متعقبو المشاكل لـ Jira.
- متابعة حالات الفشل. كل مهمة فاشلة، أو نشر فاشل، أو إصدار تم إلغاؤه لديه مفتاح تبديل تحت عند حدوث عطل ما.
- تنظيف الديون التقنية القائمة. مشروع تنظيف الديون التقنية الأسبوعي هو مفتاح تبديل في صفه الخاص بمنع التراكم.
التلقائي الذي يديره مفتاح تبديل يُذكر ذلك في صفحته بالمصنع، مع رابط إلى المفتاح؛ يمكن تعليقه أو إيقافه هناك؛ وعند تغيير تعليماته يصبح تلقائيًا خاصًا بك بعد تأكيدك.
التلقائيات التي تم إنشاؤها مسبقًا وترسل طلبات لا تزال تعمل، وتُدرج تحت قسم التلقائيات. أما التلقائيات التي كانت تمرر طلبات مراجعة فقد تم تعليقها عندما تولى ضبط الجودة مهمة Coroid مراجعة.
قوالب قسم العمل الجديد
كان قسم العمل الجديد يقدم قوالب في السابق؛ انتقلت مهامها إلى مفاتيح التبديل المذكورة أعلاه، ويمكن كتابة القالبين اللذين ينشران على Slack بكلماتك الخاصة مع تحديد القناة؛ حيث ينشران عبر خادم MCP الذي تقوم بربطه في إعدادات، ضمن قسم الاتصالات: يمكن للجدول الزمني استخدامه، وكذلك التلقائي القائم على حدث بعد السماح بأدوات MCP في محرره بالمصنع. التلقائيات التي أنشأتها من قالب تستمر في العمل كما هي؛ ويربط رابط قديم لقالب بفتح المفتاح الذي حل محله، أو بقسم العمل الجديد.
مراقبة تلقائي
افتح تلقائيًا في المصنع لرؤية كل عملية تشغيل: متى تمت، وما تكلفتها، وما فتحته، وسبب عدم اكتمالها. من هناك، يمكن للمالكين والمشرفين تعليقه، أو اختباره، أو تعديله، أو حذفه؛ ويمكن لجميع أفراد المؤسسة رؤية التلقائيات وعمليات تشغيلها.
الحفاظ على فائدة التلقائيات
المهام التي يفتحها التلقائي تنافس على نفس مساحات الوكيل مثل أي مهمة أخرى؛ فالتلقائي الذي يعمل بشكل متكرر قد يستهلك قدرتك بهدوء.
- امنحه أولوية أقل من العمل الذي طلبه الأشخاص.
P2أوP3. - اجعل المحفز محددًا. رسالة «فشلت عملية التحقق» تظهر باستمرار في مستودع نشط، بينما تظهر رسالة «فشلت عملية التحقق في الفرع الأساسي» عند وجود خطأ حقيقي.
- انظر إلى ما أنتجته. إذا قام نظام الأتمتة بفتح عشرين مهمة ودمجتَ اثنتين فقط، فهو يولد ضجيجًا وتكاليف دون إضافة قيمة.
المقياس الصادق لنجاح نظام الأتمتة هو نسبة المهام التي تم دمجها من إجمالي المهام التي فتحها، وليس عدد مرات تشغيله.
Sentinel
كانت الإصدارات السابقة من هذه الوثائق تصف أداة Sentinel، وهي أداة مراقبة للكشف عن حدوث شرط معين؛ وهي ليست ميزة منفصلة. الشرط إما حدث يمكن أن يعمل عليه نظام الأتمتة، أو شيء يتحقق منه جدول زمني.