GitLab 19.1: مهام سير عمل الذكاء الاصطناعي تعمل تلقائيًا عند وقوع الأحداث دون تدخل بشري

أصدرت GitLab النسخة 19.1، التي تنقل مهام سير عمل الذكاء الاصطناعي من وضع «شخص ما يضغط الزر» إلى وضع «تعمل من تلقاء نفسها»، وتمنح فرق المؤسسات في الوقت نفسه أدوات للتحكم في ما يعمل تحديدًا.

أربعة محفزات لـ Duo Flows

قبل 19.1، كان كل Duo Flow يتطلب إجراءً يدويًا في واجهة المستخدم: الإشارة إلى المستخدم، أو التعيين، أو إضافة مراجع. وواجهت الفرق التي تشغّل مهام سير عمل إنتاجية على نطاق واسع قيودًا محددة: لا ملخصات تلقائية للتعارضات، ولا فحوص امتثال (compliance) على طلبات الدمج الجاهزة للمراجعة، ولا إنشاء للحوادث عند فشل خط pipeline — وكل ذلك كان غير متاح دون إنسان في السلسلة.

يضيف GitLab 19.1 الآن أربعة محفزات قائمة على الأحداث:

• تعارض في merge request — يبدأ التدفق لحظة اكتشاف التعارض، حين يكون الملخص التلقائي واقتراحات الحل أكثر فائدة — قبل أن يتمكن المطوّر من فتح MR.
• انتقال المسودة إلى «جاهز للمراجعة» — يعمل المحفز عندما يزيل المطوّر حالة draft، فيشغّل تلقائيًا فحص الامتثال للمتطلبات.
• الموافقة على MR — تُشغَّل تلقائيًا الفحوص اللاحقة: الجاهزية للنشر، وتسجيل الامتثال (compliance)، وإشعارات التسليم.
• إنشاء عنصر عمل جديد — فرز فوري، وإسناد تلقائي للوسوم، وتوجيه دون حلول ترقيعية قائمة على webhook خارجي.

المحفزان الأولان مفعّلان افتراضيًا: تحصل الفرق على القيمة فور الترقية إلى 19.1. كما أصبحت التصفية حسب حالات pipeline أدق: يمكن ضبط المحفز ليعمل عند الفشل فقط، أو عند النجاح فقط، أو عند الإلغاء فقط — بدلًا من التفاعل مع كل تغيير في الحالة.

إدارة الوكلاء في البيئة

بالنسبة للمؤسسات الخاضعة للوائح تنظيمية، فإن الوكيل غير المعتمد ليس أمرًا هامشيًا بل عائق حقيقي. فتدفق مخصص واحد ظهر في namespace أثناء هاكاثون دون فحص أمني قد يعرّض تجربة المؤسسة (enterprise trial) بأكملها للخطر. وفي 19.1 ظهر معياران إداريان جديدان:

• Disable custom agents and flows — يمنع المستخدمين من إنشاء وكلاء وتدفقات مخصصة أو تفعيلها، ويقصرهم على المحتوى الأساسي للمنصة.
• Restrict the AI catalog to your group hierarchy — يحظر تفعيل عناصر AI Catalog القادمة من namespace أخرى، بما فيها محتوى المجتمع والأطراف الثالثة.

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

التحقق من الصحة قبل الحفظ

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

عند حفظ التدفق أو تحديثه، تتحقق المنصة من الإعدادات مقابل Duo Workflow Service. وإذا كان هناك خلل — مدخل مفقود، أو معامل أداة غير معروف — تظهر أخطاء منظَّمة مباشرة في الواجهة. تُكتشف المشكلة لحظة الحفظ، لا في الثالثة فجرًا عند فشل pipeline.

«كل تدفق في AI

Catalog مضبوط بشكل صحيح قبل أن يبدأ أي شخص بالاعتماد عليه في بيئة الإنتاج» — من الإصدار الرسمي لـ GitLab 19.1.

وبشكل منفصل، دخلت قائمة نماذج الذكاء الاصطناعي المسموح بها مرحلة البيتا العامة. يحدّ المسؤولون من مجموعة المزوّدين — مثلًا وفق متطلبات إقامة البيانات (data residency) أو سياسات الأمان الداخلية — ويحددون النموذج الافتراضي للمؤسسة بأكملها، مع إبقاء حرية الاختيار للمستخدمين ضمن القائمة المسموح بها.

ماذا يعني ذلك

تعالج GitLab بشكل منهجي العائق الرئيسي أمام اعتماد الذكاء الاصطناعي في المؤسسات: العجز عن الإجابة على سؤال فريق الأمن «ما الذي يعمل تحديدًا في بيئتنا ومن أضافه». وتحوّل المحفزات التلقائية والرقابة الإدارية والتحقق من الإعدادات مهام سير عمل الذكاء الاصطناعي من أدوات إلى بنية تحتية — يمكن التنبؤ بسلوكها وإدارتها، وجاهزة للإنتاج.