قامت GitLab بأتمتة دورة Merge Request الكاملة عبر 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، بدلاً من إنشاء واحد جديد كان سيتعين مراجعته يدوياً من الصفر. وبالاقتران مع الحل الذاتي لتعارضات الدمج وميزة 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 الموجود بالفعل، بدلاً من إنشاء واحد جديد.