الذكاء الاصطناعي يؤتمت merge request في GitLab Developer Flow

في GitLab 19.0 لم يعد وكيل الذكاء الاصطناعي Developer Flow مقتصرًا على كتابة الشيفرة، بل صار يدير دورة حياة merge request كاملةً: من معالجة ملاحظات المراجع وحل تعارضات الدمج وصولًا إلى الدمج النهائي. وهذه خطوة تالية بعد إطلاق Developer Flow في العام الماضي، حين كان قادرًا فقط على تحويل issue إلى MR جاهز.

ما الذي تغيّر في GitLab 19.0

وفقًا لمدوّنة GitLab، اقتصر دور الذكاء الاصطناعي حتى الآن على تسريع كتابة الشيفرة، بينما ظل كل ما بين فتح merge request ودمجه عملًا يدويًا: تعيين المراجعين، ومعالجة الملاحظات جولةً بعد جولة، وفكّ التعارضات، وإجراء rebase قبل الدمج. وكانت كل خطوة من هذه الخطوات تتطلب انتباه المطوّر. أي أن عنق الزجاجة انتقل إلى مكان آخر، دون أن تتكيّف الأدوات معه.

أُطلق Developer Flow في العام الماضي ليحل مهمة واحدة فقط: تحويل issue إلى merge request، عبر أتمتة العمل التحضيري الروتيني بين تحديد المهمة وظهور MR للمراجعة. لكن بعد إنشاء MR، ظل العمل التكراري اللاحق عليه يدويًا بالكامل.

تسدّ النسخة الجديدة من Developer Flow هذه الفجوة تحديدًا. فالوكيل نفسه يعالج الآن ملاحظات المراجعين، ويزيل التعارضات في الفروع طويلة العمر، ويستوعب الشيفرة غير المألوفة، ويقسّم طلبات MR المتضخمة إلى أجزاء. ويعمل ذلك بالتوازي مع الحل المستقل لتعارضات الدمج وrebase-and-merge بنقرة واحدة.

كيف يتصل الوكيل بالعمل على MR

يمكن تشغيل Developer Flow في أي مرحلة من العمل على المهمة. وتوجد ثلاث نقاط دخول: زر Generate MR على issue مباشرةً، أو تعيين حساب الخدمة Duo Developer مباشرةً على issue أو MR، أو المشغّل الجديد عبر الإشارة بالرمز @ في أي سلسلة نقاش على issue أو merge request.

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

فئة جديدة من أدوات الذكاء الاصطناعي للتطوير

تصف GitLab أداة Developer Flow بأنها جزء من فئة جديدة لا تزال قيد التشكّل من أدوات الذكاء الاصطناعي للشيفرة. فالموجة الأولى من هذه الأدوات سرّعت كتابة السطر التالي من الشيفرة (الإكمال التلقائي)، أما الثانية فمنحت المطوّرين نافذة دردشة لطرح الأسئلة. أما ما يظهر الآن فمختلف جذريًا: وكلاء يشاركون في العمل على امتداده كله، لا في لحظة محددة ثابتة.

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

ما هو Developer Flow في GitLab 19.0؟

Developer Flow هو وكيل الذكاء الاصطناعي من GitLab، وقد وسّع في الإصدار 19.0 نطاق مسؤوليته من إنشاء merge request إلى دورة حياته كاملة: معالجة ملاحظات المراجعين، وحل تعارضات الدمج على الفروع طويلة العمر، واستكشاف الشيفرة غير المألوفة، وتقسيم طلبات MR الكبيرة جدًا إلى أجزاء. ويعمل بالتكامل مع الحل المستقل للتعارضات وrebase-and-merge بنقرة واحدة.

كيف تختلف النسخة الجديدة من

Developer Flow عن نسخة العام الماضي؟

اقتصر إطلاق Developer Flow في العام الماضي على أتمتة مرحلة واحدة فقط: تحويل issue إلى merge request، أي التحضير الروتيني بين تحديد المهمة وظهور MR للمراجعة. وظل العمل اللاحق على MR المُنشأ يدويًا بالكامل. أما في GitLab 19.0 فيواصل الوكيل نفسه العمل على MR نفسه بعد إنشائه: يعالج الملاحظات، ويزيل التعارضات، ويشارك في إيصاله إلى الدمج.

كيف تشغّل Developer Flow على merge request؟

توجد ثلاث طرق: الضغط على زر Generate MR على issue، أو تعيين حساب الخدمة Duo Developer مباشرةً على issue أو merge request، أو الإشارة إلى الوكيل عبر مشغّل @ في أي سلسلة نقاش على issue أو MR. وفي جميع الحالات يلتقط الوكيل سياق النقاش ويواصل العمل على MR القائم بالفعل، بدلًا من إنشاء MR جديد.